Home > GNU/Linux, Sicurezza e GNU/Linux > Sicurezza e GNU/Linux (11): l’hardening, ovvero come a livello di sistema si prevengono le vulnerabilità – 1

Sicurezza e GNU/Linux (11): l’hardening, ovvero come a livello di sistema si prevengono le vulnerabilità – 1

Riprendo il discorso Sicurezza e GNU/Linux con un post riassuntivo sulle misure che permettono di prevenire le vulnerabilità dei programmi. Per capire di che parliamo, prima è necessario rileggere i primi post di questa categoria: 1 e 2 .

Riassumendo: un programma vulnerabile è un software che, a causa di un mancato controllo sui dati in ingresso, permette ad un malintenzionato di confezionare un insieme di dati (ad esempio in un file oppure in un pacchetto spedito via rete) che inducono il programma a comportamenti non previsti.

Per prevenire tali comportamenti, abbiamo già visto che Apparmor crea una sorta di “camera stagna” intorno al programma, evitando che esso possa commettere azioni non esplicitamente previste. Ora la domanda è: si può fare di più? Possiamo cioè fare in modo che, anche senza controllare il programma con un sistema MAC come Apparmor, si eviti che le vulnerabilità siano sfruttabili? La risposta è sì. Ci sono moltissimi modi per farlo e Ubuntu li implementa quasi tutti, anche se non su tutti i programmi, perché alcune di queste metodologie diminuiscono le prestazioni oppure possono rendere il programma malfunzionante. Ad essere particolarmente sorvegliati, come nel caso di Apparmor, sono i software potenzialmente pericolosi, a partire dai server Web (apache) e database (mysql).

Ma passiamo al dunque. Vedrete che molte delle funzioni che illustrerò si sovrappongono, fanno cioè quasi la stessa cosa, ma la loro presenza contemporanea è una misura di hardening (rafforzamento) della sicurezza. Inoltre quasi tutte sono forme di sicurezza proattiva: ovvero tendono ad anticipare il problema prima che si presenti. In tal modo anche se un programma non è aggiornato o contiene una vulnerabilità non ancora corretta, è più difficile o addirittura impossibile sfruttarla.

Stack protector: l’area di stack è un’area di memoria in cui i programmi memorizzano parte delle variabili e i parametri che vengono passati da una funzione all’altra di un programma. Contiene anche l’indirizzo di ritorno, cioè dove il processore deve riprendere l’esecuzione dopo che un sottoprogramma viene eseguito. Corrompendo lo stack è quindi possibile fare in modo che un programma salti in un punto sbagliato. I programmi compilati con l’opzione  -fstack-protector del compilatore gcc (la maggioranza) introducono un certo numero di byte di dati casuale prima dell’indirizzo di ritorno e, prima che la funzione termini e torni al chiamante, controllano che siano ancora lì come erano prima. Se non li trova, il programma viene interrotto. Questo meccanismo è chiamato Stack Smashing Protection (SSP) e i byte aggiuntivi sono detti “canary” (canarino), come i cararini usati nelle miniere per accorgersi se ci sono gas velenosi (infatti i canarini muoiono diverso tempo prima di un essere umano in presenza di tali gas). Con lo SSP è molto più complicato riuscire a corrompere lo stack in modo date da truccare l’indirizzo di ritorno. Inoltre vengono prese precauzioni nella memorizzazione dei vettori (cioè variabili composte da più celle di memoria una di seguito all’altra) nello stack.

Heap protector: l’heap è un’altra area cruciale della memoria, dove vengono allocati i dati di maggiori dimensioni (ad esempio un’immagine caricata in memoria). Anche attraverso la corruzione dello heap è possibile eseguire codice arbitrario. L’heap protector, implementato nella libreria di sistema glibc, utilizza varie tecniche per prevenire questo tipo di vulnerabilità.

ASLR (Address Space Layout Randomization): per sfruttare molte vulnerabilità è necessario che l’attaccante possa prevedere dove un programma viene caricato in memoria o dove memorizza i dati. Pertanto, per prevenire lo sfruttamento di queste vulnerabilità, è sufficiente fare in modo che codice e dati di un programma vengano memorizzati in posizioni casuali, quindi non prevedibili. Su Ubuntu l’ASLR è implementato sullo stack, sulle librerie da cui i programmi dipendono (cioè anche le librerie vengono caricate in posizioni casuali), sulla parte eseguibile del programma, sull’area di memoria brk (la memoria aggiuntiva allocata a richiesta dai programmi) e sul vdso, ovvero l’area che contiene gli indirizzi delle funzioni interne del kernel chiamabili dallo spazio utente (librerie e programmi).

In particolare l’ASLR della parte eseguibile del programma è implementata su diversi software, tra cui Firefox, il server di stampa CUPS, Apache, Samba, MySQL, Totem, il lettore di PDF Evince (il PDF è notoriamente un formato molto colpito da malware).

Fortify Source: il compilatore gcc è in grado di scovare molti errori comuni di programmazione e correggerli automaticamente. In particolare la compilazione con l’opzione Fortify Source permette di sostituire alcune funzioni insicure di manipolazione delle stringhe con versioni più sicure, fare controlli sui parametri di alcune chiamate di sistema e su come si aprono i file.

RELRO e BIND_NOW: La tecnica RELRO (read-only relocation table) impedisce che vengano sovrascritti gli indirizzi di chiamata delle funzioni. Poiché gli indirizzi delle funzioni contenute in librerie esterne vengono calcolati quando esse vengono chiamate, la tecnica non funzionerebbe perché necessita che la tabella con gli indirizzi sia non scrivibile. Pertanto viene usata con l’opzione BIND_NOW che obbliga il sistema a calcolare gli indirizzi delle funzioni nelle librerie esterne al caricamento del programma e non durante l’esecuzione.

Pointer Obfuscation: i puntatori alle funzioni di glibc più sfruttate negli attacchi sono offuscati, combinandoli con un numero casuale. In questo modo si previene la loro sovrascrittura da parte di un attaccante che tenta di dirottare l’esecuzione verso una sua routine.

NX (Non-executable): molti processori moderni permettono di segnare un’area di memoria dati come non eseguibile. Se l’attaccante ha creato ad esempio una finta immagine che contiene codice malevolo e tenta di far saltare il programma a questo codice (ammesso che ci riesca superando le protezioni che abbiamo già visto) il processore si rifiuterà comunque di eseguire il codice perché contenuto in un’area dati (tipicamente l’heap).  Questa tecnica è implementata completamente (a livello hardware) solo sui sistemi 64 bit o sui 32 bit che usano i kernel “pae”. Per gli altri, viene implementata a livello software (ExecShield). Da Ubunt 11.04 se nel BIOS viene disabilitata la funzione NX, il kernel non ne tiene conto e l’abilita comunque. Per controllare se la CPU supporta NX, basta leggere le rige “flags” in /proc/cpuinfo.

Protezione di /proc/$pid/maps: ogni processo è associato ad una mappa di memoria leggibile in /proc/$pid/maps (dove $PID è il numero identificativo del processo).  Questa mappa viene resa non leggibile agli utenti diversi dal proprietario del processo, cioè l’utente che l’ha lanciato. In tal modo informazioni delicate di processi che girano sotto root sono inaccessibili all’utente normale.

SECCOMP: Il kernel blocca le richieste non previste da parte di alcuni programmi. Se un programma è compilato in modo da sfruttare SECCOMP si trova quindi in una condizione di “sandbox”. Solo le chiamate di sistema autorizzate sono eseguite, mentre le altre sono ignorate. Questo meccanismo, finora in genere trascurato, è stato notevolmente migliorato nel kernel 3.2 grazie al contributo di Google.

(continua…)

  1. 7 dicembre 2011 alle 8:34

    Articolo molto interessante. È proprio quello che serviva, grazie!!!

  2. hug
    20 dicembre 2011 alle 9:38

    Ciao Guido,
    rimanendo in topic, ogni tanto ho qualche dubbio sul funzionamento di Ufw. Se chiudo tutte le porte in entrata il programma per i torrent continua a funzionare.
    Due volte a settimana poi mi capita di avere il carico di sistema al 100% ed in cima alla classifica di Top trovo: update-apt-xapi o update.mlocat .
    Almeno 2 volte a settimana, è normale?
    ciao

  3. 5 luglio 2013 alle 4:39

    Have you been perusing catalogs of vehicle units and equipment?

    Occasionally configuration is also expected so that added softwares can be
    employed.

  4. 24 maggio 2014 alle 8:08

    I am really impressed with your writing skills as well as
    with the layout on your blog. Is this a paid theme or did you modify it yourself?

    Either way keep up the excellent quality writing, it is rare to
    see a great blog like this one nowadays.

  1. No trackbacks yet.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: