TL; DR. În acest articol, explorăm schemele de întărire care funcționează imediat pe cinci distribuții Linux populare. Pentru fiecare, am luat configurația implicită a nucleului, am încărcat toate pachetele și am analizat schemele de securitate din binarele atașate. Distribuțiile luate în considerare sunt OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 și 7, precum și Ubuntu 14.04, 12.04 și 18.04 LTS.
Rezultatele confirmă că nici măcar schemele de bază, cum ar fi stivuirea canarelor și codul independent de poziție, nu sunt încă adoptate de toată lumea. Situația este și mai rea pentru compilatori când vine vorba de protejarea împotriva vulnerabilităților precum stack clash, care a intrat în centrul atenției în ianuarie după publicare. . Dar nu totul este atât de fără speranță. Un număr semnificativ de binare implementează metode de protecție de bază, iar numărul lor crește de la versiune la versiune.
Analiza a arătat că cel mai mare număr de metode de protecție este implementat în Ubuntu 18.04 la nivelurile de sistem de operare și de aplicație, urmat de Debian 9. Pe de altă parte, OpenSUSE 12.4, CentOS 7 și RHEL 7 implementează, de asemenea, scheme de protecție de bază și protecție împotriva coliziunilor de stivă. este folosit și mai pe scară largă cu un set mult mai dens de pachete implicite.
Introducere
Este dificil să se asigure un software de înaltă calitate. În ciuda numărului mare de instrumente avansate pentru analiza codului static și analiza dinamică a timpului de execuție, precum și a progresului semnificativ în dezvoltarea compilatoarelor și a limbajelor de programare, software-ul modern încă suferă de vulnerabilități care sunt exploatate constant de atacatori. Situația este și mai gravă în ecosistemele care includ cod moștenit. În astfel de cazuri, nu ne confruntăm doar cu problema eternă a găsirii unor posibile erori exploatabile, dar suntem și limitați de cadre stricte de compatibilitate inversă, care adesea ne impun să păstrăm cod limitat, sau chiar mai rău, vulnerabil sau cu erori.
Aici intră în joc metodele de protecție sau de întărire a programelor. Nu putem preveni anumite tipuri de erori, dar putem îngreuna viața atacatorului și putem rezolva parțial problema prin prevenirea sau prevenirea exploatare aceste erori. O astfel de protecție este utilizată în toate sistemele de operare moderne, dar metodele diferă foarte mult în complexitate, eficiență și performanță: de la stiva canari și la protecţie deplină и . În acest articol, vom analiza ce metode de protecție sunt utilizate în cele mai populare distribuții Linux în configurația implicită și, de asemenea, vom examina proprietățile binarelor care sunt distribuite prin sistemele de management de pachete ale fiecărei distribuții.
CVE și securitate
Cu toții am văzut articole cu titluri precum „Cele mai vulnerabile aplicații ale anului” sau „Cele mai vulnerabile sisteme de operare”. De obicei, acestea oferă statistici privind numărul total de înregistrări despre vulnerabilități precum , obtinut de la din și alte surse. Ulterior, aceste aplicații sau sisteme de operare sunt clasate după numărul de CVE. Din păcate, deși CVE-urile sunt foarte utile pentru urmărirea problemelor și informarea vânzătorilor și utilizatorilor, ele spun puțin despre securitatea reală a software-ului.
Ca exemplu, luați în considerare numărul total de CVE din ultimii patru ani pentru nucleul Linux și cele mai populare cinci distribuții de server, și anume Ubuntu, Debian, Red Hat Enterprise Linux și OpenSUSE.
Fig. 1
Ce ne spune acest grafic? Un număr mai mare de CVE înseamnă că o distribuție este mai vulnerabilă decât alta? Nici un raspuns. De exemplu, în acest articol veți vedea că Debian are mecanisme de securitate mai puternice în comparație cu, de exemplu, OpenSUSE sau RedHat Linux, și totuși Debian are mai multe CVE. Cu toate acestea, ele nu înseamnă neapărat securitate slăbită: chiar și prezența unui CVE nu indică dacă o vulnerabilitate este exploatat. Scorurile de severitate oferă o indicație despre cum probabil exploatarea unei vulnerabilități, dar în cele din urmă exploatarea depinde în mare măsură de protecțiile prezente în sistemele afectate și de resursele și capacitățile atacatorilor. Mai mult, absența rapoartelor CVE nu spune nimic despre ceilalți neînregistrat sau necunoscut vulnerabilități. Diferența de CVE se poate datora altor factori decât calitatea software-ului, inclusiv resursele alocate testării sau mărimea bazei de utilizatori. În exemplul nostru, numărul mai mare de CVE al Debian poate indica pur și simplu că Debian livrează mai multe pachete software.
Desigur, sistemul CVE oferă informații utile care vă permit să creați protecții adecvate. Cu cât înțelegem mai bine motivele eșecului programului, cu atât este mai ușor să identificăm posibilele metode de exploatare și să dezvoltăm mecanisme adecvate detectie si raspuns. În fig. 2 prezintă categoriile de vulnerabilități pentru toate distribuțiile din ultimii patru ani (). Este imediat clar că majoritatea CVE-urilor se încadrează în următoarele categorii: denial of service (DoS), execuție de cod, overflow, corupție de memorie, scurgere de informații (exfiltrare) și escaladare a privilegiilor. Deși multe CVE sunt numărate de mai multe ori în categorii diferite, în general aceleași probleme persistă an de an. În următoarea parte a articolului, vom evalua utilizarea diferitelor scheme de protecție pentru a preveni exploatarea acestor vulnerabilități.
Fig. 2
sarcini
În acest articol ne propunem să răspundem la următoarele întrebări:
- Care este securitatea diferitelor distribuții Linux? Ce mecanisme de protecție există în aplicațiile kernel și spațiul utilizatorului?
- Cum s-a schimbat de-a lungul timpului adoptarea mecanismelor de securitate în cadrul distribuțiilor?
- Care sunt dependențele medii ale pachetelor și bibliotecilor pentru fiecare distribuție?
- Ce protecții sunt implementate pentru fiecare binar?
Selectarea distribuțiilor
Se pare că este dificil să găsești statistici exacte despre instalațiile de distribuție, deoarece în majoritatea cazurilor numărul de descărcări nu indică numărul de instalări reale. Cu toate acestea, variantele Unix alcătuiesc majoritatea sistemelor de server (pe serverele web 69,2%, de W3techs și alte surse), iar cota lor este în continuă creștere. Astfel, pentru cercetarea noastră ne-am concentrat pe distribuțiile disponibile din cutie pe platformă . În special, am selectat următorul sistem de operare:
Distribuție/versiune
Miezul
Imagine
OpenSUSE 12.4
4.12.14-95.3-implicit
#1 SMP miercuri 5 decembrie 06:00:48 UTC 2018 (63a8d29)
Debian 9 (întindere)
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 marți 15 ianuarie 17:07:28 UTC 2019
CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP vineri, 1 februarie 14:54:57 UTC 2019
Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP miercuri 21 noiembrie 15:08:21 EST 2018
Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP Joi 15 Nov 17:36:42 UTC 2018
Ubuntu 14.04 (Trusty Tahr)
4.4.0–140-generic
#166~14.04.1-Ubuntu SMP sâmb. 17 noiembrie 01:52:43 UTC 20...
Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP vineri, 7 decembrie 09:59:47 UTC 2018
Ubuntu 18.04 (Bionic Beaver)
4.15.0–1026-gcp
#27-Ubuntu SMP Joi 6 Dec 18:27:01 UTC 2018
Tabelul 1
analiza
Să studiem configurația implicită a nucleului, precum și proprietățile pachetelor disponibile prin managerul de pachete al fiecărei distribuții din cutie. Astfel, luăm în considerare numai pachetele din oglinzile implicite ale fiecărei distribuții, ignorând pachetele din depozitele instabile (cum ar fi oglinzile de „testare” Debian) și pachetele terțe (cum ar fi pachetele Nvidia din oglinzile standard). În plus, nu luăm în considerare compilațiile personalizate de kernel sau configurațiile întărite din punct de vedere al securității.
Analiza configurației kernelului
Am aplicat un script de analiză bazat pe . Să ne uităm la parametrii de protecție ai distribuțiilor denumite și să le comparăm cu lista din (KSPP). Pentru fiecare opțiune de configurare, Tabelul 2 descrie setarea dorită: caseta de selectare este pentru distribuțiile care respectă recomandările KSSP (consultați următoarele pentru o explicație a termenilor). ; În articolele viitoare vom explica câte dintre aceste metode de securitate au apărut și cum să piratați un sistem în lipsa lor).
În general, noile nuclee au setări mai stricte din cutie. De exemplu, CentOS 6.10 și RHEL 6.10 pe nucleul 2.6.32 nu au majoritatea caracteristicilor critice implementate în nucleele mai noi, cum ar fi , permisiuni stricte RWX, randomizare a adreselor sau protecție copy2usr. Trebuie remarcat faptul că multe dintre opțiunile de configurare din tabel nu sunt disponibile în versiunile mai vechi ale nucleului și nu sunt aplicabile în realitate - acest lucru este încă indicat în tabel ca o lipsă de protecție adecvată. De asemenea, dacă o opțiune de configurare nu este prezentă într-o anumită versiune și securitatea necesită dezactivarea acestei opțiuni, aceasta este considerată o configurație rezonabilă.
Un alt punct de luat în considerare la interpretarea rezultatelor: unele configurații de kernel care măresc suprafața de atac pot fi folosite și pentru securitate. Astfel de exemple includ uprobe și kprobes, module de nucleu și BPF/eBPF. Recomandarea noastră este să folosiți mecanismele de mai sus pentru a oferi protecție reală, deoarece acestea nu sunt banale de utilizat, iar exploatarea lor presupune că actorii rău intenționați și-au stabilit deja un punct de sprijin în sistem. Dar dacă aceste opțiuni sunt activate, administratorul de sistem trebuie să monitorizeze activ pentru abuz.
Privind în continuare la intrările din Tabelul 2, vedem că nucleele moderne oferă mai multe opțiuni pentru protejarea împotriva exploatării vulnerabilităților, cum ar fi scurgerea de informații și depășirea stivei/heap-ului. Cu toate acestea, observăm că nici cele mai recente distribuții populare nu au implementat încă o protecție mai complexă (de exemplu, cu patch-uri ) sau protecție modernă împotriva atacurilor de reutilizare a codului (de ex. ). Pentru a înrăutăți lucrurile, chiar și aceste apărări mai avansate nu protejează împotriva întregii game de atacuri. Prin urmare, este esențial ca administratorii de sistem să completeze configurațiile inteligente cu soluții care oferă detectarea și prevenirea exploatărilor în timpul rulării.
Analiza aplicației
Nu este surprinzător că diferitele distribuții au caracteristici diferite de pachet, opțiuni de compilare, dependențe de bibliotecă etc. Diferențele există chiar și pentru distribuții și pachete cu un număr mic de dependențe (de exemplu, coreutils pe Ubuntu sau Debian). Pentru a evalua diferențele, am descărcat toate pachetele disponibile, am extras conținutul acestora și am analizat binarele și dependențele. Pentru fiecare pachet, am urmărit celelalte pachete de care depinde și pentru fiecare binar, am urmărit dependențele acestuia. În această secțiune rezumăm pe scurt concluziile.
Distribuții
În total, am descărcat 361 de pachete pentru toate distribuțiile, extragând numai pachete din oglinzile implicite. Am ignorat pachetele fără executabile ELF, cum ar fi surse, fonturi etc. După filtrare, au rămas 556 pachete, conținând un total de 129 binare. Distribuția pachetelor și fișierelor între distribuții este prezentată în Fig. 569.
Fig. 3
Puteți observa că, cu cât distribuția este mai modernă, cu atât conține mai multe pachete și binare, ceea ce este logic. Cu toate acestea, pachetele Ubuntu și Debian includ mult mai multe binare (atât executabile, cât și module dinamice și biblioteci) decât CentOS, SUSE și RHEL, ceea ce poate afecta suprafața de atac a Ubuntu și Debian (trebuie remarcat că numerele reflectă toate binarele tuturor versiunilor). pachet, adică unele fișiere sunt analizate de mai multe ori). Acest lucru este deosebit de important atunci când luați în considerare dependențele dintre pachete. Astfel, o vulnerabilitate într-un singur pachet binar poate afecta multe părți ale ecosistemului, la fel cum o bibliotecă vulnerabilă poate afecta toate binarele care îl importă. Ca punct de plecare, să ne uităm la distribuția numărului de dependențe între pachete în diferite sisteme de operare:
Fig. 4
În aproape toate distribuțiile, 60% dintre pachete au cel puțin 10 dependențe. În plus, unele pachete au un număr semnificativ mai mare de dependențe (mai mult de 100). Același lucru este valabil și pentru dependențele inverse ale pachetelor: așa cum era de așteptat, câteva pachete sunt folosite de multe alte pachete din distribuție, astfel încât vulnerabilitățile din acelea selectate sunt cu risc ridicat. Ca exemplu, următorul tabel listează cele 20 de pachete cu numărul maxim de dependențe inverse în SLES, Centos 7, Debian 9 și Ubuntu 18.04 (fiecare celulă indică pachetul și numărul de dependențe inverse).
Tabelul 3
Fapt interesant. Deși toate sistemele de operare analizate sunt construite pentru arhitectura x86_64 și majoritatea pachetelor au arhitectura definită ca x86_64 și x86, pachetele conțin adesea binare pentru alte arhitecturi, așa cum se arată în Figura 5. XNUMX.
Fig. 5
În secțiunea următoare, vom aprofunda în caracteristicile binarelor analizate.
Statistici de protecție a fișierelor binare
La minimum, trebuie să explorați un set de bază de opțiuni de securitate pentru binarele existente. Mai multe distribuții Linux vin cu scripturi care efectuează astfel de verificări. De exemplu, Debian/Ubuntu are un astfel de script. Iată un exemplu din munca lui:
$ hardening-check $(which docker)
/usr/bin/docker:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: no, only unprotected functions found!
Read-only relocations: yes
Immediate binding: yesScriptul verifică cinci :
- Position Independent Executable (PIE): Indică dacă secțiunea de text a unui program poate fi mutată în memorie pentru a realiza randomizarea dacă ASLR este activat în nucleu.
- Stack Protected: dacă stack canaris sunt activați pentru a proteja împotriva atacurilor de coliziune a stivei.
- Fortificare sursă: dacă funcțiile nesigure (de exemplu, strcpy) sunt înlocuite cu omologii lor mai siguri și dacă apelurile verificate în timpul execuției sunt înlocuite cu omologii lor nebifați (de exemplu, memcpy în loc de __memcpy_chk).
- Mutări doar în citire (RELRO): dacă intrările din tabelul de relocare sunt marcate doar pentru citire dacă sunt declanșate înainte de începerea execuției.
- Legare imediată: dacă linker-ul de execuție permite toate mișcările înainte de a începe execuția programului (acest lucru este echivalent cu un RELRO complet).
Sunt suficiente mecanismele de mai sus? Din pacate, nu. Există modalități cunoscute de a ocoli toate apărările de mai sus, dar cu cât apărarea este mai dură, cu atât bara este mai mare pentru atacator. De exemplu, mai dificil de aplicat dacă PIE și legarea imediată sunt în vigoare. De asemenea, ASLR complet necesită muncă suplimentară pentru a crea un exploit funcțional. Cu toate acestea, atacatorii sofisticați sunt deja pregătiți să îndeplinească astfel de protecții: absența lor va grăbi practic hack-ul. Prin urmare, este esențial ca aceste măsuri să fie considerate necesare minim.
Am vrut să studiem câte fișiere binare din distribuțiile în cauză sunt protejate prin acestea și alte trei metode:
- Bit inexecutabil () împiedică execuția în orice regiune care nu ar trebui să fie executabilă, cum ar fi grămada de stivă etc.
- denotă calea de execuție utilizată de încărcătorul dinamic pentru a găsi biblioteci care se potrivesc. Primul este obligatoriu pentru orice sistem modern: absența acestuia permite atacatorilor să scrie în mod arbitrar sarcina utilă în memorie și să o execute așa cum este. Pentru a doua, configurațiile incorecte ale căilor de execuție ajută la introducerea unui cod nefiabil care poate duce la o serie de probleme (de ex. și ).
- Protecția împotriva coliziunii stivei oferă protecție împotriva atacurilor care fac ca stiva să se suprapună cu alte zone de memorie (cum ar fi heap-ul). Având în vedere exploatările recente abuzive , am considerat că este adecvat să includem acest mecanism în setul nostru de date.
Așa că, fără alte prelungiri, să trecem la cifre. Tabelele 4 și 5 conțin un rezumat al analizei fișierelor executabile și, respectiv, bibliotecilor diferitelor distribuții.
- După cum puteți vedea, protecția NX este implementată peste tot, cu rare excepții. În special, se poate observa utilizarea sa ușor mai scăzută în distribuțiile Ubuntu și Debian în comparație cu CentOS, RHEL și OpenSUSE.
- Canarii stiva lipsesc în multe locuri, în special în distribuțiile cu nuclee mai vechi. Unele progrese sunt observate în cele mai recente distribuții de Centos, RHEL, Debian și Ubuntu.
- Cu excepția Debian și Ubuntu 18.04, majoritatea distribuțiilor au un suport slab pentru PIE.
- Protecția împotriva coliziunilor stivelor este slabă în OpenSUSE, Centos 7 și RHEL 7 și practic inexistentă în altele.
- Toate distribuțiile cu nuclee moderne au suport pentru RELRO, Ubuntu 18.04 fiind lider și Debian pe locul al doilea.
După cum sa menționat deja, valorile din acest tabel sunt media pentru toate versiunile fișierului binar. Dacă vă uitați numai la cele mai recente versiuni de fișiere, numerele vor fi diferite (de exemplu, a se vedea ). Mai mult, majoritatea distribuțiilor testează de obicei doar securitatea câtorva funcții din binar atunci când calculăm statistici, dar analiza noastră arată procentul real de funcții care sunt întărite. Prin urmare, dacă 5 din 50 de funcții sunt protejate într-un binar, îi vom acorda un scor de 0,1, ceea ce corespunde cu 10% din funcțiile care sunt întărite.
Tabelul 4. Caracteristici de securitate pentru fișierele executabile prezentate în Fig. 3 (implementarea funcțiilor relevante ca procent din numărul total de fișiere executabile)
Tabelul 5. Caracteristici de securitate pentru bibliotecile prezentate în Fig. 3 (implementarea funcțiilor relevante ca procent din numărul total de biblioteci)
Deci există progres? Cu siguranță există: acest lucru poate fi văzut din statisticile pentru distribuțiile individuale (de exemplu, ), precum și din tabelele de mai sus. Ca exemplu în Fig. Figura 6 arată implementarea mecanismelor de protecție în trei distribuții succesive ale Ubuntu LTS 5 (am omis statisticile privind protecția împotriva coliziunilor stivei). Observăm că, de la versiune la versiune, tot mai multe fișiere acceptă stiva canari și, de asemenea, tot mai multe binare sunt livrate cu protecție RELRO completă.
Fig. 6
Din păcate, o serie de fișiere executabile din diferite distribuții încă nu au niciuna dintre protecțiile de mai sus. De exemplu, privind Ubuntu 18.04, veți observa binarul ngetty (un înlocuitor getty), precum și shell-urile mksh și lksh, interpretul picolisp, pachetele nvidia-cuda-toolkit (un pachet popular pentru aplicațiile accelerate de GPU). precum cadrele de învățare automată) și klibc -utils. De asemenea, binarul mandos-client (un instrument administrativ care vă permite să reporniți automat mașinile cu sisteme de fișiere criptate), precum și rsh-redone-client (o reimplementare a rsh și rlogin) sunt livrate fără protecție NX, deși au drepturi SUID: (. De asemenea, Câteva binare suid nu au protecție de bază, cum ar fi canarii de stivă (de exemplu, binarul Xorg.wrap din pachetul Xorg).
Rezumat și observații finale
În acest articol, am evidențiat mai multe caracteristici de securitate ale distribuțiilor Linux moderne. Analiza a arătat că cea mai recentă distribuție Ubuntu LTS (18.04) implementează, în medie, cea mai puternică protecție la nivel de sistem de operare și aplicație dintre distribuțiile cu nuclee relativ noi, cum ar fi Ubuntu 14.04, 12.04 și Debian 9. Cu toate acestea, distribuțiile examinate CentOS, RHEL și OpenSUSE în setul nostru produc în mod implicit un set mai dens de pachete, iar în cele mai recente versiuni (CentOS și RHEL) au un procent mai mare de protecție împotriva coliziunilor stivelor în comparație cu concurenții bazați pe Debian (Debian și Ubuntu). Comparând versiunile CentOS și RedHat, observăm îmbunătățiri mari în implementarea stack canaries și RELRO de la versiunile 6 la 7, dar în medie CentOS are implementate mai multe caracteristici decât RHEL. În general, toate distribuțiile ar trebui să acorde o atenție deosebită protecției PIE, care, cu excepția Debian 9 și Ubuntu 18.04, este implementată în mai puțin de 10% din binarele din setul nostru de date.
În cele din urmă, trebuie remarcat faptul că, deși am efectuat cercetarea manual, există multe instrumente de securitate disponibile (de ex. , , ), care efectuează analize și ajută la evitarea configurațiilor nesigure. Din păcate, chiar și protecția puternică în configurații rezonabile nu garantează absența exploit-urilor. De aceea credem cu tărie că este vital să ne asigurăm , concentrându-se pe modele de exploatare și prevenirea acestora.
Sursa: www.habr.com