TL;DR. U ovom članku istražujemo mehanizme zaštite (hardening schemes) koji po defaultu funkcionišu u pet popularnih Linux distribucija. Za svaku od njih uzeli smo podrazumevanu konfiguraciju jezgra, instalirali sve pakete i analizirali mehanizme zaštite u ugniježdenim binarnim datotekama. Razmatrani 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 ni osnovni mehanizmi, kao što su kanarinske stekove i kod nezavisnog od pozicije, još uvek nisu svuda primenjeni. Situacija je još gora sa kompajlerima kada se radi o zaštiti od ranjivosti poput stack clash-a, koja je postala u fokusu u januaru nakon objavljivanja informacija o ranjivostima u systemd. Ali nije sve tako beznadežno. U značajnom delu binarnih datoteka implementirane su osnovne metode zaštite, a njihov broj raste iz verzije u verziju.

Provera je pokazala da je najveći broj metoda zaštite implementiran u Ubuntu 18.04 na nivou operativnog sistema i aplikacija, a zatim sledi Debian 9. S druge strane, u OpenSUSE 12.4, CentOS 7 i RHEL 7 takođe su implementovani osnovni mehanizmi zaštite, dok se zaštita od stash clash-a primenjuje još šire uz mnogo veću gustinu paketa po defaultu.

Uvod

Teško je obezbediti visoki kvalitet softvera. I pored ogromnog broja naprednih alata za statičku analizu koda i dinamičku analizu tokom izvođenja, kao i značajnog napretka u razvoju kompajlera i programskih jezika, savremeni softver i dalje pati od ranjivosti koje kontinuirano eksploatišu napadači. Situacija je još gora u ekosistemima koji uključuju zastareli kod. U takvim slučajevima se ne suočavamo samo sa večitim problemom otkrivanja mogućih ranjivosti, već smo i ograničeni strogim okvirima unazadne kompatibilnosti, koji često zahtevaju očuvanje ograničenog, a još gore ranjivog ili buggiranog koda.

Ovde dolaze u obzir mehanizmi zaštite ili jačanja softvera (hardening). Neke tipove grešaka ne možemo sprečiti, ali možemo učiniti život napadačima težim i delimično rešiti problem sprečavanjem ili ometanjem eksploatacije teh napak. Ta zaščita se uporablja v vseh sodobnih operacijskih sistemih, vendar se metode močno razlikujejo po zahtevnosti, učinkovitosti in zmogljivosti: od stekleničnih kanarčkov (stack canaries) in ASLR do popolnih zaščit CFI in ROP. V tem članku bomo preučili, katere zaščitne metode se uporabljajo v najbolj priljubljenih različicah Linuxa z privzetimi nastavitvami ter raziskali lastnosti binarnih datotek, ki se distribuira preko sistemov za upravljanje s paketi posameznih distribucij.

CVE in varnost

Vsi smo videli članke s naslovi, kot so 'Najbolj ranljive aplikacije leta' ali 'Najbolj ranljivi operacijski sistemi'. Običajno vsebujejo statistiko o skupnem številu zapisov o ranljivostih tipa CVE (Skupne ranljivosti in izpostavljenosti), pridobljenih iz Nacionalne baze ranljivosti (NVD) od NIST in drugih virov. Kasneje so te aplikacije ali OS razvrščeni glede na število CVE. Nažalost, čeprav so CVE zelo uporabni za sledenje težavam in obveščanje dobaviteljev in uporabnikov, malo povedo o dejanski varnosti programske opreme.

Za primer si oglejmo skupno število CVE v zadnjih štirih letih za jedro Linuxa in pet najbolj priljubljenih strežniških distribucij, in sicer Ubuntu, Debian, Red Hat Enterprise Linux in OpenSUSE.

Slika 1

Kaj nam pove ta grafikon? Ali pomeni večje število CVE, da je ena distribucija bolj ranljiva od druge? Odgovor je negativen. Na primer, v tem članku boste videli, da so v Debiánu uvedeni strožji zaščitni mehanizmi v primerjavi, recimo, z OpenSUSE ali RedHat Linux, pa vendar ima Debian več CVE. Vendar ti ne pomenijo nujno oslabljene varnosti: celo prisotnost CVE ne pove, ali je ranljivost eksplotabilna. Točke resnosti dajejo predstavo o tem, kako verjetno je izkoriščanje ranljivosti, toda na koncu je izkoriščenost v veliki meri odvisna od zaščite, ki je prisotna v prizadetih sistemih, ter od virov in zmogljivosti napadalcev. Poleg tega, odsotnost poročil CVE ne pove ničesar o drugih neregistriranih ali neznanih. ranah. Razlika u CVE može se objašnjavati ne kvalitetom softvera, već drugim faktorima, uključujući resurse odvojene za testiranje ili veličinu korisničke baze. U našem primeru, veći broj CVE u Debianu može jednostavno značiti da Debian isporučuje više paketa softvera.

Naravno, sistem CVE pruža korisne informacije koje omogućavaju stvaranje odgovarajućih zaštita. Što bolje razumemo uzroke programskih grešaka, to je lakše odrediti moguće načine eksploatacije i razviti odgovarajuće mehanizme otkrivanja i reagovanja.Na slici 2 prikazane su kategorije ranjivosti za sve distribucije tokom poslednje četiri godine (vir). Odmah se vidi da većina CVE spada u sledeće kategorije: uskraćivanje usluge (DoS), izvršenje koda, prelivanje, oštećenje memorije, curenje (ekstrahiranje) informacija i eskalacija privilegija. Iako su mnoge CVE zabeležene više puta u različitim kategorijama, u celini, isti problemi se ponavljaju iz godine u godinu. U sledećem delu članka ocenjujemo korišćenje različitih shema zaštite za sprečavanje eksploatacije navedenih ranjivosti.

Slika 2

Zadaci

U ovom članku nameravamo da odgovorimo na sledeća pitanja:

• Kakva je sigurnost različitih Linux distribucija? Koji zaštitni mehanizmi postoje u jezgru i aplikacijama korisničkog prostora?
• Kako se tokom vremena menjala prihvaćenost zaštitnih mehanizama za različite distribucije?
• Koje su prosečne zavisnosti paketa i biblioteka svake distribucije?
• Koje su zaštite implementirane za svaku binarnu datoteku?

Izbor distribucija

Ispostavlja se da je teško pronaći tačnu statistiku o instalacijama distribucija, jer u većini slučajeva broj preuzimanja ne ukazuje na broj stvarnih instalacija. Ipak, Unix varijante čine većinu serverskih sistema (na web serverima 69,2%, prema statistiki W3techs i drugim izvorima), i njihov udeo neprekidno raste. Tako da smo se za naše istraživanje fokusirali na distribucije koje su ponuđene iz kutije na platformi Google Cloud. Konkretno, izabrali smo sledeće OS:

Distribucija/verzija
Jedro
Izgradnja

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

Tabela 1

Analiza

Razićemo konfiguraciju jezgra prema zadanim postavkama, kao i osobine paketa dostupnih putem upravitelja paketa svakog distribucije 'out-of-the-box'. Tako ćemo razmotriti samo pakete iz zrcala po defaultu svake distribucije, ignorirajući pakete iz nestabilnih repozitorija (kao što su zrcala 'testing' u Debiane) i vanjske pakete (na primjer, Nvidia pakete iz standardnih zrcala). Nadalje, nećemo razmatrati korisničke kompilacije jezgra ili konfiguracije s pojačanom zaštitom.

Analiza konfiguracije jezgra

Primijenili smo skriptu analize temeljenoj na slobodnom provjeravaču kconfig. Istražujemo zadanju zaštitne postavke kod navedenih distribucija i uspoređujemo ih s popisom iz Projekta samozaštite jezgra (KSPP). Za svaku postavku konfiguracije, tabela 2 opisuje željenu postavku: kvačica označava distribucije koje ispunjavaju preporuke KSSP (objašnjenje termina može se vidjeti ovde; u budućim člancima ćemo objasniti kako su se pojavile mnoge od ovih metoda zaštite i kako hakirati sustav u njihovoj odsutnosti).

Općenito, nova jezgra imaju strože postavke iz kutije. Na primjer, CentOS 6.10 i RHEL 6.10 sa jezgrom 2.6.32 nemaju većinu kritičnih funkcionalnosti koje su implementirane u novijim jezgrama, poput SMAP, stroge RWX dozvole, randomizaciju adresa ili zaštitu copy2usr. Treba napomenuti da mnoge od opcija konfiguracije iz tabele nedostaju u starijim verzijama jezgre i nisu primjenjive u praksi — nastavlja se navoditi kao nedostatak odgovarajuće zaštite. Slično, ako parametar konfiguracije nedostaje u ovoj verziji, a za sigurnost trebate isključiti taj parametar, smatra se razumnom konfiguracijom.

Še en vidik pri interpretaciji rezultatov: nekatere konfiguracije jedra, ki povečujejo površino napada, se lahko hkrati uporabljajo za varnost. Takšni primeri vključujejo uprobes in kprobes, module jedra ter BPF/eBPF. Naša priporočila se osredotočajo na uporabo zgoraj omenjenih mehanizmov za zagotavljanje dejanske zaščite, saj so ti zapleteni za uporabo in njihova izkoriščenost pomeni, da so zlonamerni subjekti že zakoreninjeni v sistemu. Vendar pa, če so ti parametri vključeni, mora sistemski skrbnik aktivno spremljati zlorabe.

Ob nadaljnjem pregledu zapisov iz tabele 2 ugotavljamo, da sodobna jedra ponujajo več možnosti za zaščito pred izkoriščanjem takšnih ranljivosti, kot sta uhajanje informacij in prelivanje sklada/ščepe. Vendar opazimo, da še najnovejši priljubljeni distribucijski sistemi še niso uvedli bolj zapletene zaščite (na primer s popravki grsecurity) ali sodobne zaščite pred napadi ponovne uporabe kode (na primer, kombinacija randomizacije s shemami tipa R^X za kodo). Kar je še huje, tudi ti naprednejši varnostni mehanizmi ne ščitijo pred celotnim spektrom napadov. Tako je skrbnikom sistemov izjemno pomembno, da razumne konfiguracije dopolnijo z rešitvami, ki ponujajo odkrivanje in preprečevanje izkoriščanj med izvajanjem.

Analiza aplikacij

Ni presenetljivo, da imajo različni distribucijski sistemi različne značilnosti paketov, možnosti prevajanja, odvisnosti knjižnic itd. Razlike obstajajo celo med sorodnimi distribucijami in paketi z malo odvisnostmi (na primer coreutils v Ubuntu ali Debian). Da bi ocenili razlike, smo prenesli vse razpoložljive pakete, izvlekli njihovo vsebino in analizirali binarne datoteke ter odvisnosti. Za vsak paket smo spremljali druge pakete, od katerih je odvisen, in za vsak binarni element spremljali njegove odvisnosti. V tem razdelku bomo na kratko povzemali ugotovitve.

Distribucije

Skupaj smo naložili 361.556 pakotov za vse distribucije, pri čemer smo izvlekli samo pakete z privzetih ogledal. Ignorirali smo pakete brez izvršnih datotek ELF, kot so izvorne kode, pisave itd. Po filtriranju je ostalo 129.569 paketov, ki vsebujejo skupno 584.457 binarnih datotek. Porazdelitev paketov in datotek po distribucijah je prikazana na sl. 3.

Sl. 3

Opaziti je mogoče, da imajo novejše distribucije več paketov in binarnih datotek, kar je logično. Paketi Ubuntu in Debian vključujejo znatno več binarnih datotek (tako izvršnih kot dinamičnih modulov in knjižnic) kot CentOS, SUSE in RHEL, kar potencialno vpliva na površino napada Ubuntu in Debian (pomembno je opozoriti, da številke odražajo vse binarike vseh različic paketa, torej se nekatere datoteke analizirajo večkrat). To je še posebej pomembno, če upoštevamo odvisnosti med paketi. Odkritje ranljivosti v binarni datoteki enega paketa lahko vpliva na mnoge dele ekosistema, tako kot ranljiva knjižnica lahko vpliva na vse binarne datoteke, ki jo uvažajo. Kot izhodišče si oglejmo porazdelitev števila odvisnosti po paketih v različnih operacijskih sistemih:

Sl. 4

Skoraj v vseh distribucijah ima 60 % paketov najmanj 10 odvisnosti. Poleg tega imajo nekateri paketi znatno več odvisnosti (več kot 100). Enako velja za povratne odvisnosti paketov: kot je bilo pričakovano, več paketov uporablja mnoge druge pakete v distribuciji, zato je tveganje za ranljivosti v teh redkih izbrancih visoko. Kot primer v naslednji tabeli navajamo 20 paketov z največ povratnimi odvisnostmi v SLES, Centos 7, Debian 9 in Ubuntu 18.04 (v vsaki celici je navedena oznaka paketa in število povratnih odvisnosti).

Tabela 3

Zanimiva dejstvo. Čeprav so vsi analizirani operacijski sistemi zgrajeni za arhitekturo x86_64, in ima večina paketov arhitekturo definirano kot x86_64 in x86, pa paketi pogosto vsebujejo binarne datoteke za druge arhitekture, kot je prikazano na sl. 5.

Sl. 5

V naslednjem razdelku se poglobimo v značilnosti analiziranih binarnih datotek.

Statistika zaščite binarnih datotek

Kot absolutni minimum je treba proučiti osnovni nabor možnosti zaščite za obstoječe binarne datoteke. Nekateri Linux distribucije prihajajo s skripti, ki izvajajo take preglede. Na primer, v Debianu/Ubuntuu obstaja tak skript. Tukaj je primer njegove uporabe:

$ hardening-check $(which docker)
/usr/bin/docker:
 Neodvisna izvršljiva datoteka: ja
 Zaslon zaščiten: ja
 Fortify Source funkcije: ne, najdene so le ne zaščitene funkcije!
 Najprej samo za branje: ja
 Takojšnje povezovanje: ja

Skript preverja pet zaščitnih funkcij:

• Neodvisna izvršljiva datoteka (PIE): kaže, ali je mogoče v pomnilniku premakniti besedilni oddelek programa, da bi dosegli naključnost, če je v jedru omogočen ASLR.
• Zaslon zaščiten: ali so zajeti zaščitni kanarčki za zaščito pred napadi na sklad.
• Fortify Source: ali se nevarne funkcije (na primer strcpy) zamenjajo z njihovimi bolj varnimi analogi, medtem ko se pri preverjanju v času izvajanja uporabljajo njihovi nepreverjeni analogi (na primer memcpy namesto __memcpy_chk).
• Read-only relocations (RELRO): ali so vnosi v tabeli premikanja označeni kot "samo za branje", če so delovali pred začetkom izvajanja.
• Takojšnje povezovanje: ali izvajalni linker dovoli vse premike pred začetkom izvajanja programa (to je ekvivalentno popolnemu RELRO).

Ali je teh mehanizmov dovolj? Na žalost ni. Znani so načini zaobiditve vseh zgoraj navedenih zaščit, vendar višja kot je zaščita, višja je tudi meja za napadalca. Na primer, metode zaobitja RELRO so težje uporabiti, če deluje PIE in takojšnje povezovanje. Podobno, popoln ASLR zahteva dodatno delo za ustvarjanje funkcionalnega izkorišča. Vendar so sofisticirani napadalci že pripravljeni na takšne zaščite: njihovo pomanjkanje v bistvu pospeši hekerske napade. Zato je izjemno pomembno, da se te ukrepe obravnava kot nujne, minimum.

Želeli smo raziskati, koliko binarnih datotek v obravnavanih distribucijah je zaščitenih s temi, in še tremi metodami:

• Neizvršni bit (NX) preprečuje izvajanje v katerem koli območju, ki ne bi smelo biti izvršljivo, na primer na skladni kup in podobno.
• RPATH/RUNPATH označuje pot izvajanja, ki ga dinamični nalagalnik uporablja za iskanje ustreznih knjižnic. Prvi je obvezen за любой совремeni системu: её отсутствие позволяет злоумышленникам произвольно записывать полезную нагрузку в память и выполнять её как есть. Для второго неверные конфигурации пути выполнения помогают в введении ненадёжного кода, который может привести к ряду проблем (например, эскалация привилегий, kao i другие проблемы).
• Защита от столкновения стека обеспечивает защиту от атак, которые заставляют стек наложиться на другие области памяти (например, на кучу). Учитывая недавние эксплойты, злоупотребляющие уязвимостями со столкновением кучи в systemd, мы сочли уместным включить этот механизм в наш набор данных.

Итак, без дальнейших церемоний, перейдём к числам. Таблицы 4 и 5 содержат выжимку анализа исполняемых файлов и библиотек различных дистрибутивов, соответственно.

• Как можно заметить, защита NX реализована везде, за редкими исключениями. В частности, можно отметить несколько более низкое её использование в дистрибутивах Ubuntu и Debian по сравнению с CentOS, RHEL и OpenSUSE.
• Стековые канарейки много где отсутствуют, особенно в дистрибутивах со старыми ядрами. Некоторый прогресс наблюдается в последних дистрибутивах Centos, RHEL, Debian и Ubuntu.
• За исключением Debian и Ubuntu 18.04, в большинстве дистрибутивов плохая поддержка PIE.
• Защита от столкновений стека слабо реализована в OpenSUSE, Centos 7 и RHEL 7 и практически отсутствует у остальных.
• Все дистрибутивы с современными ядрами имеют некоторую поддержку RELRO, при этом лидирует Ubuntu 18.04, а второе место занимает Debian.

Как уже упоминалось, метрики в этой таблице — средние по всем версиям бинарного файла. Если смотреть только последние версии файлов, то цифры будут другими (например, см. прогресс Debian с внедрением PIE). Более того, большинство дистрибутивов обычно при подсчёте статистики проверяют защиту только нескольких функций в двоичном коде, а в нашем анализе указан истинный процент укреплённых функций. Поэтому если в бинарнике защищены 5 из 50 функций, мы укажем ему оценку 0,1, что соответствует 10% укреплённых функций.

Таблица 4. Характеристики защиты для исполняемых файлов, показанных на рис. 3 (реализация соответствующих функций в процентах от общего количества исполняемых файлов)

Tabela 5. Lastnosti zaščite za knjižnice, prikazane na sl. 3 (izvedba ustreznih funkcij v odstotkih od skupnega števila knjižnic)

Torej, napredek obstaja? Nedvomno: to je razvidno iz statistike po posameznih distribucijah (na primer, Debian), kot tudi iz zgoraj predstavljenih tabel. Kot primer slika 6 prikazuje uvedbo zaščitnih mehanizmov v treh zaporednih distribucijah Ubuntu LTS 5 (statistika zaščite pred naletom sklada je izpuščena). Opazimo, da od različice do različice vse več datotek podpira kanarčke sklada, prav tako pa tudi vse več binarnih datotek prihaja s polno zaščito RELRO.

Slika 6

Žal nekateri izvršljivi datoteki v različnih distribucijah še vedno nimajo nobene od zgoraj navedenih zaščit. Na primer, ob pogledu na Ubuntu 18.04 lahko opazite binarno datoteko ngetty (nadomestilo za getty), pa tudi lupini mksh in lksh, interpreter picolisp, pakete nvidia-cuda-toolkit (priljubljen paket za aplikacije z GPU pospešitvijo, kot so ogrodja strojnega učenja) in klibc-utils. Prav tako se binarna datoteka mandos-client (administrativno orodje, ki omogoča samodejno ponovni zagon strojev s šifriranimi datotečnimi sistemi), pa tudi rsh-redone-client (ponovna implementacija rsh in rlogin) dobavljata brez zaščite NX, čeprav imajo pravice SUID :(. Poleg tega več binarnih datotek suid nima osnovne zaščite, kot so kanarčki sklada (na primer, binarna datoteka Xorg.wrap iz paketa Xorg).

Povzetek in zaključne opombe

V tem članku smo opozorili na nekaj varnostnih lastnosti sodobnih distribucij Linuxa. Analiza je pokazala, da ima najnovejša distribucija Ubuntu LTS (18.04) povprečno najmočne zaščitne mehanizme na ravni operacijskega sistema in aplikacij med distribucijami z razmeroma novimi jedri, kot sta Ubuntu 14.04, 12.04 in Debian 9. Vendar pa obravnavane distribucije CentOS, RHEL in OpenSUSE v našem naboru podatkov privzeto nudijo bolj gosto izbiro paketov, pri čemer imajo najnovejše različice (CentOS in RHEL) višji odstotek izvedbe zaščite pred prelivanjem sklada v primerjavi s konkurenti, ki temeljijo na Debiantu (Debian in Ubuntu). Pri primerjavi različic CentOS in RedHat opažamo velike izboljšave pri uvajanju kanarčkov za sklad in RELRO z različic 6 na 7, a na splošno je v CentOS implementiranih več funkcij kot v RHEL. Na splošno bi morali vsi distribucije posvetiti posebno pozornost zaščiti PIE, ki je, razen pri Debiantu 9 in Ubuntuju 18.04, implementirana v manj kot 10% binarnih datotek iz našega nabora podatkov.

Nazadnje je treba omeniti: čeprav smo raziskavo izvedli ročno, obstaja mnogo varnostnih orodij (na primer, Lynis, Tiger, Hubble), ki izvajajo analize in pomagajo preprečevati nevarne konfiguracije. Na žalost niti močna zaščita v razumnih konfiguracijah ne zagotavlja brezizhodnosti pred izkoriščenji. Zato smo prepričani, da je izjemno pomembno zagotoviti zanesljiv nadzor in preprečevanje napadov v realnem času, osredotočajoč se na vzorce izkoriščanj in preprečujejo njihove izvedbe.

Izvor: habr.com