GHOST-bug: is er een eenvoudige manier om te testen of mijn systeem veilig is?

Het lijkt erop dat u een tool kunt downloaden van de Universiteit van Chicago waarmee u uw systeem kunt testen op de kwetsbaarheid .

Dit repareert of herstart niets het zal je alleen vertellen of je systeem kwetsbaar is.

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

Als ik dit op een van mijn externe servers draai, krijg ik:

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 

De de broncode van dat script ziet eruit als dit volgende codeblok , maar je moet sowieso eerst de oorsprongcode inspecteren . Zoals anderen al hebben opgemerkt, als je willekeurig code van internet laat draaien zonder te weten wat het doet, kunnen er slechte dingen gebeuren :

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

Bewerken : ik “heb een ansible playbook hier toegevoegd als het voor iemand nuttig is, als je een groot aantal hebt van te testen systemen, dan kunt u dit snel doen.

Eveneens, zoals hieronder uiteengezet, als u vindt dat uw servers kwetsbaar zijn en beschikbare patches toepast, wordt ten zeerste aanbevolen uw systeem opnieuw op te starten .

Reacties

• @KasperSouren Nou ja. Als het kwetsbaar is, pas dan de patch / upgrade toe en start opnieuw op.
• @KasperSouren Wat je ‘ vraagt, is eerlijk gezegd een beetje dom. Dit antwoord beantwoordt perfect uw vraag: hoe detecteer ik deze kwetsbaarheid. Dat ‘ is alles wat je hebt gevraagd. Vragen om een ” one liner ” is ook een beetje dom. Ik heb de test die hij hier op al mijn servers plaatste in minder dan 2 minuten uitgevoerd. Het ‘ is doodeenvoudig. Gewoon ” afsluiten -r nu ” nadat u ‘ opnieuw klaar bent ….. ..
• Ik heb een upgrade uitgevoerd, de test uitgevoerd, ‘ niet opnieuw opgestart. Ik kwam hier pas op terug toen ik erachter kwam dat ik opnieuw moest opstarten. Dit kan nogal wat mensen overkomen en hun servers kunnen kwetsbaar zijn en kunnen worden gehackt ondanks hun valse gevoel van veiligheid. Dus niet zo gek om dit zo mogelijk recht te zetten IMHO.
• De GHOST.c POC is afkomstig van de originele Qualys advisory .
• @KasperSouren een test kan je vertellen dat nieuwe programmas een veilige versie van glibc zullen gebruiken. Het kan echter zijn dat er op de achtergrond programmas draaien die zijn gestart vóór de upgrade en daarom de oude versie hebben geladen.

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

Als die je segfaults geven (ja, een Python-segfault, een zeldzaam exemplaar), dan ben je kwetsbaar. Ik weet niet of je Python als een “ontwikkelaarstool” beschouwt, maar PHP is een veelgebruikt programma.

Als het doelapparaat een router is, weet ik niets dat u erop zou kunnen doen om u iets te vertellen, behalve door de specificaties van de fabrikant te graven en / of te wachten op fabrikantadviezen en firmware-updates.

Reacties

• Is het mogelijk om dit te combineren met sudo lsof | grep libc- | grep DEL"? Verstrekt in een andere opmerking, om dat te voorkomen mensen denken dat ze ‘ veilig zijn terwijl de oude libc nog in gebruik is. Met deze toevoeging geef ik ‘ de premie meteen uit.
• Het ‘ is een shell-commando, dus je kunt dingen aanpakken met & & En dat commando is alleen beschikbaar nadat je je glibc-pakketten hebt bijgewerkt.Als u ‘ hebt bijgewerkt, zullen deze one-liners niet werken. Dus stop je update vommamd tussendoor?
• Ik gebruikte de php-versie op SUSE 11SP3, en ik zag geen segfault voor of na het patchen. Enige ideeën?
• @marcin Dat ‘ is interessant. Ik heb deze uit internetbronnen gehaald en veel mensen melden segfaulting. Doet het verhogen van het aantal lussen iets? (Voor wat het ‘ waard is, zal de segfault voor Python ook segfault op sommige gepatchte systemen … geen woord over waarom dat ‘ gebeurt.)
• Door met de uchicago-code te spelen, lijkt het erop dat als je probeert te overlopen met meer dan 4 bytes of zo, gethostbyname () een fout (EINVAL) zal retourneren in plaats van overlopen. Met C kunt u precies bepalen wat er wordt overschreven. Met PHP of Python kan wat wordt overschreven belangrijk en segfault zijn, of misschien niets; het ‘ zal afhankelijk zijn van de exacte build van het systeem. En de Python-segfault op gethostbyname("0"*50000000) lijkt voor mij meer op een bug in Python. (Ghost Python?)

het antwoord van aaronfay is al behandeld om te bepalen of je onderliggende systeem kwetsbaar is, maar het detecteert niet of er programmas zijn die na de upgrade nog steeds de oude versie van glibc gebruiken. Dat wil zeggen, u zou kunnen upgraden zonder de betrokken processen opnieuw op te starten, en het script zou “niet kwetsbaar” rapporteren, ook al is de oude, kwetsbare bibliotheek nog steeds in gebruik.

Hier is een manier om te controleren of die er zijn dynamisch gekoppelde programmas die nog steeds de oude versie van glibc gebruiken:

sudo lsof | grep libc- | grep DEL 

Als er resultaten zijn, zijn verwijderde versies van glibc in gebruik en kunnen de processen die ze gebruiken zijn kwetsbaar.

Dit dekt natuurlijk niet het geval waarin glibc statisch was gekoppeld. Het goede (?) nieuws is dat het zeer zeldzaam is om glibc statisch gekoppeld te vinden in een binair bestand, beide omdat van de grootte, en omdat het een aantal andere ergernissen en moeilijkheden oplevert. In het geval dat je wel programmas hebt die een statisch gecompileerde glibc gebruiken (wat je vrijwel zeker niet doet), zou je ze opnieuw moeten compileren.

Reacties

• lsof +c0 -f -- /usr/lib64/libc-*.so | grep "(deleted)$" een beetje nauwkeuriger, toont je volledige namen van processen en zoekt naar links naar bestanden die verwijderd zijn.

Als je een account hebt in Redhat, kun je hun “GHOST-detector” openen op deze URL . Het is een klein shell-script dat u vertelt of uw glibc kwetsbaar is.

Red Hat is nu teruggekomen en verklaarden dat hun detectiescript gebrekkig is. Merk op dat er ook bezorgdheid bestaat over RHEL6.6 wanneer yum –security wordt gebruikt om de kwetsbaarheid te patchen, aangezien deze is gemist volgens https://bugzilla.redhat.com/show_bug.cgi?id=1186717 .

Reacties

• De RedHat-tool controleert alleen de versie van de glibc RPM , en het alleen weet over RedHat-versies (en waarschijnlijk afgeleiden). Het werkt eigenlijk niet op een ander besturingssysteem.
• Dit is ook niet langer beschikbaar om te downloaden, waarschijnlijk vanwege de gebreken.