Bug GHOST: esiste un modo semplice per verificare se il mio sistema è sicuro?

Sembra che tu possa scaricare uno strumento da Università di Chicago che ti consentirà di testare il tuo sistema per la vulnerabilità .

Questo non ripara o riavvia nulla ti dirà solo se il tuo sistema è vulnerabile.

$ wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c $ gcc GHOST.c -o GHOST $ ./GHOST [responds vulnerable OR not vulnerable ] 

Eseguendolo su uno dei miei server remoti ottengo:

user@host:~# wget https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c --2015-01-27 22:30:46-- https://webshare.uchicago.edu/orgs/ITServices/itsec/Downloads/GHOST.c Resolving webshare.uchicago.edu (webshare.uchicago.edu)... 128.135.22.61 Connecting to webshare.uchicago.edu (webshare.uchicago.edu)|128.135.22.61|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1046 (1.0K) [text/x-csrc] Saving to: `GHOST.c" 100%[============================================>] 1,046 --.-K/s in 0s 2015-01-27 22:30:48 (237 MB/s) - `GHOST.c" saved [1046/1046] user@host:~# gcc GHOST.c -o GHOST user@host:~# ./GHOST vulnerable 

Il il codice sorgente di quello script assomiglia al seguente blocco di codice ma dovresti prima controllare il codice di origine . Come altri hanno sottolineato, se esegui arbitrariamente codice da Internet senza sapere cosa fa, potrebbero accadere cose brutte :

/* * GHOST vulnerability check * http://www.openwall.com/lists/oss-security/2015/01/27/9 * Usage: gcc GHOST.c -o GHOST && ./GHOST */ #include <netdb.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #define CANARY "in_the_coal_mine" struct { char buffer[1024]; char canary[sizeof(CANARY)]; } temp = { "buffer", CANARY }; int main(void) { struct hostent resbuf; struct hostent *result; int herrno; int retval; /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/ size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1; char name[sizeof(temp.buffer)]; memset(name, "0", len); name[len] = "\0"; retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno); if (strcmp(temp.canary, CANARY) != 0) { puts("vulnerable"); exit(EXIT_SUCCESS); } if (retval == ERANGE) { puts("not vulnerable"); exit(EXIT_SUCCESS); } puts("should not happen"); exit(EXIT_FAILURE); } 

Modifica : ho aggiunto un playbook ansible qui se è utile a chiunque, se ne hai un numero elevato di sistemi da testare poi ansible ti permetterà di farlo velocemente.

Inoltre, come da discussione di seguito, se trovi i tuoi server vulnerabili e applichi le patch disponibili, è altamente raccomandato di riavviare il sistema .

Commenti

• @KasperSouren Ebbene sì. Se è vulnerabile, applica la patch / aggiornamento e riavvia.
• @KasperSouren Quello che ‘ stai chiedendo è francamente un po sciocco. Questa risposta risponde perfettamente alla tua domanda: come faccio a rilevare questa vulnerabilità. Questo è tutto ciò che hai chiesto ‘. Anche la richiesta di ” una riga ” è un po sciocca. Ho eseguito il test che ha pubblicato qui su tutti i miei server in meno di 2 minuti. ‘ è semplicissimo. Solo ” shutdown -r ora ” dopo che ‘ hai finito ….. ..
• Ho aggiornato, eseguito il test, ‘ non riavviato. Sono tornato a questo solo quando ho scoperto che dovevo riavviare. Ciò potrebbe accadere a un bel po di persone ei loro server potrebbero essere vulnerabili e potrebbero essere violati nonostante il loro falso senso di sicurezza. Quindi non è così sciocco capire se possibile IMHO.
• Il GHOST.c POC proviene da il Qualys originale advisory .
• @KasperSouren un test può dirti che i nuovi programmi useranno una versione sicura di glibc. Tuttavia, potresti avere programmi in esecuzione in background che sono stati avviati prima dellaggiornamento e quindi avere caricato la vecchia versione.

La risposta di aaronfay “è già stata spiegata per determinare se il tuo sistema sottostante è vulnerabile, ma non rileva se ci sono programmi che sono ancora in esecuzione utilizzando la vecchia versione di glibc dopo laggiornamento. Cioè, potresti aggiornare senza riavviare i processi interessati e lo script segnalerebbe “non vulnerabile” anche se la vecchia libreria vulnerabile è ancora in uso.

Ecco un modo per verificare se ce ne sono programmi collegati dinamicamente che utilizzano ancora la vecchia versione di glibc:

sudo lsof | grep libc- | grep DEL 

Se ci sono risultati, le versioni eliminate di glibc sono in uso e i processi che le utilizzano potrebbero essere vulnerabile.

Ovviamente, questo non copre il caso in cui glibc fosse linkato staticamente. La buona (?) notizia è che è molto raro trovare glibc linkato staticamente in un binario, sia perché delle dimensioni e perché presenta altri fastidi e difficoltà. Nel caso in cui hai programmi che utilizzano una glibc compilata staticamente (cosa che quasi certamente non “t), dovresti ricompilarli.

Commenti

• lsof +c0 -f -- /usr/lib64/libc-*.so | grep "(deleted)$" un po più preciso, mostra i nomi completi dei processi e cerca collegamenti ai file che sono stati eliminati.

Se hai un account in Redhat, puoi accedere al loro “rilevatore GHOST” su questo URL . È un piccolo script di shell che ti dirà se il tuo glibc è vulnerabile.

Red Hat è tornato e ha dichiarato che il loro script di rilevamento è difettoso. Si noti che cè anche un problema su RHEL6.6 quando si utilizza yum –security per correggere la vulnerabilità poiché è stata persa secondo https://bugzilla.redhat.com/show_bug.cgi?id=1186717 .

Commenti

• Lo strumento RedHat controlla solo la versione dellRPM glibc , e solo conosce le versioni di RedHat (e probabilmente i derivati). In realtà non funziona su nessun altro sistema operativo.
• Anche questo non è più disponibile per il download, probabilmente a causa dei difetti.