TL; DR. En aquest article, explorem els esquemes d'enduriment que funcionen fora de la caixa en cinc distribucions populars de Linux. Per a cadascun, vam agafar la configuració predeterminada del nucli, vam carregar tots els paquets i vam analitzar els esquemes de seguretat als binaris adjunts. Les distribucions considerades són OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 i 7, així com Ubuntu 14.04, 12.04 i 18.04 LTS.
Els resultats confirmen que fins i tot els esquemes bàsics com ara l'apilament de canaris i el codi independent de la posició encara no són adoptats per tothom. La situació és encara pitjor per als compiladors quan es tracta de protegir-se de vulnerabilitats com el xoc de pila, que es va posar de relleu al gener després de la publicació. . Però no tot és tan desesperançat. Un nombre important de binaris implementen mètodes bàsics de protecció, i el seu nombre creix de versió en versió.
La revisió va mostrar que el major nombre de mètodes de protecció s'implementa a Ubuntu 18.04 a nivells de sistema operatiu i d'aplicació, seguit de Debian 9. D'altra banda, OpenSUSE 12.4, CentOS 7 i RHEL 7 també implementen esquemes de protecció bàsics i protecció contra col·lisions de pila. s'utilitza encara més àmpliament amb un conjunt molt més dens de paquets per defecte.
Introducció
És difícil assegurar un programari d'alta qualitat. Malgrat la gran quantitat d'eines avançades per a l'anàlisi de codi estàtic i l'anàlisi dinàmica del temps d'execució, així com els progressos significatius en el desenvolupament de compiladors i llenguatges de programació, el programari modern encara pateix vulnerabilitats que són explotades constantment pels atacants. La situació és encara pitjor en els ecosistemes que inclouen codi heretat. En aquests casos, no només ens enfrontem a l'etern problema de trobar possibles errors explotables, sinó que també estem limitats per marcs de compatibilitat amb versions anteriors estrictes, que sovint ens obliguen a preservar codi limitat, o encara pitjor, vulnerable o amb errors.
Aquí és on entren en joc els mètodes de protecció o enduriment dels programes. No podem prevenir alguns tipus d'errors, però podem dificultar la vida de l'atacant i resoldre parcialment el problema evitant o evitant explotació aquests errors. Aquesta protecció s'utilitza en tots els sistemes operatius moderns, però els mètodes difereixen molt en complexitat, eficiència i rendiment: des de la pila de canaris i a una protecció total и . En aquest article, veurem quins mètodes de protecció s'utilitzen a les distribucions Linux més populars en la configuració per defecte, i també examinarem les propietats dels binaris que es distribueixen a través dels sistemes de gestió de paquets de cada distribució.
CVE i seguretat
Tots hem vist articles amb títols com "Les aplicacions més vulnerables de l'any" o "Els sistemes operatius més vulnerables". Normalment proporcionen estadístiques sobre el nombre total de registres sobre vulnerabilitats com , obtingut de d' i altres fonts. Posteriorment, aquestes aplicacions o SO es classifiquen segons el nombre de CVE. Malauradament, tot i que els CVE són molt útils per fer un seguiment dels problemes i informar a proveïdors i usuaris, diuen poc sobre la seguretat real del programari.
Com a exemple, considereu el nombre total de CVE durant els últims quatre anys per al nucli de Linux i les cinc distribucions de servidors més populars, a saber, Ubuntu, Debian, Red Hat Enterprise Linux i OpenSUSE.
La figura. 1
Què ens diu aquest gràfic? Un nombre més elevat de CVE significa que una distribució és més vulnerable que una altra? Sense resposta. Per exemple, en aquest article veureu que Debian té mecanismes de seguretat més forts en comparació, per exemple, amb OpenSUSE o RedHat Linux, i, tanmateix, Debian té més CVE. Tanmateix, no necessàriament signifiquen una seguretat debilitat: fins i tot la presència d'un CVE no indica si hi ha una vulnerabilitat. explotat. Les puntuacions de gravetat proporcionen una indicació de com probablement l'explotació d'una vulnerabilitat, però en última instància, l'explotació depèn en gran mesura de les proteccions presents als sistemes afectats i dels recursos i capacitats dels atacants. A més, l'absència d'informes CVE no diu res dels altres no registrat o desconegut vulnerabilitats. La diferència de CVE pot ser deguda a factors diferents de la qualitat del programari, inclosos els recursos destinats a les proves o la mida de la base d'usuaris. En el nostre exemple, el nombre més elevat de CVE de Debian pot indicar simplement que Debian envia més paquets de programari.
Per descomptat, el sistema CVE proporciona informació útil que permet crear les proteccions adequades. Com millor entenem les raons del fracàs del programa, més fàcil serà identificar possibles mètodes d'explotació i desenvolupar mecanismes adequats. detecció i resposta. A la Fig. 2 mostra les categories de vulnerabilitats per a totes les distribucions durant els últims quatre anys (). Immediatament queda clar que la majoria de CVE es divideixen en les categories següents: denegació de servei (DoS), execució de codi, desbordament, corrupció de memòria, filtració d'informació (exfiltració) i escalada de privilegis. Tot i que molts CVE es compten diverses vegades en diferents categories, en general els mateixos problemes persisteixen any rere any. A la següent part de l'article, avaluarem l'ús de diversos esquemes de protecció per evitar l'explotació d'aquestes vulnerabilitats.
La figura. 2
tasques
En aquest article pretenem respondre les preguntes següents:
- Quina és la seguretat de les diferents distribucions de Linux? Quins mecanismes de protecció existeixen al nucli i a les aplicacions de l'espai d'usuari?
- Com ha canviat l'adopció de mecanismes de seguretat al llarg del temps entre les distribucions?
- Quines són les dependències mitjanes de paquets i biblioteques per a cada distribució?
- Quines proteccions s'implementen per a cada binari?
Selecció de distribucions
Resulta que és difícil trobar estadístiques precises sobre les instal·lacions de distribució, ja que en la majoria dels casos el nombre de descàrregues no indica el nombre d'instal·lacions reals. Tanmateix, les variants Unix constitueixen la majoria dels sistemes de servidor (en servidors web el 69,2%, per W3techs i altres fonts), i la seva quota està en constant creixement. Així, per a la nostra investigació ens vam centrar en les distribucions disponibles a la plataforma . En particular, hem seleccionat el següent sistema operatiu:
Distribució/versió
El nucli
Construir
OpenSUSE 12.4
4.12.14-95.3-per defecte
#1 SMP dimecres 5 de desembre 06:00:48 UTC 2018 (63a8d29)
Debian 9 (extensió)
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 dimarts, 15 de gener 17:07:28 UTC 2019
CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP divendres 1 de febrer 14:54:57 UTC 2019
Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP dimecres 21 de novembre 15:08:21 EST 2018
Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP Dj, 15 de novembre 17:36:42 UTC 2018
Ubuntu 14.04 (Trusty Tahr)
4.4.0–140-genèric
#166~14.04.1-Ubuntu SMP Ds. 17 de novembre 01:52:43 UTC 20...
Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP divendres 7 de desembre 09:59:47 UTC 2018
Ubuntu 18.04 (Bionic Beaver)
4.15.0–1026-gcp
#27-Ubuntu SMP Dj, 6 de desembre 18:27:01 UTC 2018
Taula 1
Anàlisi
Estudiem la configuració predeterminada del nucli, així com les propietats dels paquets disponibles a través del gestor de paquets de cada distribució. Per tant, només considerem els paquets de les rèpliques per defecte de cada distribució, ignorant els paquets dels dipòsits inestables (com ara les rèpliques de "prova" de Debian) i els paquets de tercers (com els paquets de Nvidia de les rèpliques estàndard). A més, no tenim en compte les compilacions personalitzades del nucli ni les configuracions amb seguretat.
Anàlisi de la configuració del nucli
Hem aplicat un script d'anàlisi basat en . Vegem els paràmetres de protecció predefinits de les distribucions anomenades i comparem-los amb la llista de (KSPP). Per a cada opció de configuració, la Taula 2 descriu la configuració desitjada: la casella de selecció és per a les distribucions que compleixen les recomanacions del KSSP (vegeu a continuació una explicació dels termes). ; En propers articles explicarem quants d'aquests mètodes de seguretat van sorgir i com piratejar un sistema en la seva absència).
En general, els nous nuclis tenen configuracions més estrictes des de la caixa. Per exemple, CentOS 6.10 i RHEL 6.10 al nucli 2.6.32 no tenen la majoria de les funcions crítiques implementades en nuclis més nous, com ara , estrictes permisos RWX, aleatorització d'adreces o protecció copy2usr. Cal tenir en compte que moltes de les opcions de configuració de la taula no estan disponibles en versions anteriors del nucli i no són aplicables a la realitat; això encara s'indica a la taula com a falta de protecció adequada. De la mateixa manera, si una opció de configuració no està present en una versió determinada i la seguretat requereix que aquesta opció estigui desactivada, es considera una configuració raonable.
Un altre punt a tenir en compte a l'hora d'interpretar els resultats: algunes configuracions del nucli que augmenten la superfície d'atac també es poden utilitzar per seguretat. Aquests exemples inclouen uprobes i kprobes, mòduls del nucli i BPF/eBPF. La nostra recomanació és utilitzar els mecanismes anteriors per proporcionar una protecció real, ja que no són trivials d'utilitzar i la seva explotació suposa que els actors maliciosos ja han establert una base al sistema. Però si aquestes opcions estan habilitades, l'administrador del sistema ha de supervisar activament els abusos.
Mirant més a les entrades de la taula 2, veiem que els nuclis moderns ofereixen diverses opcions per protegir-se de l'explotació de vulnerabilitats, com ara la fuga d'informació i els desbordaments de pila/munt. Tanmateix, observem que fins i tot les distribucions populars més recents encara no han implementat una protecció més complexa (per exemple, amb pedaços ) o protecció moderna contra atacs de reutilització de codi (p. ). Per empitjorar les coses, fins i tot aquestes defenses més avançades no protegeixen contra tota la gamma d'atacs. Per tant, és fonamental que els administradors del sistema complementin les configuracions intel·ligents amb solucions que ofereixen detecció i prevenció d'explotacions en temps d'execució.
Anàlisi de l'aplicació
No és sorprenent que diferents distribucions tinguin diferents característiques de paquet, opcions de compilació, dependències de biblioteques, etc. Fins i tot hi ha diferències per a distribucions i paquets amb un nombre reduït de dependències (per exemple, coreutils a Ubuntu o Debian). Per avaluar les diferències, vam descarregar tots els paquets disponibles, vam extreure el seu contingut i vam analitzar els binaris i les dependències. Per a cada paquet, vam fer un seguiment dels altres paquets dels quals depèn, i per a cada binari, vam fer un seguiment de les seves dependències. En aquest apartat resumim breument les conclusions.
Distribucions
En total, vam descarregar 361 paquets per a totes les distribucions, extreint només paquets dels miralls predeterminats. Hem ignorat els paquets sense executables ELF, com ara fonts, tipus de lletra, etc. Després del filtratge, van quedar 556 paquets, que contenien un total de 129 binaris. La distribució de paquets i fitxers entre distribucions es mostra a la Fig. 569.
La figura. 3
Podeu observar que com més moderna és la distribució, més paquets i binaris conté, la qual cosa és lògic. Tanmateix, els paquets Ubuntu i Debian inclouen molts més binaris (tant executables com mòduls dinàmics i biblioteques) que CentOS, SUSE i RHEL, la qual cosa pot afectar la superfície d'atac d'Ubuntu i Debian (cal tenir en compte que els números reflecteixen tots els binaris de totes les versions). paquet, és a dir, alguns fitxers s'analitzen diverses vegades). Això és especialment important quan teniu en compte les dependències entre paquets. Així, una vulnerabilitat en un únic paquet binari pot afectar moltes parts de l'ecosistema, de la mateixa manera que una biblioteca vulnerable pot afectar tots els binaris que l'importen. Com a punt de partida, mirem la distribució del nombre de dependències entre paquets en diferents sistemes operatius:
La figura. 4
En gairebé totes les distribucions, el 60% dels paquets tenen almenys 10 dependències. A més, alguns paquets tenen un nombre significativament més gran de dependències (més de 100). El mateix s'aplica a les dependències inverses dels paquets: com era d'esperar, molts altres paquets de la distribució utilitzen alguns paquets, de manera que les vulnerabilitats d'aquells pocs són d'alt risc. Com a exemple, la taula següent enumera els 20 paquets amb el nombre màxim de dependències inverses a SLES, Centos 7, Debian 9 i Ubuntu 18.04 (cada cel·la indica el paquet i el nombre de dependències inverses).
Taula 3
Fet interessant. Tot i que tots els sistemes operatius analitzats estan creats per a l'arquitectura x86_64 i la majoria dels paquets tenen l'arquitectura definida com a x86_64 i x86, els paquets sovint contenen binaris per a altres arquitectures, com es mostra a la figura 5. XNUMX.
La figura. 5
En el següent apartat, aprofundirem en les característiques dels binaris analitzats.
Estadístiques de protecció de fitxers binaris
Com a mínim, heu d'explorar un conjunt bàsic d'opcions de seguretat per als vostres binaris existents. Diverses distribucions de Linux inclouen scripts que realitzen aquestes comprovacions. Per exemple, Debian/Ubuntu té aquest script. Aquí teniu un exemple del seu treball:
$ 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: yesEl guió en comprova cinc :
- Position Independent Executable (PIE): indica si la secció de text d'un programa es pot moure a la memòria per aconseguir l'aleatorització si ASLR està habilitat al nucli.
- Stack Protected: si els canaris de pila estan habilitats per protegir-se dels atacs de col·lisió de pila.
- Fortifica la font: si les funcions no segures (per exemple, strcpy) es substitueixen per les seves contraparts més segures, i les trucades verificades en temps d'execució es substitueixen per les seves contraparts no marcades (per exemple, memcpy en lloc de __memcpy_chk).
- Reubicacions de només lectura (RELRO): si les entrades de la taula de reubicació estan marcades com a només lectura si s'activen abans de començar l'execució.
- Enllaç immediat: si l'enllaçador en temps d'execució permet tots els moviments abans que comenci l'execució del programa (això és equivalent a un RELRO complet).
Són suficients els mecanismes anteriors? Lamentablement no. Hi ha maneres conegudes de saltar totes les defenses anteriors, però com més dura sigui la defensa, més alta serà la barra per a l'atacant. Per exemple, més difícil d'aplicar si el PIE i la vinculació immediata estan vigents. De la mateixa manera, l'ASLR complet requereix treball addicional per crear un exploit que funcioni. Tanmateix, els atacants sofisticats ja estan preparats per complir amb aquestes proteccions: la seva absència bàsicament accelerarà el pirateig. Per tant, és fonamental que aquestes mesures es considerin necessàries mínim.
Volíem estudiar quants fitxers binaris de les distribucions en qüestió estan protegits per aquests i tres mètodes més:
- Bit inexecutable () impedeix l'execució a qualsevol regió que no hauria de ser executable, com ara el munt de pila, etc.
- indica la ruta d'execució utilitzada pel carregador dinàmic per trobar biblioteques coincidents. El primer és obligatori per a qualsevol sistema modern: la seva absència permet als atacants escriure arbitràriament la càrrega útil a la memòria i executar-la tal qual. Per al segon, les configuracions incorrectes del camí d'execució ajuden a introduir codi poc fiable que pot provocar una sèrie de problemes (p. I ).
- La protecció contra col·lisions de pila proporciona protecció contra atacs que fan que la pila se superposi a altres àrees de la memòria (com ara l'emmagatzematge dinàmic). Tenint en compte els fets recents abusant , vam considerar que era adequat incloure aquest mecanisme al nostre conjunt de dades.
Per tant, sense més preàmbuls, anem als números. Les taules 4 i 5 contenen un resum de l'anàlisi dels fitxers executables i de les biblioteques de diverses distribucions, respectivament.
- Com podeu veure, la protecció NX s'implementa a tot arreu, amb rares excepcions. En particular, es pot notar el seu ús lleugerament inferior a les distribucions Ubuntu i Debian en comparació amb CentOS, RHEL i OpenSUSE.
- Els canaris de pila falten en molts llocs, especialment en distribucions amb nuclis més antics. S'estan observant alguns progressos en les últimes distribucions de Centos, RHEL, Debian i Ubuntu.
- Amb l'excepció de Debian i Ubuntu 18.04, la majoria de distribucions tenen un suport PIE deficient.
- La protecció contra col·lisions de pila és feble a OpenSUSE, Centos 7 i RHEL 7, i pràcticament inexistent en altres.
- Totes les distribucions amb nuclis moderns tenen cert suport per a RELRO, amb Ubuntu 18.04 liderant el camí i Debian en segon lloc.
Com ja s'ha esmentat, les mètriques d'aquesta taula són la mitjana de totes les versions del fitxer binari. Si mireu només les últimes versions dels fitxers, els números seran diferents (per exemple, vegeu ). A més, la majoria de distribucions normalment només posen a prova la seguretat d'unes quantes funcions en el binari quan es calculen les estadístiques, però la nostra anàlisi mostra el percentatge real de funcions que s'endureix. Per tant, si 5 de 50 funcions estan protegides en un binari, li donarem una puntuació de 0,1, que correspon al 10% de les funcions que s'estan reforçant.
Taula 4. Característiques de seguretat dels fitxers executables que es mostren a la Fig. 3 (implementació de funcions rellevants com a percentatge del nombre total de fitxers executables)
Taula 5. Característiques de seguretat de les biblioteques que es mostren a la Fig. 3 (implementació de les funcions rellevants com a percentatge del nombre total de biblioteques)
Així doncs, hi ha progrés? Definitivament n'hi ha: això es pot veure a partir de les estadístiques de distribucions individuals (per exemple, ), així com de les taules anteriors. Com a exemple a la Fig. La figura 6 mostra la implementació de mecanismes de protecció en tres distribucions successives d'Ubuntu LTS 5 (hem omès les estadístiques de protecció contra col·lisions de pila). Ens adonem que, de versió en versió, cada cop hi ha més fitxers que admeten els canaris de pila, i també s'envien més i més binaris amb protecció RELRO completa.
La figura. 6
Malauradament, diversos fitxers executables de diferents distribucions encara no tenen cap de les proteccions anteriors. Per exemple, mirant Ubuntu 18.04, notareu el binari ngetty (un reemplaçament de Getty), així com les shells mksh i lksh, l'intèrpret picolisp, els paquets nvidia-cuda-toolkit (un paquet popular per a aplicacions accelerades per GPU). com ara marcs d'aprenentatge automàtic) i klibc -utils. De la mateixa manera, el binari mandos-client (una eina administrativa que permet reiniciar automàticament les màquines amb sistemes de fitxers xifrats), així com rsh-redone-client (una reimplementació de rsh i rlogin) s'envien sense protecció NX, tot i que tenen drets SUID: (. A més, diversos binaris suid no tenen protecció bàsica com ara els canaris de pila (per exemple, el binari Xorg.wrap del paquet Xorg).
Resum i observacions finals
En aquest article, hem destacat diverses característiques de seguretat de les distribucions de Linux modernes. L'anàlisi va mostrar que la darrera distribució Ubuntu LTS (18.04) implementa, de mitjana, la protecció a nivell d'aplicació i sistema operatiu més fort entre les distribucions amb nuclis relativament nous, com Ubuntu 14.04, 12.04 i Debian 9. No obstant això, les distribucions examinades CentOS, RHEL i OpenSUSE al nostre conjunt produeixen per defecte un conjunt més dens de paquets, i en les últimes versions (CentOS i RHEL) tenen un percentatge més elevat de protecció contra col·lisions de pila en comparació amb els competidors basats en Debian (Debian i Ubuntu). Comparant les versions de CentOS i RedHat, observem grans millores en la implementació de stack canaris i RELRO de les versions 6 a 7, però de mitjana CentOS té més funcions implementades que RHEL. En general, totes les distribucions haurien de prestar especial atenció a la protecció PIE, que, amb l'excepció de Debian 9 i Ubuntu 18.04, s'implementa en menys del 10% dels binaris del nostre conjunt de dades.
Finalment, cal tenir en compte que, tot i que hem realitzat la investigació manualment, hi ha moltes eines de seguretat disponibles (p. , , ), que realitzen anàlisis i ajuden a evitar configuracions insegures. Malauradament, fins i tot una protecció forta en configuracions raonables no garanteix l'absència d'explotacions. Per això creiem fermament que és vital garantir-ho , centrant-se en els patrons d'explotació i prevenir-los.
Font: www.habr.com