GHOST-fejl: er der en enkel måde at teste, om mit system er sikkert?

Det ser ud til, at du kan downloade et værktøj fra University of Chicago , der giver dig mulighed for at teste dit system for sårbarheden .

Dette reparerer eller genstarter ikke noget , det fortæller dig kun, om dit system 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 ] 

At køre dette på en af 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 

kildekoden til dette script ser ud som denne næste kodeblok , men du skal alligevel først undersøge oprindelseskoden . Som andre har påpeget, hvis du vilkårligt kører kode fra internettet uden at vide, hvad det gør, kan der ske dårlige ting :

/* * 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 tilføjet en anselig playbog her , hvis den er til brug for nogen, hvis du har et stort antal af systemer til at teste så ansible giver dig mulighed for at gøre det hurtigt.

Som beskrevet i diskussionen nedenfor, hvis du finder ud af, at dine servere er sårbare og anvender tilgængelige programrettelser, anbefales det , at du genstarter dit system .

Kommentarer

• @KasperSouren Nå ja. Hvis det er sårbart, skal du anvende patch / opgradering og genstarte.
• @KasperSouren Hvad du ‘ beder om, er ærligt talt lidt fjollet. Dette svar svarer perfekt på dit spørgsmål: hvordan opdager jeg denne sårbarhed. Det ‘ er alt hvad du spurgte. At bede om en ” en liner ” er også lidt fjollet. Jeg kørte den test, han postede her på alle mine servere på under 2 minutter. Det ‘ er dødt simpelt. Bare ” nedlukning -r nu ” efter du ‘ er færdig ….. ..
• Jeg opgraderede, kørte testen, startede ikke ‘. Kom først tilbage til dette, da jeg fandt ud af, at jeg var nødt til at genstarte. Dette kan ske for en hel del mennesker, og deres servere kan være sårbare og måske blive hacket på trods af deres falske følelse af sikkerhed. Så ikke så dumt at få dette lige hvis det er muligt IMHO.
• GHOST.c POC stammer fra den originale Qualys rådgivende .
• @KasperSouren en test kan fortælle dig, at nye programmer bruger en sikker version af glibc. Du kan dog have programmer, der kører i baggrunden, der startede før opgraderingen, og derfor har du indlæst den gamle version.

aaronfay “s svar allerede dækket for at bestemme, om dit underliggende system er sårbart, men det registrerer ikke, om der er programmer, der stadig kører ved hjælp af den gamle version af glibc efter opgradering. Det vil sige, du kan opgradere uden at genstarte de berørte processer, og scriptet rapporterer “ikke sårbart”, selvom det gamle, sårbare bibliotek stadig er i brug.

Her er en måde at kontrollere, om der er nogen dynamisk linkede programmer, der stadig bruger den gamle version af glibc:

sudo lsof | grep libc- | grep DEL 

Hvis der er resultater, er slettede versioner af glibc i brug, og de processer, der bruger dem, kan være sårbar.

Dette dækker selvfølgelig ikke den sag, hvor glibc var statisk knyttet. Den gode (?) nyhed er, at det er meget sjældent at finde glibc statisk knyttet i en binær, begge fordi af størrelsen, og fordi det giver nogle andre irritationer og vanskeligheder. I tilfælde af at du har har programmer, der bruger en statisk kompileret glibc (som du næsten helt sikkert ikke ikke har), skal du kompilere dem igen.

Kommentarer

• lsof +c0 -f -- /usr/lib64/libc-*.so | grep "(deleted)$" lidt mere præcist, viser dig fulde navne på processer og ser efter at linke til filer, der blev slettet.

Hvis du har en konto i Redhat, kan du få adgang til deres “GHOST-detektor” på denne URL . Det er et lille shell-script, der fortæller dig, om din glibc er sårbar.

Red Hat er nu kommet tilbage og sagde, at deres detektorscript er mangelfuldt. Bemærk, at der også er bekymring for RHEL6.6, når man bruger yum –security til at patchere sårbarheden, da den er gået glip af i henhold til https://bugzilla.redhat.com/show_bug.cgi?id=1186717 .

Kommentarer

• RedHat-værktøjet kontrollerer kun versionen af glibc RPM , og det kun kender til RedHat-versioner (og sandsynligvis derivater). Det fungerer faktisk ikke på noget andet operativsystem.
• Dette er heller ikke længere tilgængeligt til download, sandsynligvis til manglerne.