{"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 Linux si \u00e8 consolidato","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MilioniTL;DR<\/b>. In questo articolo esploreremo gli schemi di protezione (hardening schemes) che funzionano di default in cinque popolari distribuzioni Linux. Per ciascuna abbiamo preso la configurazione del kernel predefinita, caricato tutti i pacchetti e analizzato gli schemi di protezione nei file binari incorporati. Vengono considerati i seguenti sistemi: 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 le canarini dello stack e il codice indipendente dalla posizione, non sono ancora adottati da tutti. La situazione \u00e8 ancora peggiore per i compilatori quando si tratta di proteggere contro vulnerabilit\u00e0 come lo stack clash, che ha attirato l'attenzione a gennaio dopo la pubblicazione di informazioni sulle vulnerabilit\u00e0 in systemd.<\/a><\/noindex>. Ma non \u00e8 tutto cos\u00ec disperato. In una parte significativa dei binari sono implementati metodi di protezione di base, e il loro numero cresce ad ogni versione. <\/p>\n

La verifica ha mostrato che il numero maggiore di metodi di protezione \u00e8 implementato in Ubuntu 18.04 a livello di sistema operativo e applicazioni, seguito da Debian 9. D'altra parte, anche in OpenSUSE 12.4, CentOS 7 e RHEL 7 sono implementati schemi di protezione di base, mentre la protezione contro lo stack clash \u00e8 applicata in modo pi\u00f9 ampio con un set di pacchetti predefiniti molto pi\u00f9 denso.
\n<\/a><\/noindex><\/p>\n

Introduzione<\/h1>\n

\nGarantire un'alta qualit\u00e0 del software \u00e8 difficile. Nonostante l'enorme quantit\u00e0 di strumenti avanzati per l'analisi statica del codice e l'analisi dinamica durante l'esecuzione, cos\u00ec come i notevoli progressi nello sviluppo di compilatori e linguaggi di programmazione, il software moderno continua a soffrire di vulnerabilit\u00e0 che vengono costantemente sfruttate dai malintenzionati. La situazione \u00e8 ancora peggiore negli ecosistemi che includono codice obsoleto. In questi casi non solo affrontiamo il problema eterno della ricerca di potenziali errori sfruttabili, ma siamo anche limitati da rigide linee guida di retrocompatibilit\u00e0, che spesso richiedono di mantenere codice limitato, e ancor peggio vulnerabile o buggato.<\/p>\n

Qui entrano in gioco i metodi di protezione o di indurimento dei programmi (hardening). Alcuni tipi di errori non possiamo prevenirli, ma possiamo rendere la vita dei malintenzionati pi\u00f9 difficile e risolvere parzialmente il problema, prevenendo o ostacolando. sfruttamento<\/i> queste vulnerabilit\u00e0. Tale protezione \u00e8 utilizzata in tutti i moderni sistemi operativi, ma i metodi possono variare notevolmente in complessit\u00e0, efficacia e prestazioni: dai 'canarini nello stack' (stack canaries) e ASLR<\/a><\/noindex> fino a protezioni complete CFI<\/a><\/noindex> e ROP<\/a><\/noindex>. In questo articolo esamineremo quali metodi di protezione vengono applicati nelle distribuzioni Linux pi\u00f9 popolari con configurazioni predefinite e studieremo le propriet\u00e0 dei pacchetti 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, in essi viene fornita statistica sul numero totale di registrazioni di vulnerabilit\u00e0 tipo CVE (Common Vulnerability and Exposures)<\/a><\/noindex>, ottenuta da National Vulnerability Database (NVD)<\/a><\/noindex> di NIST<\/a><\/noindex> e altre fonti. Successivamente, queste applicazioni o sistemi operativi vengono classificati in base al numero di CVE. Sfortunatamente, sebbene le CVE siano molto utili per monitorare i problemi e informare fornitori e utenti, esse dicono poco sulla reale sicurezza del software.<\/p>\n

Per esempio, consideriamo il numero totale di CVE nell'ultimo quadriennio per il kernel Linux e per cinque delle distribuzioni server pi\u00f9 popolari, 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 implementa meccanismi di protezione pi\u00f9 severi rispetto, ad esempio, a OpenSUSE o RedHat Linux, eppure ha un numero maggiore di CVE. Tuttavia, ci\u00f2 non implica necessariamente una sicurezza compromessa: anche la presenza di CVE non indica se una vulnerabilit\u00e0 \u00e8 sfruttabile<\/i>. I punteggi di gravit\u00e0 forniscono un'idea di quanto sia probabile<\/i> sfruttare una vulnerabilit\u00e0, ma alla fine l'effettiva sfruttabilit\u00e0 dipende in larga misura dalla protezione presente nei sistemi interessati, nonch\u00e9 dalle risorse e dalle capacit\u00e0 degli aggressori. Inoltre, l'assenza di report CVE non dice nulla su altre vulnerabilit\u00e0 non registrate o sconosciute<\/i> vulnerabilit\u00e0. La differenza nel CVE pu\u00f2 essere spiegata non dalla qualit\u00e0 del software, ma da altri fattori, inclusi le risorse dedicate ai test o la dimensione della base utenti. Nel nostro esempio, un numero maggiore di CVE in Debian potrebbe semplicemente indicare che Debian fornisce pi\u00f9 pacchetti software. <\/p>\n

Naturalmente, il sistema CVE fornisce informazioni utili che consentono di creare le protezioni adeguate. Pi\u00f9 comprendiamo le cause dei malfunzionamenti del programma, pi\u00f9 semplice risulta identificare i possibili modi di sfruttamento e sviluppare i meccanismi appropriati. di rilevamento e risposta.<\/i>Nella Fig. 2 sono mostrate le categorie delle vulnerabilit\u00e0 per tutte le distribuzioni negli ultimi quattro anni (fonte<\/a><\/noindex>). \u00c8 immediatamente evidente che la maggior parte delle CVE rientrano nelle seguenti categorie: attacchi di negazione del servizio (DoS), esecuzione di codice, overflow, corruzione di memoria, fuga (exfiltrazione) di informazioni ed escalation dei privilegi. Anche se molte CVE sono contabilizzate pi\u00f9 volte in diverse categorie, in generale, gli stessi problemi persistono di anno in anno. Nella parte successiva dell'articolo, valuteremo l'uso di diversi schemi di protezione per prevenire lo sfruttamento delle vulnerabilit\u00e0 indicate.<\/p>\n

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

Problemi<\/h3>\n

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