{"id":29880,"date":"2019-10-31T21:32:27","date_gmt":"2019-10-31T18:32:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/milliony-binarnikov-spustya-kak-ukreplyalsya-linux\/"},"modified":"2019-10-31T21:32:27","modified_gmt":"2019-10-31T18:32:27","slug":"milliony-binarnikov-spustya-kak-ukreplyalsya-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/milliony-binarnikov-spustya-kak-ukreplyalsya-linux","title":{"rendered":"Milioni di binari dopo. Come si \u00e8 rafforzato Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MilioniTL;DR<\/b>. In questo articolo esploriamo gli schemi di sicurezza (hardening schemes) che funzionano out-of-the-box in cinque distribuzioni Linux popolari. Per ciascuna di esse abbiamo preso la configurazione predefinita del kernel, caricato tutti i pacchetti e analizzato gli schemi di protezione nei file binari annidati. Le distribuzioni considerate sono OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 e 7, oltre a Ubuntu 14.04, 12.04 e 18.04 LTS. <\/p>\n

I risultati confermano che anche gli schemi di base, come il canarino nello stack e il codice indipendente dalla posizione, non sono ancora utilizzati da tutti. La situazione \u00e8 ancora peggiore per i compilatori quando si tratta di protezione dalle vulnerabilit\u00e0 come il conflitto dello stack (stack clash), che sono tornate alla ribalta a gennaio dopo la pubblicazione di informazioni sulle vulnerabilit\u00e0 in systemd<\/a><\/noindex>. Ma non \u00e8 tutto cos\u00ec disperato. Una parte significativa dei binari implementa metodi di protezione di base, e il loro numero cresce di versione in versione. <\/p>\n

La verifica ha mostrato che il numero maggiore di metodi di sicurezza \u00e8 implementato in Ubuntu 18.04 a livello di sistema operativo e applicazioni, seguito da Debian 9. D'altra parte, anche OpenSUSE 12.4, CentOS 7 e RHEL 7 implementano schemi di sicurezza di base, mentre la protezione contro il conflitto dello stack \u00e8 applicata ancora pi\u00f9 ampiamente grazie a un set di pacchetti predefiniti decisamente pi\u00f9 robusto.
\n<\/a><\/noindex><\/p>\n

Introduzione<\/h1>\n

\nGarantire un'elevata qualit\u00e0 del software \u00e8 difficile. Nonostante la grande variet\u00e0 di strumenti avanzati per l'analisi statica del codice e l'analisi dinamica in fase di esecuzione, nonch\u00e9 i significativi progressi nel sviluppo di compilatori e linguaggi di programmazione, il software moderno continua a soffrire di vulnerabilit\u00e0 che sono costantemente sfruttate dagli aggressori. La situazione \u00e8 ancora pi\u00f9 critica nelle ecosistemi che includono codice obsoleto. In tali casi, ci troviamo non solo ad affrontare il problema eterno di identificare possibili errori sfruttabili, ma ci troviamo anche vincolati a rigide limitazioni di retrocompatibilit\u00e0 che spesso richiedono di mantenere codice obsoleto, vulnerabile o difettoso.<\/p>\n

Qui entrano in gioco i metodi di protezione o rafforzamento dei programmi (hardening). Alcuni tipi di errori non possiamo prevenire, ma possiamo rendere la vita pi\u00f9 difficile agli aggressori e risolvere parzialmente il problema, prevenendolo o ostacolandolo. sfruttamento<\/i> di questi errori. Questa protezione \u00e8 utilizzata in tutti i moderni sistemi operativi, ma i metodi variano notevolmente in complessit\u00e0, efficacia e prestazioni: dai canarini nello stack (stack canaries) e ASLR<\/a><\/noindex> fino alle protezioni complete. CFI<\/a><\/noindex> e ROP<\/a><\/noindex>. In questo articolo esamineremo quali metodi di protezione sono applicati nelle distribuzioni Linux pi\u00f9 popolari nella configurazione predefinita, e analizzeremo le caratteristiche dei binari distribuiti attraverso i sistemi di gestione dei pacchetti di ciascuna distribuzione.<\/p>\n

CVE e sicurezza<\/h3>\n

\nTutti noi abbiamo visto articoli con titoli come \"Le applicazioni pi\u00f9 vulnerabili dell'anno\" o \"I sistemi operativi pi\u00f9 vulnerabili\". Di solito, questi articoli presentano statistiche sul numero totale di registrazioni delle vulnerabilit\u00e0 di tipo CVE (Common Vulnerability and Exposures)<\/a><\/noindex>, ottenute da National Vulnerability Database (NVD)<\/a><\/noindex> da NIST<\/a><\/noindex> e altre fonti. Successivamente, queste applicazioni o sistemi operativi vengono classificati in base al numero di CVE. Sfortunatamente, sebbene i CVE siano molto utili per monitorare i problemi e informare fornitori e utenti, dicono poco sulla reale sicurezza del software.<\/p>\n

Per esempio, consideriamo il numero totale di CVE negli ultimi quattro anni per il kernel Linux e i cinque pi\u00f9 popolari distribuzioni server, ovvero Ubuntu, Debian, Red Hat Enterprise Linux e OpenSUSE.<\/p>\n

\"Milioni
\nFig. 1<\/i><\/p>\n

Cosa ci dice questo grafico? Un numero maggiore di CVE significa che una distribuzione \u00e8 pi\u00f9 vulnerabile di un'altra? La risposta \u00e8 no. Ad esempio, in questo articolo vedrete che Debian ha meccanismi di protezione pi\u00f9 rigorosi rispetto, ad esempio, a OpenSUSE o RedHat Linux, eppure Debian ha pi\u00f9 CVE. Tuttavia, ci\u00f2 non significa necessariamente una sicurezza compromessa: anche la presenza di CVE non indica se una vulnerabilit\u00e0 \u00e8 sfruttabile<\/i>. I punteggi di gravit\u00e0 offrono un'idea di quanto sia probabile<\/i> l'uso delle vulnerabilit\u00e0, ma in ultima analisi l'esploitabilit\u00e0 dipende in larga misura dalla protezione presente nei sistemi interessati, cos\u00ec come dalle risorse e dalle capacit\u00e0 degli aggressori. Inoltre, l'assenza di segnalazioni CVE non dice nulla su altre non registrate o sconosciute<\/i> vulnerabilit\u00e0. La differenza nel numero di CVE pu\u00f2 essere spiegata non dalla qualit\u00e0 del software, ma da altri fattori, inclusi i fondi destinati ai test o la dimensione della base utenti. Nel nostro esempio, un numero maggiore di CVE in Debian potrebbe semplicemente indicare che Debian fornisce un numero maggiore di pacchetti software. <\/p>\n

Naturalmente, il sistema CVE fornisce informazioni utili che consentono di creare protezioni adeguate. Pi\u00f9 comprendiamo le cause dei guasti del programma, pi\u00f9 \u00e8 facile identificare i possibili modi di sfruttamento e sviluppare meccanismi adeguati di rilevamento e risposta<\/i>. Nella Fig. 2 sono presentate le categorie di vulnerabilit\u00e0 per tutte le distribuzioni negli ultimi quattro anni (fonte<\/a><\/noindex>). \u00c8 evidente che la maggior parte delle CVE ricade nelle seguenti categorie: attacchi di negazione del servizio (DoS), esecuzione di codice, overflow, corruzione della memoria, perdita (esfiltrazione) di informazioni ed escalation di privilegi. Sebbene molte CVE siano registrate pi\u00f9 volte in diverse categorie, nel complesso i problemi rimangono sostanzialmente gli stessi di anno in anno. Nella prossima parte dell'articolo, valuteremo l'uso di schemi di protezione diversi per prevenire lo sfruttamento delle vulnerabilit\u00e0 sopra menzionate.<\/p>\n

\"Milioni
\nFig. 2<\/i><\/p>\n

Attivit\u00e0<\/h3>\n

\nIn questo articolo intendiamo rispondere alle seguenti domande:<\/p>\n