TL; DR. In questu articulu, esploremu i schemi di indurimentu chì funzionanu fora di a scatula nantu à cinque distribuzioni Linux populari. Per ognunu, avemu pigliatu a cunfigurazione di u kernel predeterminatu, caricate tutti i pacchetti, è analizà i schemi di sicurezza in i binari attaccati. E distribuzioni cunsiderate sò OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 è 7, è ancu Ubuntu 14.04, 12.04 è 18.04 LTS.
I risultati cunfirmanu chì ancu i schemi basi cum'è stacking canaries è codice indipendente di a pusizione ùn sò micca aduttati da tutti. A situazione hè ancu peghju per i compilatori quandu si tratta di prutezzione di vulnerabilità cum'è stack clash, chì hè ghjuntu in u focu in ghjennaghju dopu a publicazione. . Ma micca tuttu hè cusì senza speranza. Un numeru significativu di binari implementanu metudi basi di prutezzione, è u so numeru cresce da versione à versione.
A rivista hà dimustratu chì u più grande numaru di metudi di prutezzione hè implementatu in Ubuntu 18.04 à u nivellu di u SO è di l'applicazione, seguita da Debian 9. Per d 'altra banda, OpenSUSE 12.4, CentOS 7 è RHEL 7 implementanu ancu schemi di prutezzione di basa, è stack collision protection. hè utilizatu ancu più largamente cù un inseme assai più densu di pacchetti predefiniti.
Introduzione
Hè difficiuli di assicurà un software d'alta qualità. Malgradu u vastu numeru di strumenti avanzati per l'analisi di codice staticu è l'analisi dinamica di runtime, è ancu un prugressu significativu in u sviluppu di compilatori è linguaggi di prugrammazione, u software mudernu soffre sempre di vulnerabilità chì sò constantemente sfruttate da l'attaccanti. A situazione hè ancu peghju in l'ecosistemi chì includenu codice legatu. In tali casi, ùn simu micca solu affruntatu cù u prublema eternu di truvà i pussibuli errori sfruttabili, ma simu ancu limitati da stretti quadri di cumpatibilità retrocede, chì spessu ci vole à priservà codice limitatu, o ancu peghju, vulnerabile o buggy.
Hè quì chì i metudi di prutezzione o di i prugrammi indurimenti entranu in ghjocu. Ùn pudemu micca prevene certi tipi d'errori, ma pudemu fà a vita di l'attaccante più difficiule è risolve parzialmente u prublema prevenendu o prevenendu sfruttamentu sti errori. Tali prutezzione hè aduprata in tutti i sistemi operativi muderni, ma i metudi sò assai diffirenti in a cumplessità, l'efficienza è u rendiment: da stack canaries è a prutezzione piena и . In questu articulu, guardemu chì i metudi di prutezzione sò usati in i distribuzioni Linux più populari in a cunfigurazione predeterminata, è ancu esaminà e proprietà di i binari chì sò distribuiti attraversu i sistemi di gestione di pacchetti di ogni distribuzione.
CVE è sicurità
Tutti avemu vistu articuli cù tituli cum'è "L'applicazioni più vulnerabili di l'annu" o "I sistemi operativi più vulnerabili". Di solitu furniscenu statistiche nantu à u numeru tutale di registri nantu à vulnerabili cum'è , ottenuta da от è altre fonti. In seguitu, queste applicazioni o OS sò classificate per u numeru di CVE. Sfortunatamente, mentri i CVE sò assai utili per seguità i prublemi è per informà i venditori è l'utilizatori, dicenu pocu nantu à a sicurezza attuale di u software.
Per esempiu, cunzidira u numeru tutale di CVE in l'ultimi quattru anni per u kernel Linux è e cinque distribuzioni di servitori più populari, vale à dì Ubuntu, Debian, Red Hat Enterprise Linux è OpenSUSE.
Fig. 1
Chì ci dice stu graficu ? Un numaru più altu di CVE significa chì una distribuzione hè più vulnerabile chè l'altru? Nisuna risposta. Per esempiu, in questu articulu vi vede chì Debian hà meccanismi di sicurezza più forti cumparatu cù, per esempiu, OpenSUSE o RedHat Linux, è ancu Debian hà più CVE. Tuttavia, ùn significa micca necessariamente una sicurezza debilitatu: ancu a presenza di un CVE ùn indica micca se una vulnerabilità hè sfruttatu. I punteggi di gravità furniscenu un'indicazione di cumu prubabilmente sfruttamentu di una vulnerabilità, ma in fine a sfruttabilità dipende assai di e prutezioni prisenti in i sistemi affettati è e risorse è e capacità di l'attaccanti. Inoltre, l'absenza di rapporti CVE ùn dice nunda di l'altri micca registratu o scunnisciutu vulnerabilità. A diffarenza in CVE pò esse duvuta à fatturi altri chì a qualità di u software, cumprese i risorse attribuiti à a prova o a dimensione di a basa di l'utilizatori. In u nostru esempiu, u più altu numeru di CVE di Debian pò indicà solu chì Debian spedisce più pacchetti di software.
Di sicuru, u sistema CVE furnisce infurmazioni utili chì vi permette di creà prutezioni appropritate. U megliu capiscenu i motivi di u fallimentu di u prugramma, u più faciule hè di identificà i metudi pussibuli di sfruttamentu è di sviluppà meccanismi adatti. rilevazione è risposta. In Fig. 2 mostra e categurie di vulnerabilità per tutte e distribuzioni in l'ultimi quattru anni (). Hè subitu chjaramente chì a maiò parte di i CVE cadenu in e seguenti categurie: denial of service (DoS), esecuzione di codice, overflow, corruzzione di memoria, fuga di informazioni (exfiltration) è escalation di privilegi. Ancu se parechji CVE sò cuntatu parechje volte in diverse categurie, in generale, i stessi prublemi persistanu annu dopu annu. In a prossima parte di l'articulu, valuteremu l'usu di diversi schemi di prutezzione per impediscenu a sfruttamentu di sti vulnerabili.
Fig. 2
fatti
In questu articulu avemu intenzione di risponde à e seguenti dumande:
- Chì ghjè a sicurità di e diverse distribuzioni Linux? Chì meccanismi di prutezzione esistenu in u kernel è l'applicazioni di u spaziu di l'utilizatori?
- Cumu l'adopzione di i miccanismi di sicurità hà cambiatu cù u tempu in e distribuzioni?
- Chì sò e dependenzi media di pacchetti è biblioteche per ogni distribuzione?
- Chì prutezioni sò implementate per ogni binariu?
Selezzione di distribuzioni
Ci hè chì hè difficiule di truvà statistiche precise nantu à e installazioni di distribuzione, postu chì in a maiò parte di i casi, u numeru di scaricamentu ùn indica micca u numeru di installazioni attuali. Tuttavia, varianti Unix custituiscenu a maiò parte di i sistemi di servitori (in i servitori web 69,2%, da W3techs è altre fonti), è a so parte hè in constantemente crescente. Cusì, per a nostra ricerca avemu focu annantu à e distribuzioni dispunibili fora di a casella nantu à a piattaforma . In particulare, avemu sceltu i seguenti OS:
Distribuzione/versione
Core
Custruì
OpenSUSE 12.4
4.12.14-95.3-default
#1 SMP mer 5 dicembre 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 Ven 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 Mer 21 Nov 15: 08: 21 EST 2018
Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP Gio Nov 15 17:36:42 UTC 2018
Ubuntu 14.04 (Trusty Tahr)
4.4.0-140-generale
#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 Ven 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
Table 1
Analisi
Studiemu a cunfigurazione predeterminata di u kernel, è ancu e proprietà di i pacchetti dispunibuli attraversu u gestore di pacchetti di ogni distribuzione fora di a scatula. Cusì, cunsideremu solu i pacchetti da i specchi predeterminati di ogni distribuzione, ignurendu i pacchetti da i repositori instabili (cum'è i specchi "testi" di Debian) è i pacchetti di terze parti (cum'è i pacchetti Nvidia da i specchi standard). Inoltre, ùn cunsideremu micca compilazioni di kernel persunalizati o cunfigurazioni rinforzate da a sicurità.
Analisi di cunfigurazione di u kernel
Avemu applicatu un script di analisi basatu nantu . Fighjemu i paràmetri di prutezzione out-of-the-box di e distribuzioni chjamate è paragunate cù a lista da (KSPP). Per ogni opzione di cunfigurazione, a Tabella 2 descrive l'impostazione desiderata: a casella di spunta hè per e distribuzioni chì cumplenu cù e raccomandazioni KSSP (vede e seguenti per una spiegazione di i termini). ; In articuli futuri spiegheremu quanti di sti metudi di sicurità sò ghjunti è cumu per pirate un sistema in a so assenza).
In generale, i novi kernels anu paràmetri più stretti fora di a scatula. Per esempiu, CentOS 6.10 è RHEL 6.10 nantu à u kernel 2.6.32 mancanu a maiò parte di e funzioni critiche implementate in kernels più recenti, cum'è , permessi stretti RWX, randomizazione di indirizzu o prutezzione copy2usr. Semu devi esse nutatu chì assai di l'opzioni di cunfigurazione in a tavula ùn sò micca dispunibili in versioni più vechje di u kernel è ùn sò micca applicabili in a realità - questu hè sempre indicatu in a tavula cum'è una mancanza di prutezzione propria. In listessu modu, se una opzione di cunfigurazione ùn hè micca presente in una versione determinata, è a sicurità richiede chì l'opzione sia disattivata, questu hè cunsideratu una cunfigurazione raghjone.
Un altru puntu da cunsiderà quandu si interpretanu i risultati: alcune cunfigurazioni di u kernel chì aumentanu a superficia di attaccu pò ancu esse usata per a sicurità. Tali esempi includenu uprobes è kprobes, moduli di kernel, è BPF/eBPF. A nostra ricunniscenza hè di utilizà i meccanismi di sopra per furnisce una prutezzione vera, postu chì ùn sò micca triviali à utilizà è a so sfruttamentu assume chì l'attori maliziusi anu digià stabilitu un postu in u sistema. Ma se queste opzioni sò attivate, l'amministratore di u sistema deve monitorà attivamente l'abusu.
Fighjendu più in l'entrate in a Tabella 2, vedemu chì i kernels muderni furniscenu parechje opzioni per a prutezzione contra l'sfruttamentu di e vulnerabilità, cum'è a fuga di l'informazioni è a stack / heap overflows. Tuttavia, avemu nutatu chì ancu e distribuzioni populari più recenti ùn anu ancu implementatu una prutezzione più cumplessa (per esempiu, cù patch ) o prutezzione muderna contr'à attacchi di reutilizazione di codice (p.e. ). Per aggravà e cose, ancu questi difesi più avanzati ùn pruteghjanu micca da a gamma completa di attacchi. Dunque, hè criticu per l'amministratori di u sistema di cumplementà e cunfigurazioni intelligenti cù suluzioni chì offrenu a rilevazione è a prevenzione di sfruttamentu di runtime.
Analisi di l'applicazioni
Ùn hè micca surprisante, e diverse distribuzioni anu diverse caratteristiche di pacchettu, opzioni di compilazione, dipendenze di biblioteca, etc. Differenzi esistenu ancu per distribuzioni è pacchetti cù un picculu numeru di dipendenze (per esempiu, coreutils in Ubuntu o Debian). Per evaluà e differenze, avemu scaricatu tutti i pacchetti dispunibuli, estratti u so cuntenutu, è analizà i binari è dipendenze. Per ogni pacchettu, avemu seguitu a traccia di l'altri pacchetti chì dipende, è per ogni binariu, avemu tracciatu e so dependenze. In questa sezione riassumemu brevemente e cunclusioni.
Distribuzioni
In totale, avemu scaricatu 361 pacchetti per tutte e distribuzioni, estrattendu solu pacchetti da specchi predeterminati. Avemu ignoratu i pacchetti senza eseguibili ELF, cum'è fonti, fonts, etc. Dopu a filtrazione, 556 pacchetti sò stati, chì cuntenenu un totale di 129 binari. A distribuzione di pacchetti è fugliali trà e distribuzioni hè mostrata in Fig. 569.
Fig. 3
Puderete nutà chì a più moderna a distribuzione, più pacchetti è binari cuntene, chì hè logica. Tuttavia, i pacchetti Ubuntu è Debian includenu assai più binari (sia eseguibili sia moduli dinamichi è biblioteche) cà CentOS, SUSE è RHEL, chì potenzalmentu affettanu a superficia di attaccu di Ubuntu è Debian (si deve esse nutatu chì i numeri riflettenu tutti i binari di tutte e versioni). pacchettu, vale à dì, certi schedari sò analizati parechje volte). Questu hè soprattuttu impurtante quandu cunsiderà dipendenze trà i pacchetti. Cusì, una vulnerabilità in un solu pacchettu binariu pò influenzà parechje parte di l'ecosistema, cum'è una biblioteca vulnerabile pò influenzà tutti i binari chì l'importanu. Cum'è un puntu di partenza, fighjemu a distribuzione di u numeru di dipendenze trà i pacchetti in diversi sistemi operativi:
Fig. 4
In quasi tutte e distribuzioni, u 60% di i pacchetti anu almenu 10 dipendenze. Inoltre, certi pacchetti anu un numeru significativamente più grande di dipendenze (più di 100). U stessu s'applica à e dipendenze di u pacchettu inversu: cum'è s'aspittava, uni pochi di pacchetti sò usati da parechji altri pacchetti in a distribuzione, cusì vulnerabili in quelli selezziunati sò un risicu altu. Per esempiu, a tavula seguente lista i pacchetti 20 cù u numeru massimu di dependenzii inversi in SLES, Centos 7, Debian 9 è Ubuntu 18.04 (ogni cellula indica u pacchettu è u numeru di dipendenze inverse).
Table 3
Fattu interessante. Ancu se tutti i OS analizati sò custruiti per l'architettura x86_64, è a maiò parte di i pacchetti anu l'architettura definita cum'è x86_64 è x86, i pacchetti spessu cuntenenu binari per altre architetture, cum'è mostra in Figura 5. XNUMX.
Fig. 5
In a sezione dopu, avemu da approfondisce e caratteristiche di i binari analizati.
Statistiche di prutezzione di i schedari binari
À u minimu assolutu, avete bisognu di spiegà un inseme basu di opzioni di sicurezza per i vostri binari esistenti. Diversi distribuzioni Linux venenu cù script chì facenu tali cuntrolli. Per esempiu, Debian/Ubuntu hà un tali script. Eccu un esempiu di u so travagliu:
$ 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: yesU script verifica cinque :
- Position Independent Executable (PIE): Indica se a sezione di testu di un prugramma pò esse spustata in memoria per ottene una randomizazione se ASLR hè attivatu in u kernel.
- Stack Protected: Sia chì i canari di stack sò attivati per prutege contr'à attacchi di collisione di pila.
- Fortify Source: se e funzioni insicure (per esempiu, strcpy) sò rimpiazzati cù i so contraparti più sicuri, è i chjamati verificati in runtime sò rimpiazzati cù i so contraparti non verificati (per esempiu, memcpy invece di __memcpy_chk).
- Trasferimenti di sola lettura (RELRO): Se e voci di a tavola di trasferimentu sò marcati in sola lettura si sò attivati prima di inizià l'esecuzione.
- Ubligatoriu immediatu: Se u runtime linker permette tutti i movimenti prima di l'esekzione di u prugramma principia (questu hè equivalente à un RELRO cumpletu).
Sò i meccanismi sopra abbastanza? Sfurtunatamente no. Ci sò modi cunnisciuti per scaccià tutte e difese sopra, ma più dura hè a difesa, più alta hè a barra per l'attaccante. Per esempiu, più difficiuli di applicà se u PIE è u vincolu immediatu sò in vigore. In listessu modu, ASLR cumpletu richiede un travagliu supplementu per creà un sfruttamentu di travagliu. Tuttavia, l'attaccanti sofisticati sò digià pronti à scuntrà tali prutezzione: a so assenza essenzialmente accelerà u pirate. Hè dunque essenziale chì queste misure sò cunsiderate necessarie minimu.
Vulemu studià quanti schedarii binari in e distribuzioni in quistione sò prutetti da questi è trè altri metudi:
- Bit ineseguibile () impedisce l'esekzione in ogni regione chì ùn deve esse eseguibile, cum'è a pila di pila, etc.
- denota u percorsu di esecuzione utilizatu da u caricatore dinamicu per truvà biblioteche currispondenti. U primu hè ubligatoriu per ogni sistema mudernu: a so assenza permette à l'attaccanti di scrive arbitrariamente u payload in memoria è eseguisce cum'è. Per u sicondu, e cunfigurazioni di percorsi di esecuzione incorrecte aiutanu à introduci un codice inaffidabile chì pò purtà à una quantità di prublemi (per esempiu , cum'è ancu ).
- A prutezzione di collisione di stack furnisce a prutezzione contru l'attacchi chì facenu chì a pila si sovrappone à l'altri spazii di memoria (cum'è u munzeddu). Data l'abusu di sfruttamenti recenti , avemu pensatu chì era apprupriatu per include stu mecanismu in u nostru dataset.
Allora, senza più preghjudiziu, andemu à i numeri. I Tabella 4 è 5 cuntenenu un riassuntu di l'analisi di i fugliali eseguibili è e librerie di diverse distribuzioni, rispettivamente.
- Comu pudete vede, a prutezzione NX hè implementata in ogni locu, cù rari eccezzioni. In particulare, si pò nutà u so usu ligeramente più bassu in distribuzioni Ubuntu è Debian cumparatu à CentOS, RHEL è OpenSUSE.
- Stack canaries mancanu in parechji lochi, in particulare in distribuzioni cù kernels più vechji. Qualchi prugressu hè vistu in l'ultime distribuzioni di Centos, RHEL, Debian è Ubuntu.
- Cù l'eccezzioni di Debian è Ubuntu 18.04, a maiò parte di e distribuzioni anu un poviru supportu PIE.
- A prutezzione di collisione di stack hè debule in OpenSUSE, Centos 7 è RHEL 7, è praticamente inesistente in altri.
- Tutte e distribuzioni cù kernel muderni anu qualchì supportu per RELRO, cù Ubuntu 18.04 chì guidanu a strada è Debian chì vene in seconda.
Comu digià dettu, i metrichi in questa tavula sò a media per tutte e versioni di u schedariu binariu. Se guardate solu l'ultime versioni di i schedari, i numeri seranu diffirenti (per esempiu, vede ). Inoltre, a maiò parte di e distribuzioni sò in solitu pruvà solu a sicurità di uni pochi di funzioni in u binari quandu calcule statistiche, ma a nostra analisi mostra u veru percentualità di funzioni chì sò induriti. Per quessa, se 5 di e funzioni 50 sò prutetti in un binariu, daremu un puntu di 0,1, chì currisponde à 10% di e funzioni chì sò rinfurzati.
Table 4. Caratteristiche di sicurezza per i schedarii eseguibili mostrati in Fig. 3 (implementazione di funzioni pertinenti cum'è percentualità di u numeru tutale di fugliali eseguibili)
Table 5. Caratteristiche di sicurezza per e librerie mostrate in Fig. 3 (implementazione di funzioni pertinenti cum'è percentuale di u numeru tutale di biblioteche)
Allora ci hè prugressu ? Ci hè certamente: questu pò esse vistu da e statistiche per distribuzioni individuali (per esempiu, ), è ancu da e tavule sopra. Comu esempiu in Fig. A Figura 6 mostra l'implementazione di i meccanismi di prutezzione in trè distribuzioni successive di Ubuntu LTS 5 (avemu omessi statistiche di prutezzione di collisione di stack). Avemu nutatu chì da a versione à a versione più è più schedari supportanu stack canaries, è ancu più è più binari sò spediti cù a prutezzione RELRO cumpleta.
Fig. 6
Sfurtunatamente, una quantità di fugliali eseguibili in diverse distribuzioni ùn anu ancu nisuna di e prutezzione sopra. Per esempiu, fighjendu Ubuntu 18.04, vi vede u binariu ngetty (un rimpiazzamentu di getty), è ancu i shell mksh è lksh, l'interprete picolisp, i pacchetti nvidia-cuda-toolkit (un pacchettu populari per l'applicazioni accelerate da GPU). cum'è i quadri di apprendimentu automaticu), è klibc -utils. In listessu modu, u binariu mandos-client (un strumentu amministrativu chì vi permette di riavvià automaticamente e macchine cù sistemi di file criptati) è ancu rsh-redone-client (una reimplementazione di rsh è rlogin) spedite senza prutezzione NX, ancu s'ellu anu diritti SUID: (. Inoltre, Diversi suid binari mancanu a prutezzione di basa cum'è stack canaries (per esempiu, u binariu Xorg.wrap da u pacchettu Xorg).
Riassuntu è Rimarche Conclusioni
In questu articulu, avemu evidenziatu parechje caratteristiche di sicurezza di distribuzioni Linux muderni. L'analisi hà dimustratu chì l'ultima distribuzione Ubuntu LTS (18.04) implementa, in media, u più forte OS è a prutezzione di u livellu di l'applicazione trà e distribuzioni cù kernel relativamente novi, cum'è Ubuntu 14.04, 12.04 è Debian 9. Tuttavia, e distribuzioni esaminate CentOS, RHEL è OpenSUSE in u nostru settore per difettu producenu un inseme più densu di pacchetti, è in l'ultime versioni (CentOS è RHEL) anu un percentinu più altu di prutezzione di collisione di stack cumparatu cù i cuncurrenti basati in Debian (Debian è Ubuntu). Paragunendu e versioni CentOS è RedHat, avemu nutatu grandi miglioramenti in l'implementazione di stack canaries è RELRO da e versioni 6 à 7, ma in media CentOS hà più funzioni implementate cà RHEL. In generale, tutte e distribuzioni devenu esse attenti à a prutezzione PIE, chì, cù l'eccezzioni di Debian 9 è Ubuntu 18.04, hè implementatu in menu di 10% di i binari in u nostru dataset.
Infine, deve esse nutatu chì, ancu s'è avemu realizatu a ricerca manualmente, ci sò assai strumenti di sicurezza dispunibili (per esempiu , , ), chì facenu analisi è aiutanu à evità cunfigurazioni insicure. Sfortunatamente, ancu una prutezzione forte in cunfigurazioni ragiunate ùn guarantisci micca l'absenza di sfruttamenti. Hè per quessa chì credemu fermamente chì hè vitale per assicurà , fucalizza nantu à mudelli di sfruttamentu è impediscenu.
Source: www.habr.com