GHOST-Fehler: Gibt es eine einfache Möglichkeit zu testen, ob mein System sicher ist?

Anscheinend können Sie ein Tool von der University of Chicago herunterladen, mit dem Sie Ihr System auf die Sicherheitsanfälligkeit testen können

Hiermit wird nichts repariert oder neu gestartet. Es wird Ihnen nur mitgeteilt, ob Ihr System anfällig ist.

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

Wenn ich dies auf einem meiner Remote-Server ausführe, erhalte ich:

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 

Die Der Quellcode dieses Skripts sieht wie folgt aus: , aber Sie sollten den Ursprungscode trotzdem zuerst überprüfen . Wie andere bereits betont haben, können schlimme Dinge passieren, wenn Sie willkürlich Code aus dem Internet ausführen, ohne zu wissen, was er tut. :

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

Bearbeiten : Ich habe hier ein ansible Playbook hinzugefügt, wenn es für jemanden von Nutzen ist, wenn Sie eine große Anzahl haben von Systemen zu testen, dann ansible ermöglicht es Ihnen, es schnell zu tun.

Wenn Sie feststellen, dass Ihre Server anfällig sind und verfügbare Patches anwenden, wird dringend empfohlen, Ihr System .

Kommentare

• @KasperSouren Nun ja. Wenn es anfällig ist, wenden Sie den Patch / das Upgrade an und starten Sie ihn neu.
• @KasperSouren Was Sie ‚ fragen, ist ehrlich gesagt ein wenig albern. Diese Antwort beantwortet Ihre Frage perfekt: Wie erkenne ich diese Sicherheitsanfälligkeit? Das ‚ ist alles, was Sie gefragt haben. Nach einem “ Einzeiler “ zu fragen, ist auch ein wenig albern. Ich habe den Test, den er hier gepostet hat, in weniger als 2 Minuten auf allen meinen Servern ausgeführt. ‚ ist denkbar einfach. Nur “ Herunterfahren -r jetzt “ nachdem Sie ‚ fertig sind ….. ..
• Ich habe ein Upgrade durchgeführt, den Test ausgeführt und ‚ nicht neu gestartet. Ich bin erst darauf zurückgekommen, als ich herausfand, dass ich neu starten musste. Dies kann einigen Personen passieren und ihre Server sind möglicherweise anfällig und werden trotz ihres falschen Sicherheitsgefühls gehackt. Also nicht so dumm, wenn möglich IMHO klar zu machen.
• Der GHOST.c POC stammt von den ursprünglichen Qualys Hinweis .
• @KasperSouren Ein Test kann Ihnen sagen, dass neue Programme eine sichere Version von glibc verwenden. Möglicherweise werden jedoch Programme im Hintergrund ausgeführt, die vor dem Upgrade gestartet wurden, und haben daher die alte Version geladen.

PHP-Einzeiler:

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

Python-Einzeiler:

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

Wenn diese Ihnen Segfaults geben (ja, ein Python-Segfault, ein seltenes Exemplar), sind Sie „verwundbar“. Ich weiß nicht, ob Sie Python als „Entwicklertool“ betrachten, aber PHP ist ein gängiges Programm.

Wenn das Zielgerät ein Router ist, weiß ich nichts, was Sie darauf tun könnten, außer in den Herstellerspezifikationen zu stöbern und / oder auf Herstellerhinweise und Firmware-Updates zu warten.

Kommentare

• Ist es möglich, dies mit sudo lsof | grep libc- | grep DEL" zu kombinieren? Wird in einem anderen Kommentar angegeben, um dies zu vermeiden Leute denken, dass sie ‚ sicher sind, während die alte Bibliothek noch verwendet wird. Mit diesem Zusatz werde ich ‚ das Kopfgeld sofort ausgeben.
• Es ist ‚ ein Shell-Befehl, sodass Sie mit & . Und dieser Befehl wird erst ausgeführt, nachdem Sie Ihre glibc-Pakete aktualisiert haben.Wenn Sie ‚ aktualisiert haben, schlagen diese Einzeiler fehl. Also stopfe dein Update vommamd dazwischen?
• Ich habe das PHP unter SUSE 11SP3 verwendet und vor oder nach dem Patchen keinen Segfault gesehen. Irgendwelche Ideen?
• @marcin Das ‚ ist interessant. Ich habe diese aus Internetquellen bezogen, und viele Leute berichten von Segfaulting. Hat das Erhöhen der Schleifenzahl etwas zu tun? (Für das, was es ‚ wert ist, wird der Segfault für Python auch auf einigen gepatchten Systemen segfault … kein Wort darüber, warum das ‚ s passiert.)
• Wenn Sie versuchen, mit dem Uchicago-Code zu spielen, wird gethostbyname () einen Fehler (EINVAL) zurückgeben, anstatt zu überlaufen. Mit C können Sie genau steuern, was überschrieben wird. Mit PHP oder Python kann das, was überschrieben wird, wichtig und fehlerhaft sein, oder es kann nichts sein. ‚ hängt vom genauen Aufbau des Systems ab. Und der Python-Segfault auf gethostbyname("0"*50000000) sieht für mich eher wie ein Fehler in Python aus. (Ghost Python?)

Die Antwort von aaronfay deckte bereits ab, ob Ihr zugrunde liegendes System anfällig ist. Es wird jedoch nicht erkannt, ob Programme vorhanden sind, die nach dem Upgrade noch mit der alten Version von glibc ausgeführt werden. Das heißt, Sie können ein Upgrade durchführen, ohne die betroffenen Prozesse neu zu starten, und das Skript meldet „nicht anfällig“, obwohl die alte, anfällige Bibliothek noch verwendet wird.

Hier ist eine Möglichkeit, um zu überprüfen, ob es welche gibt Dynamisch verknüpfte Programme, die weiterhin die alte Version von glibc verwenden:

sudo lsof | grep libc- | grep DEL 

Wenn Ergebnisse vorliegen, werden gelöschte Versionen von glibc verwendet, und die Prozesse, die sie verwenden, können verwendet werden anfällig.

Dies deckt natürlich nicht den Fall ab, in dem glibc statisch verknüpft war. Die gute (?) Nachricht ist, dass es sehr selten vorkommt, dass glibc statisch in einer Binärdatei verknüpft ist, beides, weil von der Größe, und weil es einige andere Belästigungen und Schwierigkeiten darstellt. Für den Fall, dass Sie Programme haben, die einen statisch kompilierten glibc verwenden (was Sie mit ziemlicher Sicherheit nicht tun), müssten Sie diese neu kompilieren.

Kommentare

• lsof +c0 -f -- /usr/lib64/libc-*.so | grep "(deleted)$" etwas genauer, zeigt Ihnen die vollständigen Namen der Prozesse an und sucht nach Links zu gelöschten Dateien.

Wenn Sie ein Konto in Redhat haben, können Sie unter diese URL . Es ist ein kleines Shell-Skript, das Ihnen sagt, ob Ihre glibc anfällig ist.

Red Hat ist jetzt zurückgekehrt und stellte fest, dass das Detektorskript fehlerhaft ist. Beachten Sie, dass RHEL6.6 auch bei der Verwendung von yum –security zum Patchen der Sicherheitsanfälligkeit Bedenken hat, da diese gemäß https://bugzilla.redhat.com/show_bug.cgi?id=1186717 .

Kommentare

• Das RedHat-Tool überprüft nur die Version des glibc-RPM und es nur kennt RedHat-Versionen (und wahrscheinlich Derivate). Es funktioniert unter keinem anderen Betriebssystem.
• Dies steht auch nicht mehr zum Download zur Verfügung, wahrscheinlich aufgrund der Fehler.