TL;DR. U ovom članku istražujemo sheme zaštite (hardening schemes) koje su ugrađene u pet popularnih Linux distribucija. Za svaku od njih uzeli smo konfiguraciju jezgre prema zadanim postavkama, preuzeli sve pakete i analizirali sheme zaštite unutar binarnih datoteka. Razmatrane su distribucije OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 i 7, kao i Ubuntu 14.04, 12.04 i 18.04 LTS.

Rezultati potvrđuju da čak i osnovne sheme, poput kanarinskog steka i koda neovisnog o položaju, još uvijek nisu u potpunosti korištene. Situacija je još gora kod kompajlera, kada je riječ o zaštiti od ranjivosti kao što je sudar steka (stack clash), koje su došle u središte pažnje u siječnju nakon objave informacija o ranjivostima u systemd. No, nije sve tako beznadno. U značajnom dijelu binarnih datoteka implementirane su osnovne metode zaštite, a njihov broj raste iz verzije u verziju.

Istraživanje je pokazalo da je najveći broj metoda zaštite implementiran u Ubuntu 18.04 na razini operativnog sustava i aplikacija, zatim slijedi Debian 9. S druge strane, OpenSUSE 12.4, CentOS 7 i RHEL 7 također imaju implementirane osnovne sheme zaštite, a zaštita od sudara steka primjenjuje se još šire uz mnogo gušći skup paketa prema zadanim postavkama.

Uvod

Teško je osigurati visoku kvalitetu softvera. Unatoč ogromnom broju naprednih alata za statičku analizu koda i dinamičku analizu tijekom izvođenja, kao i značajnom napretku u razvoju kompajlera i jezika programiranja, suvremeni softver još uvijek pati od ranjivosti koje se neprekidno eksploatiraju od strane napadača. Situacija je još gora u ekosustavima koji uključuju zastarjeli kod. U takvim slučajevima ne samo da se suočavamo s vječnim problemom otkrivanja mogućih eksploatabilnih grešaka, već smo i ograničeni strogim okvirima unazadne kompatibilnosti, koji često zahtijevaju očuvanje ograničenog, a još gore ranjivog ili kvarnog koda.

Tu na scenu stupaju metode zaštite ili pojačanja softvera (hardening). Neke vrste grešaka ne možemo spriječiti, ali možemo otežati život napadaču i djelomično riješiti problem sprečavajući ili ometajući. iskorištavanja ovih grešaka. Ova zaštita se koristi u svim modernim operativnim sustavima, ali se metode uvelike razlikuju po složenosti, efikasnosti i performansama: od stog kanarinca (stack canaries) i ASLR do potpune zaštite CFI i ROP. U ovom članku ćemo raspraviti koje metode zaštite se primenjuju u najpopularnijim distribucijama Linuxa u podrazumevanju, kao i istražiti svojstva binarnih datoteka koje se distribuiraju putem sistema za upravljanje paketima svake distribucije.

CVE i sigurnost

Svi smo videli članke sa naslovima poput "Najranjivijih aplikacija godine" ili "Najranjivijih operativnih sistema". Obično se navodi statistika o ukupnom broju zapisa o ranjivostima tipa CVE (Common Vulnerability and Exposures), dobijenih iz Nacionalne baze ranjivosti (NVD) od NIST i drugih izvora. Nakon toga, ove aplikacije ili OS-ovi se rangiraju prema broju CVE. Nažalost, iako su CVE veoma korisni za praćenje problema i obaveštavanje dobavljača i korisnika, malo govore o stvarnoj sigurnosti softvera.

Na primer, razmotrimo ukupan broj CVE u protekle četiri godine za Linux kernel i pet najpopularnijih server distribucija, a to su Ubuntu, Debian, Red Hat Enterprise Linux i OpenSUSE.

Sl. 1

Šta nam govori ova grafika? Znači li veći broj CVE da je jedna distribucija ranjivija od druge? Odgovor je ne. Na primer, u ovom članku ćete videti da Debian ima strože mehanizme zaštite u poređenju, recimo, s OpenSUSE ili RedHat Linuxom, a ipak Debian ima više CVE. Međutim, to ne znači nužno slabiju sigurnost: čak i postojanje CVE ne govori da li je ranjivost eksploatisana. Bodovi ozbiljnosti daju uvid u to koliko je verovatno iskorišćavanje ranjivosti, ali na kraju, eksploatabilnost u velikoj meri zavisi od zaštite prisutne u pogođenim sistemima, kao i od resursa i mogućnosti napadača. Štaviše, odsustvo CVE izveštaja ne govori ništa o drugim registriranim ili nepoznatim ranjivostima. Razlika u CVE može se objasniti ne kvalitetom softvera, već drugim faktorima, uključujući resurse dodijeljene za testiranje ili veličinu korisničke baze. U našem primjeru veći broj CVE u Debiánu može jednostavno ukazivati na to da Debian pruža više paketa softvera.

Naravno, CVE sustav pruža korisne informacije koje omogućuju izradu odgovarajućih zaštita. Što bolje razumijemo uzroke programskih grešaka, lakše je odrediti moguće načine iskorištavanja i razviti odgovarajuće mehanizme otkrivanja i reagiranja. Na slikama 2 prikazane su kategorije ranjivosti za sve distribucije u posljednje četiri godine (izvor). Odmah je vidljivo da većina CVE spada u sljedeće kategorije: uskraćivanje usluga (DoS), izvršavanje koda, prelivanja, oštećenje memorije, curenje (ekstrakcija) informacija i eskalacija privilegija. Iako su mnogi CVE zabilježeni više puta u različitim kategorijama, u cjelini se isti problemi zadržavaju iz godine u godinu. U sljedećem dijelu članka ocijenit ćemo korištenje različitih shema zaštite za sprječavanje iskorištavanja navedenih ranjivosti.

Slika 2

Zadaci

U ovom članku planiramo odgovoriti na sljedeća pitanja:

• Koja je sigurnost različitih distribucija Linuxa? Koji mehanizmi zaštite postoje u kernelu i aplikacijama korisničkog prostora?
• Kako se tijekom vremena promijenila prihvaćenost mehanizama zaštite za različite distribucije?
• Koje su prosječne zavisnosti paketa i biblioteka svake distribucije?
• Koje su zaštite implementirane za svaki binarni paket?

Odabir distribucija

Ispostavlja se da je teško pronaći točnu statistiku o instalacijama distribucija, budući da u većini slučajeva broj preuzimanja ne ukazuje na broj stvarnih instalacija. Ipak, Unix opcije čine većinu serverskih sistema (na web poslužiteljima 69,2%, prema statistikama W3techs i drugim izvorima), a njihov udio stalno raste. Stoga smo se za naše istraživanje fokusirali na distribucije dostupne iz kutije na platformi Google Cloud. Konkretno, odabrali smo sljedeće OS:

Distribucija/verzija
Jezgra
Gradnja

OpenSUSE 12.4
4.12.14-95.3-default
#1 SMP Wed Dec 5 06:00:48 UTC 2018 (63a8d29)

Debian 9 (stretch)
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018-10-27)

CentOS 6.10
2.6.32-754.10.1.el6.x86_64
#1 SMP Tue Jan 15 17:07:28 UTC 2019

CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP Fri Feb 1 14:54:57 UTC 2019

Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP Wed Nov 21 15:08:21 EST 2018

Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP Thu Nov 15 17:36:42 UTC 2018

Ubuntu 14.04 (Trusty Tahr)
4.4.0–140-generic

#166~14.04.1-Ubuntu SMP Sat Nov 17 01:52:43 UTC 20…

Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP Fri Dec 7 09:59:47 UTC 2018

Ubuntu 18.04 (Bionic Beaver)
4.15.0–1026-gcp
#27-Ubuntu SMP Thu Dec 6 18:27:01 UTC 2018

Tablica 1

Analiza

Istražit ćemo zadanu konfiguraciju jezgre, kao i svojstva paketa dostupnih kroz paketni menadžer svakog distribucije 'iz kutije'. Tako ćemo razmotriti samo pakete iz zadnjih zrcala svake distribucije, ignorirajući pakete iz nestabilnih repozitorija (primjerice, zrcala 'testing' u Debianu) i vanjske pakete (na primjer, pakete Nvidia sa standardnih zrcala). Osim toga, nećemo razmatrati korisničke kompilacije jezgre ili konfiguracije s pojačanom zaštitom.

Analiza konfiguracije jezgre

Primijenili smo skriptu za analizu temeljenu na slobodnom provjerivaču kconfig. Razmatramo opcije zaštite 'iz kutije' za navedene distribucije i uspoređujemo ih s popisom od Projekta samopomoći jezgre (KSPP). Za svaku opciju konfiguracije, Tablica 2 opisuje željenu postavku: kvačica označava distribucije koje se pridržavaju preporuka KSSP (objašnjenje pojmova vidi ovdje; u budućim člancima ćemo objasniti kako su se mnoge od ovih metoda zaštite pojavile i kako ugroziti sustav u njihovoj odsutnosti).

U cjelini, nove jezgre imaju strože postavke 'iz kutije'. Na primjer, kod CentOS 6.10 i RHEL 6.10 sa jezgrom 2.6.32 nedostaju većina kritičnih funkcija implementiranih u novim jezgrama, kao što su SMAP, stroge dozvole RWX, randomizacija adresa ili zaštita copy2usr. Treba napomenuti da mnoge opcije konfiguracije iz tablice nedostaju u starijim verzijama jezgre i nisu primjenjive u stvarnosti — u tablici je to i dalje navedeno kao nedostatak adekvatne zaštite. Slično tome, ako opcija konfiguracije nedostaje u ovoj verziji, a za sigurnost ju je potrebno onemogućiti, to se smatra razumnom konfiguracijom.

Još jedna stvar pri tumačenju rezultata: neke konfiguracije jezgre koje povećavaju površinu napada mogu se istovremeno koristiti za sigurnost. Takvi primjeri uključuju uprobes i kprobes, module jezgre i BPF/eBPF. Naša preporuka je koristiti navedene mehanizme za osiguranje stvarne zaštite, budući da su netrivijalni za upotrebu, a njihova eksploatacija podrazumijeva da su zlonamjerni subjekti već uspostavljeni u sustavu. No, ako su te opcije uključene, sistemski administrator treba aktivno pratiti zloupotrebe.

Daljnjim proučavanjem unosa u tablici 2, vidimo da moderna jezgra nude nekoliko opcija za zaštitu od eksploatacije takvih ranjivosti kao što su curenje informacija i prelivanje stoga/heap-a. Ipak, primjećujemo da čak ni najnovije popularne distribucije još nisu implementirale složeniju zaštitu (na primjer, s ispravkama grsecurity) ili modernu zaštitu od napada ponovne upotrebe koda (na primjer, kombinaciju randomizacije sa shemama tipa R^X za kod). Što je još gore, čak ni ovi napredniji alati zaštite ne štite od cijelog spektra napada. Stoga je za sistemske administratore od iznimne važnosti dopuniti razumnu konfiguraciju rješenjima koja nude otkrivanje i sprječavanje eksploatacija tijekom izvođenja.

Analiza aplikacija

Nije iznenađujuće što različite distribucije imaju različite karakteristike paketa, opcije kompajliranja, zavisnosti biblioteka itd. Razlike postoje čak i za rodne distribucije i pakete s malim brojem zavisnosti (na primjer, coreutils u Ubuntu ili Debian). Kako bismo procijenili razlike, preuzeli smo sve dostupne pakete, izdvojili njihovu sadržinu i analizirali binarne datoteke i zavisnosti. Za svaki paket pratili smo druge pakete od kojih ovisi, a za svaku binarnu datoteku pratili smo njene zavisnosti. U ovom odjeljku ukratko ćemo iznijeti zaključke.

Distribucije

Ukupno smo preuzeli 361.556 paketa za sve distribucije, izvlačeći samo pakete sa zrcala prema zadanim postavkama. Ignorirali smo pakete bez izvršnih ELF datoteka, poput izvornog koda, fontova itd. Nakon filtriranja ostalo je 129.569 paketa koji sadrže ukupno 584.457 binarnih datoteka. Distribucija paketa i datoteka po distribucijama prikazana je na slici 3.

Sl. 3

Može se primijetiti da što je distribucija modernija, to ima više paketa i binarnih datoteka, što je logično. Međutim, paketi Ubuntu i Debian uključuju mnogo više binarnih datoteka (kako izvršivih, tako i dinamičkih modula i biblioteka) nego CentOS, SUSE i RHEL, što potencijalno utječe na površinu napada Ubuntu i Debiana (valja napomenuti da brojke odražavaju sve binarije svih verzija paketa, odnosno neki se datoteke analiziraju više puta). Ovo je posebno važno uzimajući u obzir ovisnosti između paketa. Tako ranjivost u binariji jednog paketa može utjecati na mnoge dijelove ekosustava, dok ranjiva biblioteka može utjecati na sve binarne datoteke koje je uvoze. Kao referencu, pogledajmo distribuciju broja ovisnosti po paketima u različitim OS-ovima:

Sl. 4

U gotovo svim distribucijama 60% paketa ima najmanje 10 ovisnosti. Osim toga, neki paketi imaju značajno više ovisnosti (više od 100). Isto vrijedi i za povratne ovisnosti paketa: kao što se i očekivalo, nekoliko paketa koristi mnogo drugih paketa u distribuciji, pa ranjivosti u tim nekolicinama imaju visoki rizik. Kao primjer, u sljedećoj tablici navedeno je 20 paketa s maksimalnim brojem povratnih ovisnosti u SLES, CentOS 7, Debian 9 i Ubuntu 18.04 (u svakoj ćeliji navode se paket i broj povratnih ovisnosti).

Tablica 3

Zanimljiva činjenica. Iako su svi analizirani OS-ovi izgrađeni za arhitekturu x86_64, a većina paketa ima arhitekturu definiranu kao x86_64 i x86, paketi često sadrže binarne datoteke za druge arhitekture, kao što je prikazano na slici 5.

Slika 5

U sljedećem odjeljku produbiti ćemo se u karakteristike analiziranih binarnih datoteka.

Statistika zaštite binarnih datoteka

Kao apsolutni minimum, potrebno je proučiti osnovni set opcija zaštite za postojeće binarne datoteke. Nekoliko Linux distribucija dolazi sa skriptama koje obavljaju takve provjere. Na primjer, u Debianu/Ubuntu postoji takva skripta. Evo primjera njenog rada:

$ hardening-check $(which docker)
/usr/bin/docker:
 Pozicija neovisna izvršna datoteka: da
 Zaštita staka: da
 Fortify Source funkcije: ne, pronađene samo nezaštićene funkcije!
 Samo za čitanje relokacije: da
 Neposredna vezivanje: da

Skripta provjerava pet funkcija zaštite:

• Pozicija neovisna izvršna datoteka (PIE): označava je li moguće premjestiti odjeljak s kodom programa u memoriji kako bi se postigla nasumičnost, ako je ASLR uključena u jezgru.
• Zaštita staka: je li omogućena zaštita od napada kroz kanarince na staku.
• Fortify Source: zamjenjuju li se nesigurne funkcije (na primjer, strcpy) njihovim sigurnijim analogama, a pozivi koji se provjeravaju u vrijeme izvođenja – njihovim neprovjeravanim analogama (na primjer, memcpy umjesto __memcpy_chk).
• Relokacije samo za čitanje (RELRO): jesu li unosi u tablici premještanja označeni kao „samo za čitanje“, ako su aktivirani prije početka izvođenja.
• Neposredna vezivanje (immediate binding): omogućuje li dinamički linker sve premještaje prije početka izvođenja programa (to je ekvivalentno potpunom RELRO-u).

Jesu li dovoljni navedeni mehanizmi? Nažalost, nisu. Poznate su metode za zaobilaženje svih navedenih zaštita, ali što je zaštita jača, to je viša granica za napadača. Na primjer, metode zaobilaženja RELRO-a teže je primijeniti ako su aktivni PIE i neposredna vezivanje. Slično tome, potpuni ASLR zahtijeva dodatni rad za stvaranje radnog eksploita. Međutim, sofisticirani zlonamjernici već su spremni za takve zaštite: njihovo odsustvo zapravo ubrzava napad. Stoga je izuzetno važno da se ove mjere smatraju nužnim minimumom.

Željeli smo istražiti koliko su mnoge binarne datoteke u razmatranim distribucijama zaštićene ovim, kao i još tri metode:

• Neizvršni bit (NX) sprječava izvršavanje u bilo kojem području koje ne bi trebalo biti izvršno, na primjer, u hrpi, na staku itd.
• RPATH/RUNPATH označava put izvođenja koji dinamički učitavač koristi za pronalaženje odgovarajućih biblioteka. Prvi je obavezan za svaki moderni sustav: njegovo odsustvo omogućuje napadačima da slobodno upisuju teret u memoriju i izvršavaju ga kao takvog. U drugom slučaju, netočne konfiguracije putanje izvršenja pomažu u uvođenju nepouzdanog koda, što može dovesti do niza problema (na primjer, eskalacija privilegija, kao i druge poteškoće).
• Zaštita od preklapanja stoga osigurava zaštitu od napada koji uzrokuju da se stog preklopi s drugim područjima memorije (na primjer, na hrpu). Uzimajući u obzir nedavne eksploite koji iskorištavaju ranjivosti preklapanja hrpe u systemd, smatrali smo prikladnim uključiti ovaj mehanizam u naš skup podataka.

Dakle, bez daljnjeg odgađanja, prijeđimo na brojke. Tablice 4 i 5 sadrže sažetak analize izvršnih datoteka i biblioteka različitih distribucija, redom.

• Kao što se može primijetiti, NX zaštita je implementirana svugdje, uz rijetke iznimke. Konkretno, može se primijetiti nešto niža implementacija u distribucijama Ubuntu i Debian u usporedbi s CentOS-om, RHEL-om i OpenSUSE-om.
• Stogovi kanarinca su u velikoj mjeri odsutni, posebno u distribucijama sa starim kernelima. Neki napredak zabilježen je u posljednjim distribucijama CentOS-a, RHEL-a, Debiana i Ubuntua.
• Osim Debiana i Ubuntua 18.04, većina distribucija slabo podržava PIE.
• Zaštita od preklapanja stoga slabo je implementirana u OpenSUSE-u, CentOS-u 7 i RHEL-u 7, dok praktički ne postoji kod ostalih.
• Sve distribucije s modernim kernelima imaju neku podršku za RELRO, pri čemu prednjači Ubuntu 18.04, a drugo mjesto zauzima Debian.

Kao što je već spomenuto, metrike u ovoj tablici su prosjeke za sve verzije binarne datoteke. Ako se gledaju samo najnovije verzije datoteka, brojevi će biti drugačiji (na primjer, pogledajte napredak Debiana s uvođenjem PIE). Štoviše, većina distribucija obično pri izračunu statistike provjerava zaštitu samo nekoliko funkcija u binarnoj datoteci, a u našoj analizi navedeni su stvarni postotci ojačanih funkcija. Dakle, ako je u binarnoj datoteci zaštićeno 5 od 50 funkcija, dodijelit ćemo mu ocjenu 0,1, što odgovara 10% ojačanih funkcija.

Tablica 4. Značajke zaštite za izvršne datoteke prikazane na slici 3 (implementacija odgovarajućih funkcija u postotcima od ukupnog broja izvršnih datoteka)

Tablica 5. Karakteristike zaštite za biblioteke prikazane na sl. 3 (implementacija odgovarajućih funkcija u procentima od ukupnog broja biblioteka)

Dakle, ima napretka? Definitivno ima: to se može vidjeti iz statistike za pojedinačne distribucije (na primjer, Debian), kao i iz gornjih tabela. Kao primjer, na sl. 6 prikazana je implementacija zaštitnih mehanizama u tri uzastopne distribucije Ubuntu LTS 5 (izostavili smo statistiku zaštite od sukoba steka). Primjećujemo da iz verzije u verziju sve više datoteka podržava kanarince steka, a također se postepeno sve više binarnih datoteka isporučuje s potpunom zaštitom RELRO.

Sl. 6

Nažalost, niz izvršnih datoteka u različitim distribucijama i dalje nema nijednu od gore navedenih zaštita. Na primjer, kada pogledate Ubuntu 18.04, možete primijetiti binarno datoteku ngetty (zamjena za getty), kao i ljuske mksh i lksh, interpreter picolisp, pakete nvidia-cuda-toolkit (popularni paket za aplikacije s GPU ubrzanjem, kao što su okviri za mašinsko učenje) i klibc-utils. Slično, binarna datoteka mandos-client (administrativni alat koji omogućava automatsko ponovo pokretanje računara sa šifriranim datotečnim sistemima), kao i rsh-redone-client (ponovna implementacija rsh i rlogin) isporučuju se bez zaštite NX, iako imaju SUID prava :(. Štaviše, u nekoliko SUID binarnih datoteka nedostaje osnovna zaštita poput kanarinca steka (na primjer, binarna datoteka Xorg.wrap iz paketa Xorg).

Sažetak i konačne napomene

U ovom članku istaknuli smo nekoliko sigurnosnih osobina modernih Linux distribucija. Analiza je pokazala da najnovija LTS distribucija Ubuntu (18.04) pruža, u prosjeku, najsnažniju zaštitu na razini operativnog sustava i aplikacija među distribucijama s relativno novim jezgrama, kao što su Ubuntu 14.04, 12.04 i Debian 9. Međutim, razmatrane distribucije CentOS, RHEL i OpenSUSE u našem skupu podataka zadano nude gusto pakiranje paketa, a u najnovijim verzijama (CentOS i RHEL) imaju viši postotak implementacije zaštite od sudara steka, u usporedbi s konkurentima temeljenim na Debianku (Debian i Ubuntu). U usporedbi verzija CentOS i RedHat primjećujemo velika poboljšanja u implementaciji kanarinca steka i RELRO s verzija 6 na 7, ali u prosjeku je u CentOS-u implementirano više funkcija nego u RHEL-u. Sveukupno, svim distribucijama treba posvetiti posebnu pažnju zaštiti PIE, koja je, osim Debiana 9 i Ubuntua 18.04, implementirana u manje od 10% binarnih datoteka iz našeg skupa podataka.

Na kraju, treba napomenuti: iako smo ručno proveli istraživanje, postoji mnogo sigurnosnih alata (npr., Lynis, Tiger, Hubble), koji obavljaju analizu i pomažu u izbjegavanju nesigurnih konfiguracija. Nažalost, čak i snažna zaštita u razumnim konfiguracijama ne jamči odsutnost exploita. Zato čvrsto vjerujemo da je od vitalne važnosti osigurati pouzdano praćenje i sprječavanje napada u stvarnom vremenu, fokusirajući se na obrasce eksploatacije i sprječavajući ih.

Izvor: habr.com