Buffer overflow napad – prevencija i zaštita

Buffer overflow je vrsta sigurnosnog propusta u softveru koji se dešava kada program pokuša da napiše više podataka u memorijski buffer nego što taj buffer može da sadrži. Tada dolazi do prelivanja (upisivanja) tih podataka u susedne delove memorije, što može da dovede do oštećenja podataka ili, u najgorem slučaju, do izvršavanja zlonamernog koda i preuzimanja kontrole nad čitavim sistemom.

Ovo je najviše karakteristično za C i C++ programske jezike, gde ručno upravljanje memorijom i nedostatak ugrađenih bezbednosnih mehanizama (kao na primer provera dužine stringa teksta prilikom upisa) čine da su ova dva jezika posebno podložna ovakvim napadima. 

Sa druge strane, Java, Python i JavaScript  imaju jaču kontrolu pristupa memoriji, pa su u startu nešto otporniji. 

Ipak, treba imati u vidu da nijedan programski jezik nije u potpunosti bezbedan od buffer overflow-a. Granice u bufferu mogu biti probijene u svim jezicima ukoliko u kodu postoje neke logičke ranjivosti ili ukoliko se koriste biblioteke koje omogućavaju direktan pristup memoriji.

Zato ćemo u ovom tekstu detaljnije objasniti na koji način dolazi do buffer overflow-a i kako da se zaštitite od ove vrste napada. 

Kako memorija radi u procesu

Razumevanje buffer overflow-a ne može biti potpuno bez razumevanja načina na koji je memorija organizovana u jednom procesu. U savremenim operativnim sistemima, kada se program pokrene, njegov prostor u memoriji se uglavnom deli na nekoliko glavnih segmenata:

1. Kod segment
   U ovom segmentu se nalaze kompajlirane instrukcije programa, koje se izvršavaju na procesoru. Ovaj segment je obično zaštićen tako da on ne može da se menja tokom rada programa (read-only), iako postoje neki izuzeci od ovog pravila.
   
2. Data segment
   Sadrži globalne promenljive koje su inicijalizovane pre pokretanja programa. Ovo se često deli na deo koji je samo za čitanje (npr. za konstantne vrednosti) i deo koji je za čitanje i pisanje (za promenljive koje mogu da se menjaju).
   
3. BSS segment (Block Starting Symbol)
   Ovo je deo gde se nalaze globalne i statičke promenljive koje nisu inicijalizovane ili su inicijalizovane na nulu. Za razliku od dela data segmenta, ovde se konkretni sadržaj definiše prilikom učitavanja programa u memoriju.
   
4. Stack segment
   Koristi se za upravljanje pozivima funkcija. Kada se funkcija pozove, na stack-u se čuvaju argumenti funkcije, pokazivač na adresu sa koje treba da se nastavi program nakon povratka iz funkcije (return address), kao i lokalne promenljive. Stack se organizuje po principu „last-in-first-out“ (LIFO). Zato se kasnije dodat sadržaj uklanja pre onog koji je ranije dodat.
   
5. Heap segment
   Predviđen je za dinamičku alokaciju memorije. U C jeziku, na primer, ovo se radi pomoću funkcije malloc(), dok se u C++ to često radi pomoću new(). Podaci koje ovde alociramo ostaju u memoriji sve dok ih eksplicitno ne oslobodimo (putem free() u C ili delete u C++).

Kada program krene sa radom, kompajlirani kod se učitava u kod segment, statičke i globalne promenljive odlaze u data i BSS, dok se pri pozivima funkcija i dinamičkoj alokaciji koristi stack ili heap. Upravo u stacku i heapu najčešće dolazi do buffer overflow napada.

Vrste buffer overflow napada

Buffer overflow načelno možemo podeliti na pet kategorija:

1. Stack-based buffer overflow
2. Heap-based buffer overflow
3. Integer overflow
4. Format string overflow
5. Unicode overflow

Svaka kategorija ima specifičnu tehniku eksploatacije, iako je krajnji cilj najčešće isti: prepisivanje kritičnih struktura u memoriji kako bi se postiglo neovlašćeno izvršavanje koda, rušenje procesa ili neka druga zloupotreba.

Stack-based buffer overflow

Šta je stack-based overflow?
Kod stack-based napada, prepisuje se prostor na stack, koji je definisan lokalnim promenljivima i podacima funkcija. Svaki put kada se funkcija pozove, kreira se tzv. stack frame. U njemu se nalaze:

• Argumenti funkcije
• Adresa na koju se program vraća nakon završetka funkcije (return address)
• Pokazivač za bazu tog stack frame-a (EBP u 32-bitnom sistemu, RBP u 64-bitnom)
• Lokalni bufferi i promenljive

Da bismo razumeli kako dolazi do prepisivanja, hajde da zamislimo funkciju koja izgleda ovako (ovde dajemo primer pseudo-koda):

void hello() {

    char buffer[76];

    gets(buffer);

    printf("Uneta vrednost: %s\n", buffer);

    return;

}

Funkcija gets može da bude problematična sa stanovišta bezbednosti zato što ne proverava dužinu unosa. Ako korisnik upiše 80 ili više karaktera, vrednost počinje da curi iz rezervisanog prostora buffer[76] i time prepisuje susednu memoriju. 

U nekim slučajevima, to može značiti prepisivanje adrese povratka – što je upravo ključ napada. Ako se ta adresa zameni nekom proizvoljnom adresom koja sadrži uputstvo za skok na napadačev kod, nakon završetka funkcije hello() procesor će preći na tu adresu i izvršiti maliciozni kod (shellcode ili poziv neovlašćene funkcije poput admin_panel()).

Kako funkcioniše mehanizam poziva funkcije?

1. Pre poziva funkcije, argumenti se guraju na stack (push).
2. Ukoliko je reč o 32-bitnoj arhitekturi, nakon toga se na stack-u čuva i adresa sa koje treba nastaviti nakon završetka funkcije (tzv. return address).
3. Formira se novi frame tako što se postavi baza tog frame-a (EBP) i eventualno pomeri vrh stack-a (ESP) da bi se napravilo mesta za lokalne promenljive.
4. Kada funkcija završi, vraćamo se na onu adresu koja je čuvana na stacku – odnosno, učitavamo je u registar EIP na 32-bit, ili RIP na 64-bit sistemu.

Kada neko izvrši buffer overflow, može da prepiše upravo tu adresu povratka, što vodi u kontrolu toka programa.

Heap-based buffer overflow

Nasuprot stack-u, heap-based napadi se odvijaju u dinamički alociranoj memoriji (heap-u). Ovde se koriste funkcije poput malloc(), calloc(), realloc() u C jeziku ili new u C++. Recimo da imamo sledeću konstrukciju:

char *buffer = malloc(32);

char *secret = malloc(32);

gets(buffer);  // Ozbiljno nebezbedno

Ako upišemo više od 32 bajta u buffer, višak će početi da prepisuje susednu memoriju, što može da bude promenljiva secret ili deo neke druge strukture. Tako dolazi do korupcije memorije, rušenja programa ili potencijalne zloupotrebe. 

U zavisnosti od rasporeda u memoriji i od toga šta je smešteno pored buffer promenljive, napadač može da prepiše tabele funkcijskih pokazivača, vrednosti koje kontrolišu tok programa i slično.

Zašto je ovo moguće?
Heap je dizajniran da bude fleksibilan: programer ručno traži memoriju i oslobađa je. Sam operativni sistem i interni mehanizmi alokatora ne proveravaju uvek da li se upis vrši van zadatih granica. Ako funkcija poput gets (koja je ionako obustavljena u modernim standardima C jezika – ISO/IEC 9899) dopusti neograničen unos, prelazimo granice alociranog bloka.

Integer overflow

Šta je integer overflow?
Integer overflow nastaje kada se celobrojni tip (npr. int ili long) prebaci iznad svog maksimalnog opsega ili padne ispod minimalnog. To dovodi do toga da se rezultat obmota na početak opsega (ili dobije neočekivanu vrednost), što omogućava različite sigurnosne propuste, uključujući i prelivanje buffer-a.

Kako može izgledati tipičan primer?
Zamislimo funkciju koja alocira buffer na osnovu korisničkog unosa:

void allocateBuffer(int length) {
    char *buffer;
    
    // Proračun veličine buffer-a
    int size = length * sizeof(char);

    // Zatim se alocira memorija
    buffer = (char *) malloc(size);

    if (buffer == NULL) {
        printf("Neuspešna alokacija\n");
        return;
    }

    // Popunimo buffer
    memset(buffer, 'A', size);
    printf("Alocirali smo bafer dužine: %d\n", size);

    free(buffer);
    return;
}

Ako length premaši vrednost koju int može da čuva (npr. unese se nenamerno ogromna vrednost), doći će do celobrojnog prelivanja prilikom length * sizeof(char). Rezultat može postati izuzetno mali ili negativan, a to izaziva nedovoljnu (ili neispravnu) alokaciju, što se kasnije može iskoristiti za prelivanje buffer-a.

Kako dovodi do prepisivanja memorije?

• Program očekuje da je size dovoljno veliki da stane sav sadržaj.
• Zbog prelivanja, size ispadne suviše mali ili pogrešan.
• Kopiranjem više podataka u nedovoljno velik buffer, curi se u memorijski prostor koji ne pripada buffer-u, pa se mogu oštetiti susedne promenljive ili povratne adrese.

Kada neko izvrši integer overflow, može:

• Potencijalno preusmeriti tok programa ako se cilja na kontrolne adrese
• Neprimećeno da alocira premalo memorije i time omogući klasično prelivanje buffer-a.
• Oštetiti kritične strukture (npr. stack frame, globalne promenljive).

Format string overflow

Šta je format string overflow?
Ova ranjivost se javlja kada se vrednost korisničkog unosa direktno koristi kao format string bez odgovarajućeg format specifier-a. Na primer:

printf(userInput); 

umesto:

printf("%s", userInput);

U tom slučaju, korisnik može da unese specijalne formate (%x, %n, %p, itd.) i tako čita, menja ili prepisuje delove memorije.

Kako može izgledati tipičan primer?
Zamislimo funkciju:

void printMessage(char *msg) {
    // Ranjiv primer: msg se koristi direktno
    printf(msg);
    return;
}

Ako msg sadrži:

Hello %x %x %n

funkcija printf će pokušati da pročita (i eventualno upiše) vrednosti na stack-u, oštećujući memoriju ili otkrivajući osetljive podatke.

Kako dovodi do prepisivanja memorije?

• Korišćenje %n omogućava da se broj ispisanih karaktera upiše na određenu lokaciju na stack-u.
• Na taj način je moguće menjati vrednosti bitnih promenljivih ili čak povratnu adresu.
• Dolazi do neovlašćene kontrole toka programa, slično klasičnom buffer overflow-u.

Kada neko izvrši format string overflow, može:

• Čitati vrednosti iz memorije, što otvara vrata za dalji napad (otkrivanje adresa, ključeva, lozinki).
• Upisivati nepoželjne vrednosti u memoriju, prepisivati povratne adrese.
• Preuzeti potpunu kontrolu nad tokom programa.

Unicode overflow

Šta je Unicode-based napad?
Kod Unicode-based prelivanja, ranjivost se javlja pri rukovanju proširenim skupovima znakova (UTF-8, UTF-16, UTF-32, wchar_t, itd.). Za razliku od ASCII-ja, gde svaki znak zauzima 1 bajt, Unicode znak može zauzimati 2 ili više bajtova, što povećava šansu za prelivanje ako se veličina memorije ne računa ispravno.

Kako može izgledati tipičan primer?
Razmotrimo funkciju koja koristi široke karaktere (wchar_t):

void processWideString(const wchar_t *input) {
    // Buffer od 16 wide karaktera
    wchar_t buffer[16];

    // Kopiramo input bez proveravanja dužine
    wcscpy(buffer, input);

    wprintf(L"Obrađeni ulaz: %ls\n", buffer);
    return;
}

Ako input ima više od 15 znakova (računajući i završni karakter \0), prepiše se memorija van buffer[16]. Time se mogu prepisati druge kritične strukture na steku.

Kako dovodi do prepisivanja memorije?

• Nedovoljno ili pogrešno alociran buffer za široke karaktere.
• Moguća pogrešna konverzija između različitih formata (UTF-8, UTF-16) dovodi do neočekivanog povećanja broja bajtova.
• Usled toga, napadač dobija mogućnost da prepiše povratnu adresu, globalne vrednosti ili druge delove memorije.

Kada neko izvrši Unicode-based napad, može:

• „Curenjem“ iz buffer-a oštetiti kontrolne strukture sličnim mehanizmom kao kod klasičnog buffer overflow-a.
• U kritičnim slučajevima, preuzeti tok programa i izvršiti neovlašćeni kod.

Buffer overflow i DoS (Denial of Service) napadi

Buffer overflow napadi se ne svode uvek na daljinsko izvršavanje koda. Nekad je cilj jednostavno rušenje procesa ili servisa, što za posledicu ima Denial of Service. 

Napadač može:

• Da uputi posebno pripremljen zahtev koji izaziva prevelik broj bajtova na ulazu
• Da ošteti vitalne strukture programa, tako da se on ruši i više nije dostupan legitimnim korisnicima

Na primer, ranjivosti u biblioteci mod_lua u okviru Apache web servera (CVE-2021-44790) su pokazale kako pogrešno upravljanje veličinom buffera dovodi do situacije u kojoj veličina za memcpy() postane 0 ili neka ekstremno neispravna vrednost. Rezultat može biti SEGMENTATION FAULT, obaranje celog procesa i onemogućavanje pristupa web servisu.

Buffer overflow i daljinsko izvršavanje komandi (StageFright)

Jedan od najupečatljivijih primera jeste StageFright ranjivost u Android operativnom sistemu (otkrivena 2015. godine). 

Ova biblioteka, pisana u C++, služila je za obradu multimedijalnih fajlova. Greška u njoj je dopustila da se zlonamerno pripremljen fajl (MMS ili drugi format) iskoristi za prepisivanje memorije i daljinsko izvršavanje koda, a korisnik nije morao čak ni da otvori fajl; dovoljno je bilo da telefon pokuša da ga obradi u pozadini. 

Procene su govorile da je preko 95% uređaja s Androidom u to vreme bilo ranjivo.

Posledice buffer overflow napada

• Rušenje servera ili aplikacije
  Kada se buffer prepiše i dođe do korupcije memorije, program često prestaje sa radom i generiše grešku (SEGV, SEGMENTATION FAULT). U produkciji to znači obaranje servisa, što uzrokuje prekid rada za korisnike (DoS). Veliki sistemi, kao što su bankarski ili industrijski sistemi, mogu zbog ovoga da pretrpe veliku štetu i finansijske gubitke.

• Izvršavanje proizvoljnog koda
  Iskorišćavanje ranjivosti može da podrazumeva ubacivanje malicioznog koda (shellcode), ili preusmeravanje toka programa na već postojeće funkcije koje su napadaču od koristi (npr. system("/bin/sh")). Ako proces radi s višim privilegijama (poput root korisnika na Linuxu ili SYSTEM naloga na Windowsu), napadač na taj način može da preuzme čitav računar.

• Otvaranje vrata za druge napade
  Kada napadač jednom dobije pristup sistemu, on uglavnom nastavlja da istražuje druge ranjivosti i mogućnosti. Može da preuzme fajlove, instalira zlonamerne procese ili promeni konfiguracije da bi postavio trajni pristup (tzv. backdoor). Buffer overflow tako često bude samo prvi korak u složenom lancu napada.

Kako se zaštititi od buffer overflow napada

Iako ne postoji čarobni štapić koji bi zauvek sprečio svaki buffer overflow, moderna bezbednosna praksa uključuje niz mera koje značajno otežavaju ili onemogućavaju uspešnu eksploataciju. Ovo uključuje:

• ASLR (Address Space Layout Randomization)
  Ova tehnika sprečava napadača da lako pogodi adresu kritičnih struktura (poput adrese na stack-u ili heap-u). Prilikom pokretanja nekog procesa operativni sistem nasumično raspoređuje glavne segmente memorije (stack, heap, biblioteke). Tako napadač ne može uvek da predvidi tačnu lokaciju svog malicioznog koda ili adrese koju želi da prepiše. Mada je ASLR važan korak, postoje i tehnike za njegovu zaobilaženje (bruteforce, infoleaks), pa se ne treba slepo oslanjati samo na njega.
  
• NX (Non-executable) bit / DEP (Data Execution Prevention)
  Cilj je da se segmenti memorije (stack, heap) proglase neizvršnim, tako da se čak i ako napadač uspe da ubrizga (inject-uje) zlonamerni kod, on ne može direktno da se pokrene odatle. U starijim sistemima su stack i heap mogli da budu izvršni, što je napadaču olakšavalo posao. Danas većina modernih operativnih sistema ima aktiviranu ovu opciju. Ipak, treba imati u vidu da postoje i tehnike poput ROP-a (Return-Oriented Programming) koje zaobilaze NX tako što skaču po već postojećem kodu u memoriji.
  
• SSP (Stack Smashing Protector), poznat i kao canary (kanarinac)
  Kompajleri poput GCC-a umeću mali zaštitni podatak (tzv. canary) tik ispred adrese povratka na stacku. Ako se tokom izvršenja funkcije otkrije da je canary izmenjen, program to prepoznaje kao pokušaj buffer overflow-a i odmah prekida rad. Ovo efikasno zaustavlja veliki broj napada. Nažalost, postoje metode za zaobilaženje SSP-a (ako napadač uspe da pronađe način da ne prepiše canary ili da ga prepiše pravom vrednošću).
  
• Sigurnije funkcije i proveravanje ulaza
  Funkcije kao što su gets, strcpy, strcat, sprintf, memcpy (bez dodatnih provera) tradicionalno nisu bezbedne, jer ne proveravaju veličinu ulaza. Umesto njih, dobra praksa je da koristite bezbednije varijante poput fgets, strncpy, snprintf, ili da makar prethodno proverite i ograničite dužinu niza.
  • Validacija korisničkog unosa: Svaki unos od strane korisnika (ili od spoljnih servisa) mora biti tretiran kao potencijalno nebezbedan. Provere dužine i formatiranja ulaza treba da budu obavezna praksa.
  • Kod koji radi s memorijom: Uvek treba da proverite da li se upis vrši u opseg raspoložive memorije. Ako se koriste dinamički alocirane strukture, pobrinite se da su one dovoljno velike i da nema slučajeva preklapanja.

• Redovno ažuriranje i zakrpe
  Kako se softver razvija, tako se pronalaze nove ranjivosti, pa samim tim izlaze i nove zakrpe (patches). Bez redovnih ažuriranja, vaš sistem ostaje izložen već poznatim propustima. Na primer, samo tokom jednog meseca (decembra 2024. godine) objavljeno je 18 CVE ranjivosti s ocenom većom od 9 po CVSS skali, što govori o ozbiljnosti i učestalosti propusta.
• Bezbednosno testiranje (fuzzing, pen-test, statička i dinamička analiza koda)
  • Fuzzing: Automatizovani alat koji nasumično generiše ulaze za aplikaciju pokušavajući da je poremeti, što može otkriti potencijalne buffer overflows.
  • Pen-test (penetration testing): Ekipa testera namerno traži rupe u sistemu s ciljem da se uoče slabosti pre nego što to urade zlonamerni napadači.
  • Statička analiza koda: Prolazi kroz kod bez njegovog izvršenja, tražeći uzorke koji mogu ukazivati na nebezbedne funkcije i nedovoljno proverene unose.
  • Dinamička analiza koda: Aplikacija se izvršava u kontrolisanom okruženju dok alat prati upotrebu memorije, beleži potencijalne curenja memorije ili nedozvoljene pristupe.

• Princip najmanjih privilegija (Least Privilege)
  Čak i da dođe do buffer overflow-a, ukoliko proces nema suvišne privilegije, napadač neće automatski steći potpuni pristup sistemu. Ovo podrazumeva da aplikacije i servisi rade samo s onim ovlašćenjima koja su im striktno potrebna za normalan rad.
• Separacija procesa i sandboxing
  Tehnike sandboxing-a i kontejnerizacije (poput Docker-a ili LXC-a) omogućavaju da se procesi pokreću u izolovanim okruženjima. Ako dođe do kompromitovanja jednog procesa, šteta je ograničena samo na taj kontejner ili sandbox.

Praktični saveti za programere

• Imajte u planu bezbednost još u fazi projektovanja:
  Bezbednost nije samo tema za kasnije. Dok pišete softver, uvek razmišljajte koliko memorije dodeljujete, da li vi ili biblioteka koristite bezbedne funkcije, kako reagujete na neočekivane dužine ili formate ulaza.

Primer koda (provera dužine pri kopiranju stringa):

void safe_copy(char *dest, size_t dest_size, const char *src) {

    // Proveravamo da li je izvor duži od destinacije -1 (rezervisano za terminator)

    if (strlen(src) >= dest_size) {

        fprintf(stderr, "Greška: pokušaj kopiranja prevelikog stringa!\n");

        return;

    }

    strcpy(dest, src);

}

U ovom primeru koristimo strlen da bismo proverili dužinu ulaznog stringa pre kopiranja. Iako je i strcpy nebezbedan u osnovi, dodatna provera veličine unosa obezbeđuje da ne dođe do prepisivanja.

• Obavljajte revizije koda (code review):
  Dva para očiju vide više nego jedan. Pregledajte međusobno kod i tražite pozive funkcijama visokog rizika ili mesta gde se barata stringovima bez provere dužine. Uvek obratite pažnju na kompleksne delove koda gde se mnogo manipulacije vrši nad memorijskim strukturama.

Primer koda (rizična funkcija):

// Rizično

void input_data(char *user_input) {

    // Bez provere kolike je dužine user_input

    char buffer[64];

    strcpy(buffer, user_input);

    // ...

}

Tokom code review-a, važno je da primetite ovakve slučajeve i da ih nakon toga zamenite sigurnijim pristupom:

// Sigurnije

void input_data_safe(char *user_input) {

    char buffer[64];

    strncpy(buffer, user_input, sizeof(buffer) - 1);

    buffer[sizeof(buffer) - 1] = '\0';

    // ...

}

• Koristite alate za statičku i dinamičku analizu:
  Statička analiza automatski pronalazi potencijalno opasne konstrukcije, poput strcpy(buffer, user_input).
  Dinamička analiza (valgrind, sanitizers) pomaže da u toku izvršavanja vidite da li dolazi do upisa van opsega, dvostrukog oslobađanja memorije i sl.

Korišćenje sanitizera (AddressSanitizer) prilikom kompajliranja:

gcc -fsanitize=address -g -o moj_program moj_program.c

Kada se program pokrene, AddressSanitizer prati potencijalne out-of-bounds pristupe i prijavljuje greške.

• Testirajte ekstenzivno:
  U idealnom slučaju, vaša aplikacija treba da prođe kroz stotine ili hiljade testova koji uključuju nevažeće ili izuzetno velike ulaze. Tako ćete na vreme videti da li se dešavaju nevalidni upisi u memoriju. Fuzzing alati su odlični za automatsko generisanje takvih scenario testova.

Primer fuzzing testa (libFuzzer za C/C++):

#include <stddef.h>

#include <stdint.h>

extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {

    // Pozovite funkciju koju testirate, npr. parseData(Data, Size);

    // Cilj je da vidite da li će doći do rušenja ili curenja

    return 0;

}

• Birajte modernije biblioteke i API-je:
  Mnoge standardne biblioteke danas imaju funkcije koje proveravaju veličinu memorije. Na primer, snprintf (umesto sprintf), strncat (umesto strcat), i slično.

Primer razlike između sprintf i snprintf:

char output[100];

int num = 42;

// Neprovereno: može prepisati ako je rezultat veći od 100 bajtova

sprintf(output, "Broj je: %d", num);

// Bezbednije: ograničavamo maksimalnu veličinu zapisa

snprintf(output, sizeof(output), "Broj je: %d", num);

• Razmislite o prelasku na bezbednije jezike ili okruženja kada je to moguće:
  Iako nije uvek izvodljivo (naročito za sisteme niskog nivoa i drajvere koji traže C/C++), u mnogim poslovnim aplikacijama prelazak na Java, Rust, Go ili slične jezike može znatno smanjiti rizik. Rust je, na primer, projektovan s namerom da spreči većinu grešaka s memorijom.

Primer u Rust-u:

fn main() {

    let data = String::from("Neka korisnička vrednost");

    println!("Dužina stringa je: {}", data.len());

}

Jezik sam brine o granicama i oslobađanju memorije, čime se rizik od buffer overflow-a svodi na minimum.

Praktični saveti za administratore

• Redovna primena patch-eva:
  Najveći deo napada na buffer overflow oslanja se na poznate ranjivosti. Ako vaš operativni sistem i softver (poput Apache, Nginx, PHP, baza podataka) nisu ažurirani, vrlo je verovatno da su izloženi već dokumentovanim propustima.

Primer nadogradnje paketa na Linux sistemima (Debian/Ubuntu):

sudo apt-get update

sudo apt-get upgrade

Ovim procesom instaliraju se najnoviji patch-evi, čime se smanjuje verovatnoća uspešne eksploatacije poznatih ranjivosti.

• Instaliranje i pravilno podešavanje sistema za detekciju upada (IDS/IPS):
  Alati kao što su Snort, Suricata ili WAF (Web Application Firewall) mogu da prepoznaju pokušaj slanja neprirodno dugačkog zahteva ka određenom servisu. Ovo može drastično da smanji šanse za uspešnu eksploataciju buffer overflow-a.

Primer Snort pravila:

alert tcp any any -> any 80 (msg:"Dugački GET zahtev detektovan"; \

content:"GET "; nocase; pcre:"/^GET [^\r\n]{1000,}/"; sid:1000001; rev:1;)

U ovom primeru Snort će podići uzbunu ako detektuje GET zahtev čija je dužina veća od 1000 karaktera.

• Ograničavanje privilegija i primena SELinux-a/AppArmor-a:
  Ako ranjivi servis radi kao nezaštićeni root proces, uspešan napad znači potpunu kontrolu sistema. Međutim, ako koristite ograničene naloge i mehanizme kontrole pristupa (SELinux, AppArmor), čak i ako dođe do kompromitovanja servisa, napadač neće moći lako da pristupi ostatku sistema.

Primer konfigurisanja SELinux konteksta (na CentOS/RedHat sistemima):

# Provera trenutnog konteksta fajla

ls -Z /var/www/html/index.php

# Promena konteksta fajla

chcon -t httpd_sys_content_t /var/www/html/index.php

Na ovaj način ograničavate kakve akcije Apache (ili drugi servisi) mogu obavljati nad fajlovima.

• Praćenje logova i anomalija u mrežnom saobraćaju:
  Iznenadne greške poput SEGFAULT ili nagli rast pristupa s čudnim parametrima mogu da ukažu na aktivni pokušaj eksploatacije. Redovno pratite logove, aktivirajte alarmiranje i reagujte na vreme.

Primer pregledanja logova u realnom vremenu (Linux):

tail -f /var/log/messages

tail -f /var/log/apache2/error.log

Kada primetite učestale SEGFAULT poruke ili neobične HTTP zahteve, važno je da odmah pokrenute detaljniju istragu.

• Izolacija i segmentacija mreže:
  U slučaju da jedan server postane kompromitovan, segmentirana mreža onemogućava napadaču da lako pristupi drugim sistemima i bazama podataka.

Primer segmentacije pomoću iptables (pojednostavljen primer):

# Polisa da se sav saobraćaj odbija, osim onog koji je eksplicitno dozvoljen

iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT ACCEPT

# Dozvoljen SSH pristup samo s određene IP adrese

iptables -A INPUT -p tcp -s 10.0.0.5 --dport 22 -j ACCEPT

# Dozvoljen HTTP saobraćaj samo ka web serveru

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Ovako pravite dodatne prepreke unutar mreže i štitite kritične servise od neovlašćenih pristupa.

Zaključak

Kao što ste videli, buffer overflow predstavlja ozbiljan bezbednosni propust koji nastaje kada program upiše više podataka nego što je predviđeno u rezervisanom prostoru (baferu). 

Iako današnji programski jezici uglavnom imaju dobru zaštitu od ovakve ranjivosti, buffer overflow i dalje predstavlja opasnost, posebno kod C i C++ programskih jezika, zbog načina na koji upravljaju memorijom. 

Da bi ste umanjili rizik od buffer overflow-a, dobra praksa je da koristite tehnike poput nasumičnog raspoređivanja memorije (ASLR), onemogućavanja izvršavanja u određenim segmentima (NX/DEP), SSP-a, kao i proverene bezbednosne funkcije (fgets, strncpy i dr.). 

Redovno ažuriranje softvera, pravilno upravljanje privilegijama, revizija koda i testiranje takođe su ključni koraci u zaštiti od ove vrste napada.