Eroare GHOST: există o modalitate simplă de a testa dacă sistemul meu este sigur?

Se pare că puteți descărca un instrument de la de la Universitatea din Chicago care vă va permite să testați vulnerabilitatea sistemului dvs. .

Aceasta nu repară sau repornește nimic vă va spune doar dacă sistemul dvs. este vulnerabil.

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

Rulând pe unul dintre serverele mele la distanță primesc:

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 

codul sursă al acelui script arată ca următorul bloc de cod , dar oricum ar trebui să inspectați codul de origine . După cum au subliniat alții, dacă rulați în mod arbitrar cod de pe internet fără să știți ce face, atunci se pot întâmpla lucruri rele :

/* * 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); } 

Editați : „Am adăugat un playbook ansible aici dacă este de folos oricui, dacă aveți un număr mare de sisteme pentru a testa apoi ansible vă va permite să faceți acest lucru rapid.

De asemenea, conform discuțiilor de mai jos, dacă găsiți că serverele dvs. sunt vulnerabile și aplicați patch-uri disponibile, este recomandat să reporniți sistemul .

Comentarii

• @KasperSouren Ei bine, da. Dacă este vulnerabil, aplicați patch-ul / actualizați și reporniți.
• @KasperSouren Ceea ce cereți ‘ este sincer puțin prost. Acest răspuns răspunde perfect la întrebarea dvs.: cum detectez această vulnerabilitate. Asta ‘ este tot ce ai cerut. Solicitarea unui ” o linie ” este, de asemenea, puțin prostească. Am efectuat testul pe care l-a postat aici pe toate serverele mele în mai puțin de 2 minute. Este ‘ simplu mort. Doar ” oprire -r acum ” după ce ‘ ați terminat ….. ..
• Am făcut upgrade, am rulat testul, nu am repornit ‘. Am revenit la acest lucru doar când am aflat că trebuie să repornesc. Acest lucru s-ar putea întâmpla cu destul de mulți oameni și serverele lor ar putea fi vulnerabile și ar putea fi piratate în ciuda falsului lor sentiment de securitate. Deci nu atât de prost pentru a obține acest lucru direct, dacă este posibil IMHO.
• POC-ul GHOST.c provine din din calitatea originală consultativ .
• @KasperSouren un test vă poate spune că noile programe vor folosi o versiune sigură a glibc. Cu toate acestea, este posibil să aveți programe care rulează în fundal care au început înainte de actualizare și, prin urmare, ați încărcat vechea versiune.

PHP one-liner:

php -r "$e="0";for($i=0;$i<2500;$i++){$e="0$e";gethostbyname($e); }" 

Python one-liner:

python -c "import socket;y="0"*50000000;socket.gethostbyname(y)" 

Dacă acestea vă oferă segfaults (da, un Python segfault, un specimen rar), atunci sunteți „vulnerabil. Nu știu dacă considerați Python un„ instrument pentru dezvoltatori ”, dar PHP este un program obișnuit.

Dacă dispozitivul țintă este un router, nu știu nimic din ceea ce ați putea face pe acesta, care să vă spună, cu excepția căutării în specificațiile producătorului și / sau așteptarea recomandărilor producătorului și a actualizărilor de firmware.

Comentarii

• Este posibil să combinați acest lucru cu sudo lsof | grep libc- | grep DEL"? Furnizat într-un alt comentariu, pentru a evita acest lucru oamenii cred că ‘ sunt în siguranță în timp ce vechiul libc este încă în uz. Cu această adăugare voi ‘ voi da recompensa imediat.
• Este ‘ o comandă shell, astfel încât să puteți aborda lucrurile cu & &. Și acea comandă este numai după ce v-ați actualizat pachetele glibc.Dacă ‘ ați actualizat, aceste linere vor eșua. Deci, puneți-vă actualizarea în vommamd?
• Am folosit cel php pe SUSE 11SP3 și nu am văzut segfault înainte sau după corecție. Aveți idei?
• @marcin Este ‘ interesant. Le-am extras din surse de internet și o mulțime de oameni au raportat că sunt segmente. Creșterea numărului de bucle face ceva? (Pentru ceea ce valorează ‘, segfault-ul pentru Python va fi difuzat și pe unele sisteme patch-uri … niciun cuvânt despre motivul pentru care ‘ Se întâmplă.)
• De la jocul cu codul uchicago, se pare că dacă încercați să depășiți cu mai mult de 4 octeți, gethostbyname () va returna o eroare (EINVAL) în loc să depășească. Cu C puteți controla exact ceea ce este suprascris. Cu PHP sau Python, ceea ce devine suprascris poate fi important și separat, sau s-ar putea să nu fie nimic; ‘ va depinde de construcția exactă a sistemului. Iar segfault-ul Python de pe gethostbyname("0"*50000000) mi se pare mai degrabă un bug din Python. (Ghost Python?)

răspunsul aaronfay ”deja acoperit, determinând dacă sistemul dvs. de bază este vulnerabil, dar nu detectează dacă există programe care încă rulează folosind vechea versiune de glibc după actualizare. Adică, puteți face upgrade fără a reporni procesele afectate, iar scriptul ar raporta „nu este vulnerabil”, chiar dacă vechea bibliotecă vulnerabilă este încă în uz.

Iată o modalitate de a verifica dacă există programe conectate dinamic care încă folosesc vechea versiune a glibc:

sudo lsof | grep libc- | grep DEL 

Dacă există rezultate, versiunile șterse ale glibc sunt utilizate și procesele care le utilizează pot fi vulnerabil.

Desigur, acest lucru nu acoperă cazul în care glibc a fost legat static. Vestea bună (?) este că este foarte rar să găsești glibc legat static într-un binar, atât pentru că de dimensiune și pentru că prezintă alte neplăceri și dificultăți. În cazul în care aveți programe care utilizează un glibc compilat static (pe care aproape sigur nu îl aveți), ar trebui să le recompilați.

Comentarii

• lsof +c0 -f -- /usr/lib64/libc-*.so | grep "(deleted)$" un pic mai precis, vă arată numele complete ale proceselor și caută legătura cu fișierele șterse.

Dacă aveți un cont în Redhat, puteți accesa „detectorul GHOST” al acestora la această adresă URL . Este un mic script shell care vă va spune dacă glibc este vulnerabil.

Red Hat a revenit acum și a declarat că scriptul lor de detector este defect. Rețineți că există și o îngrijorare cu privire la RHEL6.6 atunci când se utilizează yum –security pentru a corela vulnerabilitatea, deoarece a fost ratată conform https://bugzilla.redhat.com/show_bug.cgi?id=1186717 .

Comentarii

• Instrumentul RedHat verifică doar versiunea glibc RPM , și numai știe despre versiunile RedHat (și probabil derivate). De fapt, nu funcționează pe niciun alt sistem de operare.
• De asemenea, acesta nu mai este disponibil pentru descărcare, probabil că faceți greșeli.