it-swarm.com.de

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

GHOST ( CVE-2015-0235 ) ist gerade aufgetaucht. Wie kann ich schnell überprüfen, ob ein System von mir sicher ist? Idealerweise mit einem einzeiligen Shell-Befehl.

Laut ZDNet-Artikel "sollten Sie dann das System neu starten". Im Idealfall würde der Test auch dies anzeigen ...

61
kqw

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

Hierdurch wird nichts repariert oder neu gestartet . Es wird nur angezeigt, 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, bekomme ich:

[email protected]:~# 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]

[email protected]:~# gcc GHOST.c -o GHOST
[email protected]:~# ./GHOST
vulnerable

Der Quellcode dieses Skripts sieht wie dieser nächste Codeblock aus , aber Sie sollten den Origin-Code 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 bewirkt:

/*
 * 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 ein Ansible-Playbook hinzugefügt hier Wenn es für jemanden von Nutzen ist, wenn Sie eine große Anzahl von Systemen zum Testen haben, können Sie es mit Ansible tun es schnell.

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

71
aaronfay

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, a Python Segfault, ein seltenes Exemplar), sind Sie verwundbar. Ich weiß nicht, ob Sie Python a "Entwicklertool" 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.

15
Ohnana

in der Antwort von aaronfay wurde bereits festgestellt, 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 noch dynamisch verknüpfte Programme vorhanden sind, die 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, sind möglicherweise anfällig.

Dies gilt natürlich nicht für den Fall, dass glibc statisch verknüpft war. Die gute (?) Nachricht ist, dass es sehr selten vorkommt, dass glibc statisch in einer Binärdatei verknüpft ist, sowohl aufgrund der Größe als auch aufgrund einiger anderer Belästigungen und Schwierigkeiten. Für den Fall, dass Sie do Programme haben, die einen statisch kompilierten glibc verwenden (was Sie mit ziemlicher Sicherheit nicht tun), müssten Sie diese neu kompilieren.

9
Chris Down