GHOST-feil: er det en enkel måte å teste om systemet mitt er sikkert?

Det ser ut til at du kan laste ned et verktøy fra University of Chicago som lar deg teste systemet ditt for sårbarhet .

Dette reparerer eller starter ikke noe , det vil bare fortelle deg om systemet ditt er sårbart.

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

Kjører dette på en av mine eksterne servere får jeg:

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 

The kildekoden til skriptet ser ut som denne neste kodeblokken , men du bør inspisere opprinnelseskoden først uansett . Som andre har påpekt, hvis du kjører vilkårlig fra internett uten å vite hva det gjør, kan dårlige ting skje :

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

Rediger : Jeg har lagt til en brukbar spillbok her hvis den er til bruk for noen, hvis du har et stort antall av systemer for å teste deretter ansible vil tillate deg å gjøre det raskt.

Også, som beskrevet i diskusjonen nedenfor, hvis du finner serverne dine er sårbare og bruker tilgjengelige oppdateringer, er det sterkt anbefalt at du starter systemet på nytt .

Kommentarer

• @KasperSouren Vel, ja. Hvis det er sårbart, bruk oppdateringen / oppgraderingen og start den på nytt.
• @KasperSouren Det du ‘ spør, er ærlig talt litt dumt. Dette svaret svarer perfekt på spørsmålet ditt: hvordan oppdager jeg dette sikkerhetsproblemet. Det ‘ er alt du spurte. Å be om en » en liner » er også litt dumt. Jeg kjørte testen han la ut her på alle serverne mine på under 2 minutter. Det ‘ er døds enkelt. Bare » nedleggelse -r nå » etter at du ‘ er ferdig ….. ..
• Jeg oppgraderte, kjørte testen, startet ikke ‘. Kom bare tilbake til dette da jeg fant ut at jeg måtte starte på nytt. Dette kan skje med ganske mange mennesker, og serverne deres kan være sårbare og kan bli hacket til tross for deres falske følelse av sikkerhet. Så ikke så dumt å få dette rett hvis mulig IMHO.
• GHOST.c POC stammer fra den originale Qualys rådgivende .
• @ KasperSouren en test kan fortelle deg at nye programmer vil bruke en trygg versjon av glibc. Du kan imidlertid ha programmer som kjører i bakgrunnen som startet før oppgraderingen, og derfor har du lastet inn den gamle versjonen.

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

Hvis de gir deg segfaults (ja, en Python-segfault, en sjelden prøve), er du «sårbar. Jeg vet ikke om du anser Python som et» utviklerverktøy «, men PHP er et vanlig program å ha.

Hvis målenheten er en ruter, vet jeg ikke noe du kan gjøre på den som vil fortelle deg, bortsett fra å grave i produsentens spesifikasjoner og / eller vente på produsentens råd og firmwareoppdateringer.

Kommentarer

• Er det mulig å kombinere dette med sudo lsof | grep libc- | grep DEL"? Gitt i en annen kommentar, for å unngå at folk tror de ‘ er trygge mens den gamle libc fortsatt er i bruk. Med dette tillegget vil jeg ‘ gi ut dusøren med en gang.
• Det ‘ en shell-kommando, slik at du kan takle ting med & &. Og den kommandoen er først etter at du har oppdatert glibc-pakkene dine.Hvis du ‘ har oppdatert, vil disse linjene mislykkes. Så fylle oppdateringen din vommamd innimellom?
• Jeg brukte php-en på SUSE 11SP3, og jeg så ingen segfault før eller etter lappingen. Noen ideer?
• @marcin Det er ‘ interessant. Jeg hentet disse fra internettkilder, og mange rapporterer om feil. Gjør det noe å øke løkkeantallet? (For hva det ‘ er verdt, vil segfault for Python også segfault på noen lappede systemer … ikke noe ord på hvorfor den ‘ s skjer.)
• Fra å leke med uchicago-koden, ser det ut som om du prøver å strømme over mer enn 4 byte eller så, vil gethostbyname () returnere en feil (EINVAL) i stedet for å overfylle. Med C kan du kontrollere nøyaktig hva som blir overskrevet. Med PHP eller Python kan det som blir overskrevet være viktig og segfeilt, eller det kan være ingenting; det ‘ vil være avhengig av den nøyaktige utformingen av systemet. Og Python-segfaulten på gethostbyname("0"*50000000) ser mer ut som en feil i Python for meg. (Ghost Python?)

aaronfays svar allerede dekket for å avgjøre om det underliggende systemet ditt er sårbart, men det oppdager ikke om det er programmer som fortsatt kjører med den gamle versjonen av glibc etter oppgradering. Det vil si at du kan oppgradere uten å starte de berørte prosessene på nytt, og skriptet rapporterer «ikke sårbart» selv om det gamle, sårbare biblioteket fortsatt er i bruk.

Her er en måte å sjekke om det er noen dynamisk koblede programmer som fremdeles bruker den gamle versjonen av glibc:

sudo lsof | grep libc- | grep DEL 

Hvis det er resultater, er slettede versjoner av glibc i bruk, og prosessene som bruker dem kan være sårbar.

Dette dekker selvfølgelig ikke saken der glibc var statisk knyttet. Den gode (?) nyheten er at det er veldig sjelden å finne glibc statisk knyttet i en binær, begge fordi av størrelsen, og fordi det gir andre irritasjoner og vanskeligheter. I tilfelle at du gjør har programmer som bruker et statisk kompilert glibc (som du nesten ikke trenger å gjøre), må du kompilere dem på nytt.

Kommentarer

• lsof +c0 -f -- /usr/lib64/libc-*.so | grep "(deleted)$" litt mer presis, viser deg fullstendige navn på prosesser og ser etter kobling til filer som ble slettet.

Hvis du har en konto i Redhat, kan du få tilgang til «GHOST-detektoren» deres på denne nettadressen . Det er et lite skallskript som vil fortelle deg om glibc er sårbar.

Red Hat har nå kommet tilbake og uttalt at detektorskriptet deres er feil. Legg merke til at det også er bekymring for RHEL6.6 når du bruker yum –security for å lappe sårbarheten slik den har blitt savnet i henhold til https://bugzilla.redhat.com/show_bug.cgi?id=1186717 .

Kommentarer

• RedHat-verktøyet sjekker bare versjonen av glibc RPM , og det bare vet om RedHat-versjoner (og sannsynligvis derivater). Det fungerer faktisk ikke på noe annet operativsystem.
• Dette er heller ikke lenger tilgjengelig for nedlasting, sannsynligvis til feilene.