GHOST-fel: Finns det ett enkelt sätt att testa om mitt system är säkert?

Det verkar som om du kan ladda ner ett verktyg från University of Chicago som låter dig testa ditt system för sårbarhet .

Detta reparerar eller startar inte om någonting det berättar bara om ditt system är sårbart.

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

Kör detta på en av mina fjärrservrar får jag:

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 

källkoden för det skriptet ser ut som nästa kodblock men du bör inspektera ursprungskoden först ändå . Som andra har påpekat, om du godtyckligt kör kod från internet utan att veta vad det gör kan dåliga saker hända :

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

Redigera : Jag har lagt till en ansiktsbok här om den är användbar för någon, om du har ett stort antal av system för att testa då ansible gör att du kan göra det snabbt.

Dessutom, enligt diskussionen nedan, om du tycker att dina servrar är sårbara och tillämpar tillgängliga korrigeringar, är det starkt rekommenderat att du startar om ditt system .

Kommentarer

• @KasperSouren Tja, ja. Om det är sårbart, använd patch / uppgradering och starta om.
• @KasperSouren Vad du ’ frågar är uppriktigt sagt lite dumt. Det här svaret svarar perfekt på din fråga: hur upptäcker jag denna sårbarhet. Det ’ är allt du frågade. Att be om en ” en liner ” är också lite dumt. Jag körde testet som han publicerade här på alla mina servrar på under 2 minuter. Det ’ är dött enkelt. Bara ” avstängning -r nu ” när du ’ är klar ….. ..
• Jag uppgraderade, körde testet, startade inte ’. Kom bara tillbaka till detta när jag fick reda på att jag var tvungen att starta om. Detta kan hända med en hel del människor och deras servrar kan vara sårbara och kan hackas trots deras falska känsla av säkerhet. Så inte så dumt att få det här om möjligt IMHO.
• GHOST.c POC härstammar från originalet Qualys rådgivande .
• @KasperSouren ett test kan berätta att nya program kommer att använda en säker version av glibc. Du kan dock ha program som körs i bakgrunden som startade före uppgraderingen och därför har du laddat den gamla versionen.

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)" 

Om de ger dig segfel (ja, en Python-segfault, ett sällsynt exemplar) är du ”sårbar. Jag vet inte om du anser att Python är ett” utvecklarverktyg ”men PHP är ett vanligt program att ha.

Om målenheten är en router vet jag inte om något du kan göra på den som skulle berätta för dig, förutom att gräva i tillverkarens specifikationer och / eller vänta på tillverkarens råd och firmwareuppdateringar.

Kommentarer

• Är det möjligt att kombinera detta med sudo lsof | grep libc- | grep DEL"? Tillhandahålls i en annan kommentar, för att undvika att människor tror att de ’ är säkra medan den gamla libc fortfarande används. Med detta tillägg kommer jag ’ att ge ut bounty genast.
• Det ’ ett skalkommando, så att du kan klara saker med & &. Och det kommandot är först efter att du har uppdaterat dina glibc-paket.Om du ’ har uppdaterat kommer de här linjerna att misslyckas. Så fylla din uppdatering vommamd däremellan?
• Jag använde php-en på SUSE 11SP3 och jag såg ingen segfault före eller efter lappning. Några idéer?
• @marcin Det ’ är intressant. Jag hämtade dessa från internetkällor, och många människor rapporterar segfaulting. Gör det att öka slingantalet? (För vad det ’ är värt, kommer segfaulten för Python att segfaulta på vissa patchade system också … inget ord om varför den ’ s händer.)
• Från att spela med uchicago-koden ser det ut som om du försöker överflödas med mer än fyra byte eller så kommer gethostbyname () att returnera ett fel (EINVAL) istället för att flyta över. Med C kan du kontrollera exakt vad som skrivs över. Med PHP eller Python kan det som blir överskrivet vara viktigt och segfault, eller det kan vara ingenting; det ’ kommer att vara beroende av systemets exakta uppbyggnad. Och Pythons segfault på gethostbyname("0"*50000000) ser mer ut som ett fel i Python för mig. (Ghost Python?)

aaronfays svar redan täckt för att avgöra om ditt underliggande system är sårbart, men det upptäcker inte om det finns program som fortfarande körs med den gamla versionen av glibc efter uppgraderingen. Det vill säga du kan uppgradera utan att starta om de berörda processerna och skriptet rapporterar ”inte sårbart” även om det gamla, sårbara biblioteket fortfarande används.

Här är ett sätt att kontrollera om det finns några dynamiskt länkade program som fortfarande använder den gamla versionen av glibc:

sudo lsof | grep libc- | grep DEL 

Om det finns resultat används raderade versioner av glibc och processerna som använder dem kan vara sårbart.

Naturligtvis täcker detta inte fallet där glibc var statiskt kopplat. Den goda (?) nyheten är att det är mycket sällsynt att hitta glibc statiskt kopplat i en binär, både för att av storleken, och eftersom det ger några andra irritationer och svårigheter. Om du gör har program som använder en statiskt sammanställt glibc (som du nästan säkert inte behöver), måste du kompilera dem igen.

Kommentarer

• lsof +c0 -f -- /usr/lib64/libc-*.so | grep "(deleted)$" lite mer exakt, visar fullständiga namn på processer och letar efter länkar till filer som har tagits bort.

Om du har ett konto i Redhat kan du komma åt deras ”GHOST-detektor” på den här webbadressen . Det är ett litet skalskript som berättar om din glibc är sårbar.

Red Hat har nu kommit tillbaka och uppgav att deras detektorskript är felaktigt. Observera att det också finns en oro för RHEL6.6 när du använder yum –security för att patcha sårbarheten eftersom den har missats enligt https://bugzilla.redhat.com/show_bug.cgi?id=1186717 .

Kommentarer

• RedHat-verktyget kontrollerar endast versionen av glibc RPM , och det bara känner till RedHat-versioner (och förmodligen derivat). Det fungerar faktiskt inte på något annat operativsystem.
• Detta är inte heller tillgängligt för nedladdning, troligen med brister.