Leaderboard

In acest tutorial voi ilustra cum pot fi prevenite atacurile de tip stack buffer overflow si heap buffer overflow pe platformele LINUX x86-64 fara editarea fisierelor sursa(presupunem ca toate aplicatiile pe care dorim sa le securizam sunt open source). Cuprins: Tipuri de fisiere obiect(binare) in LINUX Structura fisierelor ELF Imaginea stivei in memorie Ce sunt atacurile de tip stackbuffer overflow?(breviar teoretic) Mijloace curente de prevenire a acestora. Setari implicite(default) Recompilarea aplicatiilor tinta 1. Tipuri de fisiere obiect(binare) in LINUX In LINUX sunt trei tipuri de fisiere obiect: Un fisier relocabil(relocatable) contine cod si date pentru legarea(linking) cu alte fisiere obiect pentru a crea fisiere partajate(shared object) sau fisiere executabile Fisiere executabile. Acestea contin programe(in cod masina) care pot fi rulate direct. Fisierul specifica cum exec creaza imaginea procesului Un fisier obiect partajat(shared object file) contine cod si date ce pot fi legate(linked) in doua contexte. In primul editorul ld il poate procesa impreuna cu un numar de fisiere relocabile si fisiere de tip obiecte partajate(shared object files) pentru a crea un alt fisiere de tip obiect partajat. In celalalt context, linker-ul dinamic(dynamic linker) il combina impreuna cu un fisier executabil si alte fisiere de tip obiecte partajate pentru a crea imaginea unui proces. Diferenta intre fisierele de tip obiect partajat dinamic(dynamic shared object, aceastea se termina cu extensia .so) si cele de tip obiect partajat static(static shared object, acestea se termina cu extensia .a) este ca in primul caz functiile care se gasesc in fisierul .so nu sunt incluse in executabilul final si acestea sunt rezolvate la executie(runtime) in felul urmator: La inceputul imaginii executabilului din memorie se gaseste un fragment de memorie numit procedure linking table(sau PLT). Imaginea executabilului este obtinuta prin incarcarea in memorie de catre sistemul de operare(prin apelul catre functia exec) a fisierului binar de pe hard disk. Imaginea depinde de antetul fisierului ELF despre care vom vorbi in sectiunile urmatoare. Tabela PLT contine intrari(instructiuni de tip jump care modifica pointer-ul de instructiuni(adica punctul in care suntem la un moment dat in executia programului) sa arate catre intrari din GOT) catre proceduri/functii ale caror adrese nu sunt cunoscute in momentul in care se face link-area(prin link-are se intelege legarea definitiei unei proceduri/functii de implementarea sa. In cazul fisierelor obiect partajat dinamic(dynamic shared object) aceasta se gaseste intr-un fisier diferit fata de cel din care a fost chemata). Link-area se realizeaza de catre linker-ul dinamic in momentul executiei(run-time). GOT este o abreviere pentru Global Offset Table si este folosit, de asemenea, pentru rezolvarea adreselor procedurilor in timpul rularii. Mai exact sa presupunem ca avem urmatoarele linii de cod: #include <stdio.h> void main(void) { int a = 1, b = 2; printf("%d %d", a, ; } Implementarea functiei printf nu se gaseste in programul de mai sus. Se obtine in timpul rularii prin link-area dinamic cu libc(libc este un fisiere .so care este incarcat in memorie la boot-are) in felul urmator. Pointer-ul de instructiuni(acesta este memorat intr-un registru(eip(pe platforme x86-64)) si indica catre instructiunea care se executa la un moment dat) va arata catre o instructiune din zona .text(codul programelor si anume al instructiunilor se gaseste aici) care apeleaza printf in felul urmator: call printf # acesta este cod masina(assembly) si reprezinta apelul catre functia printf din programul nostru In cazul nostru nu cunoastem adresa functiei printf in memorie. Acum call printf face ca pointer-ul de instructiuni sa sara catre o intrare din procedure linking table(PLT). Inca o data pointer-ul de instructiuni ne arata instructiunea care se executa in momentul de fata din programul nostru(practic este un reper in cadrul programului; ne arata unde suntem; ca si o analogie pointer-ul poate fi comparat cu un vehicul care "merge" prin program. Instructiunile deja executate reprezinta drumul parcurs) Acum suntem in PLT la o adresa care corespunde functiei printf. Aici intalnim urmatorul set de instructiuni: jmp [printf] # aceasta linie "sare", muta pointer-ul de instructiuni, in GOT. Acum obtinem adresa din GOT. De ex. 0x7fff400 push 0 # aceasta linie urca un argument pe stiva necesar pentru dlresolv jmp dlresolv # aceasta linie apeleaza utilitarul dlresolv care mapeaza adresa din GOT cu adresa functiei printf din libc dlresolve obtine adresa functiei printf din fisierul partajat obiect libc dupa care o plaseaza in GOT. Acum programul nostru stie unde se gaseste implementarea functiei printf in memorie. O data ce se realizeaza aceasta corespondenta(functie - adresa implementare) dlresolve nu mai trebuie apelat ulterior pentru aceiasi functie. Adica daca am mai avea un apel la printf l-am gasi direct in GOT de aceasta data. Un exemplu grafic se gaseste mai jos: 2. Structura fisierelor ELF Fisierele de tip ELF contin urmatoarele sectiuni: .text: aceasta contine totalitatea instructiunilor programului .symtab: tabela de simboluri(importata si exportata) .rel*: adrese de relocare(unde sunt simbolurile folosite) .data and .data1: date initializate .rodata and .rodata1: date initializate de tip read only(valoarea acestora nu poate fi modificata) .debug: informatii simbolice de depanare Mai jos se gasesc cateva ilustrari grafice: Tabela GOT se afla in zona de inceput a executabilului: Modul in care se identifica si mapeaza adresa functiilor din fisierele dinamice partajate se poate observa mai jos: Detalii despre antetul fisierelor ELF se gasesc aici: Executable and Linkable Format - Wikipedia, the free encyclopedia 3. Imaginea stivei in memorie Inainte de a vorbi despre structura stivei voi explica intai rolul acesteia. Initial programele erau scrise in totalitate in limbaj de asamblare. Apelurile catre functii se realizau populand regsitrii apriori cu argumente necesare acestora. In timp, o data cu cresterea complexitatii aplicatiilor software, numarul de registrii disponibili nu mai era suficient pentru apelarea functiilor complexe ce presupuneau un numar ridicat de paramentri(argumente). In consecinta s-a gandit ca o zona de memorie structurata ar putea deservi acestui scop. Astfel, s-a nascut stiva. Aceasta este o structura de tip FIFO(first in first out) pe care sunt stocate, in aceasta ordine, parametrii functiei, adresa de revenire(pointer-ul de instructiuni catre urmatoarea instructiune de apelat dupa functie) si variabile locale functiilor. Stiva functioneaza in felul urmator: la apelul unei functii se salveaza pointer-ul de baza(acesta arata catre fundul stivei), dupa aceea salvam valoarea varfului stivei in pointer-ul de baza iar in pasul final alocam memorie varaiabilelor locale urcand varful stivei cu un anumit numar de bytes. pushl %ebp # salvam baza stivei [B]ebp[/B] movl %esp, %ebp # initializam valoarea bazei cu valoarea varfului(ponter-ului de varf [B]esp[/B]) subl $n,%esp # alocam spatiu pentru variabile locale(urcam valoarea pointer-ului stivei) La sfarsitul apelului eliberam stiva: movl %ebp, %esp # salvam valoarea pointer-ului de baza in pointer-ul de varf(coboram in stiva) popl %ebp # scoatem valoarea intiala a bazei ret # rezumam executia cu instructiunea imediat urmatoare apelului functiei 4. ]Ce sunt atacurile de tip stackbuffer overflow?(breviar teoretic) Atacurile de tip buffer overflow se bazeaza, in principiu, pe lipsa de validare a lungimii vectorilor in limbaje precum C si C++. Cu alte cuvinte un atacator ar putea trimite un sir de octeti(bytes) care sa suprascrie adresa de revenire din functie(acel ret de mai sus) cu o adresa care arata catre o alta functie/instructiune decat cea asteptata in mod normal. Astfel, firul executiei este modificat. De exemplu, in trecut, un atacator incerca sa obtina un apel: system("/bin/bash"); care crea un shell pe statia respectiva prin intermediul caruia puteau fi rulate comenzi primite de la atacator. 5. Mijloace curente de prevenire a acestora. Setari implicite(default) In prezent sunt prezente mijloace de prevenire a executiei de cod in procese prin intermediul suprascrierii adresei de revenire. Mijloacele folosite astazi sunt: NX memory. Cu alte cuvinte stiva nu mai este executabila. Chiar daca un atacator reuseste sa urce un shellcode acesta va genera o exceptie(si in cele mai frecvente cazuri o esuare(crash) a procesului respectiv). ASLR care este o abreviere pentru address space layout randomization. Aceasta tehnica se bazeaza pe arbitrarea zonelor de memorie in care este incarcat programul si a adreselor functiilor/procedurilor acestuia. La fiecare repornire a programului acestea pot fi diferite in functie de implementare Canarries. Acestea sunt secvente de bytes situate pe stiva intre instructiunile functiei si variabilele locale(acestea includ si buffer-ele). Astfel, daca un atacator modifica valoarea canarries-urilor se va genera o exceptie iar programul este oprit. La repornire valoarea acestora poate fi modificata sau nu depinzand de implementare. PIE care este o abreviere pentru Position Independent Executables. Acesta tehnica se bazeaza pe plasarea programelor la adrese arbitrare in memorie(ASLR depinde de PIE) In mod implicit PIE nu este folosita. 6. Recompilarea aplicatiilor tinta Am petrecut ieri putin timp pentru a recompila firefox cu optiunea -pie setata(in gcc). Tehnica urmatoare se poate aplica tuturor aplicatiilor de tip opensource(cele care se compileaza apeland configure, make si (sudo)make install. Descarcam intai fisierele sursa. Acestea se gasesc aici: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/ Pentru a dezarhiva sursele rulam: tar -xjf <source-file.tar.bz2> Acum navigam in directorul creat dupa dezarhivare si cream un fisier .mozconf In el includem urmatoarele: # Start .mozconfig mk_add_options MOZ_OBJDIR=../obj # Pe cate core-uri are loc compilarea mk_add_options MOZ_MAKE_FLAGS="-j6" ac_add_options --disable-debug ac_add_options --disable-tests ac_add_options --enable-strip ac_add_options --disable-installer ac_add_options --enable-optimize="-march=corei7 -mavx -mpclmul -mfpmath=sse+387 -pie -fPIC" mk_add_options MOZ_OBJDIR=../obj ne spune unde se va crea executabilul. Linia: ac_add_options --enable-optimize="-march=corei7 -mavx -mpclmul -mfpmath=sse+387 -pie -fPIC" contine parametrii de optimizare. Observam aici si argumentul -pie. -march ne da arhitectura pentru care dorim sa optimizam browser-ul. Folositi -march=native daca nu sunteti siguri de arhitectura pe care o detineti. Aceasta se poate obtine cu: uname -m Acum avem toate fanioanele pentru optimizare setate si de asemenea compilarea se va face cu PIE. Pentru a porni procesul de compilare rulam: make -f client.mk build MOZ_CURRENT_PROJECT=browser Daca apar erori sau doriti sa compilati cu alte optiuni stergeti tot ce se gaseste in directorul destinatie(in acest caz acesta este ../obj astfel: rm -a ../obj/* # argumentul a sterge toate fisierele(si symlink-urile) si rulati din nou comanda de compilare. La sfarsit va veti putea bucura de un browser mai sigur si mai rapid. Tehnica este aplicabila oricarei aplicatii scrise in C/C++(asta include si kernel-ul).

Nu dau nume, dar macar cei care ati spus ca donati sa si donati, nu sa mi spui sa te ajut, imi ceri si datele, nu trimti nimic si nici nu mai raspunzi nici pe forum nici pe Y!M. (Nu ca ar fi mare valoare 4GB rami dar fi om in pula mea macar!)

To program in Assembly, you will need some software, namely an assembler and a code editor as we have seen in chapter 1. An assembler takes the written assembly code and converts it into machine code, it will come with a linker that links the assembled files and produces a executable from it (.exe extension). Sometimes, a crash may happen when the program cannot normally continue its execution or even run because of a programming bug; fortunately, there is a program called the debugger that runs other programs, allowing its user to exercise some degree of control over the program, and to examine them when things go amiss. Another tool you may have guessed is the disassembler, which translates executable code into assembly language—the inverse operation to that of an assembler. Finally, there is a tool called a resource compiler, I’m going to explain it later in this saga. In each tool, there is quite a good selection that can do the job very well. Code Editor: (Notepad++, UltraEdit, VIM, …) Assemblers: (JWasm, GoAsm, yASM, Fasm, …) Linker: (JWlink, Link, PoLink, …) Resource Compiler: (Microsoft RC, PoRC, GoRC, …) Debugger: (OllyDBG,Immunity Debugger, WinDBG, SoftICE, …) Disassembler: (IDA Pro, Win32Dasm, HDasm, …) Integrated Development Environment (IDE): ( All-In-One utility, Source Code Editor + Assembler + Linker + Resource Compiler) Assembler / Linker : It goes without saying that MASM, originally by Microsoft, is the king of the hill. The real problem with MASM is the restrictions about its license, and also that it’s not constantly updated but only on an as-needed basis by Microsoft. JWasm fixes it all: JWasm is free, has no artificial license restrictions, and can be used to create binaries for any OS. JWasm’s source is open. Hence JWasm is able to run – natively – on Windows, DOS, Linux, FreeBSD and OS/2. More output formats supported (Bin, ELF). Optionally very small object modules can be created. Better support for Open Watcom, for example the register-based calling convention. JWasm is faster than MASM. We will use PoLink as a linker, we can use ML (Microsoft Linker) too, there is only one difference between them: PoLink accept RES files for resources, whereas ML wants an OBJ file. Another difference is that PoLink can make smaller EXE’s although, with the right switches, and it is more up to date. Debugger/Disassembler: Now, we will look at some of the differences between several of the most widely used Debuggers/Disassembles. This is by no means exhaustive. Consider it as a brief overview to give people new to assembly/reversing a “quick start” guide. Before we look at IDA Pro (Free), Immunity Debugger (ImmDBG) and Olly Debugger (OllyDBG). We must first fully understand the differences between a debugger and a disassembler. I have heard these terms used interchangeably, but they are two separate tools. A disassembler will take a binary and break it down into human readable assembly. With a disassembler you can take a binary and see exactly how it functions (static analysis). Whereas with a debugger we can step through, break and edit the assembly while it is executing (dynamic analysis). IDA Pro (proprietary software, free version available) Honestly, IDA Pro should be in a category by itself. It is an interactive, extensible disassembler and debugger. IDA is also programmable with a complete development environment. This allows users to build plug-ins and scripts to assist them in their research. The standard version of IDA is too expensive and gives you support for over 50 families of processors. But for someone who is new to reversing/disassembling, the free version will do just fine. One of the main advantages you’ll notice that IDA has over Immunity Debugger (ImmDBG) and Olly Debugger (OllyDBG) is its platform support. IDA is available for Windows and Linux as well as Mac OS X. Olly Debugger (OllyDBG) OllyDBG is a user-friendly, very small and portable 32-bit user-mode debugger with intuitive interface. As you get experience, you’ll able to discover how powerful OllyDBG is. OllyDBG knows most of the Windows APIs when you’re examining your binary. OllyDBG will show you what each register parameter means. Unfortunately, it does not understand Microsoft’s symbol file format or debug information. Immunity Debugger (ImmDBG) Immunity Debugger is very similar to OllyDBG, the only new features ImmDbg offers over Olly is Python scripting and function graphing, both of which are already supported in Olly through plug-ins. There are also plug-ins to fix the numerous bugs Olly has as well. This is what it’s all about. Integrated Development Environment: There are also a thousand IDEs, all of them are quite awesome: Once you have the JWasm Assembler, the MASM32 SDK, and the EasyCode IDE, extract them in a default folder in your hard disk. You don’t actually need the other tools for this part, keep them for later. Unzip the package and run install.exe. Then, a series of message boxes will pop up, keep hitting OK till it asks to start extracting the package. Again, click OK till it says that the installation has proceeded to its completion and appears to have run correctly. Unzip the EasyCode.zip file and the ‘EasyCode.Ms‘ folder will be created. Place the whole EasyCode.Ms folder anywhere you like in one of your hard disks. If the folder already exists, overwrite it. Close all applications, open the EasyCode.Ms folder and run the ‘Settings.exe’ program (if possible, as an Administrator). Choose the desired options and press the ‘OK’ button. Now extract the JWasm archive, locate ‘JWasm.exe’, and copy it in the ‘C:masm32bin’ directory. Run the ‘EasyCode.exe’ file (located in the ‘EasyCode.MsBin’ folder) or in the desktop and set the paths for Masm32 files. To do so, use the ‘Tools–>Settings’ menu. Go to the Compiler/Link Tab and set up paths as below: Apply the changes, then press OK. Now that we have our tools working like a charm, let’s begin programming! This is the most commonly written program in the world, the “Hello World!” program. Click CTRL+N for a new project, choose classic executable file, and uncheck all the options: Copy and paste the following code in your IDE: ;----------------------------------------------- ; MessageBox.asm — Displays “Don’t learn …” in a message box ; ---------------------------------------------- .386 .Data MsgBoxCaption DB “Simple Message Box”,0 MsgBoxText DB “Hello, 0ld W0rld !”,0 .Code start: push MB_OK +MB_ICONASTERISK push offset MsgBoxCaption push offset MsgBoxText push NULL call MessageBox invoke ExitProcess, NULL End start Click F7 for building the project, you’ll be asked to save it. First of all, I recommend you create a new folder called ‘Projects” in EasyCode.Ms and save all your projects in it. Afterward, create a new folder in the “Projects” directory and call it: myFirstProgram, save all files: myFirstProgram.ecp (The Project File). myFirstProgram.asm (The Assembly code file). Press CTRL+F5 to run it: Congratulations, you have just run your first assembly code ! Take your time to discover your favorite IDE and its features. Also, you should take into consideration that IDA Pro alone requires a book or a whole chapter to fully present it as it is worth, and this also goes for OllyDBG & ImmDBG. In this chapter, the primary goal was to get you familiar with some assembly and debugging/disassembling tools. I assume you understand that the syntax of assembly code differs slightly from an assembler to another; nevertheless, different assemblers will generate in the end the same machine code.

Puteti folosi categoria "Free stuff" daca doriti sa oferiti ceva. Oferiti cui doriti, pe ce criterii doriti. Bafta!

Si eu am una in caz ca doreste cineva.

+ 2 placi de baza asus eee pc

Ideea e foarte buna. Care are de donat ceva, face un thread nou, cine doreste posteaza acolo, iar donatorul alege cui sa il dea, plus ca sa evitam taxele de transport, putem face tranzactia prin tocmai.ro, ca tot ofera transport gratis. Intre timp, am si eu de donat mai multe piese (placi de baza, unitati optice, HDD-uri) modele mai vechi, cat si o multime de periferice: tastaturi, mouse-uri, imprimante. Dati PM cu ce aveti nevoie.

5 placute ram ddr2 1 gb

Sa va zic o treaba. Binenteles ca am votat DA. In 2006 m-am apucat sa fac calculatoare din bucati (okazii,prieteni....) in speranta ca in fiecare and e Craciun ma urc in masina, merg inainte(nu conteaza unde), numai sa ajung intr-un sat, vad un copil mai de 10-15 ani si sa ii donez 1 PC. Am facut cu succes acest lucru 2006-2009 (in 2009 am avut chiar 2 donate). Bun. In 2010 m-am apucat sa strang iar dar nu prea mai aveam $$$ sa cumpar de pe okazii asa ca am mers pe la diversi si diverse firme in speranta ca ma voi lipi de 1-10 lei. Din ianuarie si pana in august am strans 20 lei. Da da da, 20 de lei, si astia 20 de lei i-am luat de la niste oameni simpli ce traiesc de azi pe maine. Nu intru in amanunte prea mult ca deja m-au luat nervii numai ca mi-am amintit decat de jegosi si prosti sunt romanii(nu toti binenteles). Concluzie: Lumea din ziua de azi prefera sa dea bani la ala de-ti spala parbrizul sau la cersetori diversi (majoritatea dintre ei foarte apti de munca) decat sa ajute la promovarea educatiei in familiile nevoiase (si aici ma refer in special la cele din zona rurala). In fine, ideea e buna dar nu se aplica in ROMANIA! Cheers

Please help my