Dipl.-Inform. Carsten Eilers

Erst mal ist die GHOST-Schwachstelle eine ganz normale
Pufferüberlauf-Schwachstelle in der Funktion
__nss_hostname_digits_dots() der Standard-C-Bibliothek GNU
C Library (glibc)
(CVE-2015-0235).
Da sie über die gethostbyname*()-Funktionen aus der Ferne
ausgenutzt werden kann, wurde sie von ihren Entdeckern von Qualys GHOST
genannt.

Eine
gute Beschreibung
der Schwachstelle hat Paul Ducklin auf Sophos Naked Security
veröffentlicht.

Eine Besonderheit der Schwachstelle ist ihr Alter: Die erste betroffene
glibc-Version ist glibc-2.2 vom 10. November 2000. Der Fehler wurde zwar am
21. Mai 2013 zwischen der Veröffentlichung der Versionen glibc-2.17 und
glibc-2.18
behoben,
aber nur als normaler Fehler und nicht als Schwachstelle.

Womit wir zur zweiten Besonderheit kommen: Den betroffenen
Linux-Distributionen. Aktuelle Distributionen, die eine aktuelle
glibc-Version (ab 2.18) enthalten, sind nicht betroffen. Da der Patch aber
nicht als sicherheitsrelevant eingestuft wurde, gelangte er nicht in die
Long-Term-Support-Versionen der Linux-Distributionen, so dass zum Beispiel
Debian 7 (Wheezy), Red Hat Enterprise Linux 6 und 7, CentOS 6 und 7 und
Ubuntu 12.04 LTS von der Schwachstelle betroffen sind. Für diese
Distributionen stehen inzwischen Updates zur Verfügung, die die
Schwachstelle beheben.

Eine
Liste
betroffener und nicht betroffener Linux-Distributionen wurde von Matasano
veröffentlicht.

Wie gefährlich ist die Schwachstelle?

Prinzipiell erlaubt die Schwachstelle das Ausführen beliebigen Codes.
Es gibt aber einige Einschränkungen, die ihre Gefährlichkeit
ziemlich reduzieren.

Die gethostbyname*()-Funktionen wandeln Hostnamen in
IP-Adressen um. Wird eine IP-Adresse übergeben, ist das natürlich
überflüssig. Der Fehler befindet sich im Code, der prüft, ob die Eingabe
eine IP-Adresse ist. Laut
Security Advisory
von Qualys muss ein Parameter etliche Bedingungen erfüllen, um den
für den Pufferüberlauf anfälligen Code zu erreichen. Bei
vielen getesteten Programmen müssen die Parameter aber genau
gegenteilige Bedingungen erfüllen, um überhaupt an die
gethostbyname*()-Funktionen übergeben zu werden. Ein
möglicherweise eingeschleuster Exploit erreicht die anfällige
Funktion in diesen Fällen also gar nicht. Außerdem ist
gethostbyname()
obsolet,
aktuelle Programmversionen nutzen oft den IPv6-fähigen Nachfolger
getaddrinfo() und sind generell nicht betroffen.

Nicht betroffen sind
laut Qualys
die folgenden Programme:

“apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql,
nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd, pure-ftpd,
rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers, vsftpd,
xinetd.”

Ebenfalls nicht betroffen sind
Squid und zugehörige Tools
sowie
HAProxy.

Johannes B. Ullrich hat im ISC Diary
beschrieben,
wie mittels ldd und lsof überprüft werden kann,
welche Programme welche Libraries verwenden.

Es gibt einen (1!) PoC

Betroffen ist der Exim-Mailserver, sofern er so konfiguriert wurde, dass er
zusätzliche Prüfungen für die Befehle HELO und EHLO durchführt. Qualys hat
einen Proof-of-Concept entwickelt, bei dem eine an den Server gesendete
E-Mail die Schwachstelle ausnutzt, um einen Shellzugang zu öffnen.
Das ist aber auch der einzige PoC, der existiert.

Außer Exim sind noch clockdiff, procmail und pppd nachweislich
betroffen,
außerdem sind möglicherweise PHP-Anwendungen wie zum Beispiel WordPress
betroffen.
Für das Metasploit-Framework gibt es ein
wordpress ghost scanner module
zum Testen von WordPress-Installationen. Was es nicht gibt, sind PoCs oder
gar echte Exploits für diese Programme.

Und nun?

Die Lösung des Problems ist ganz einfach: Es müssen nur die
inzwischen bereit stehenden Patches/Updates installiert werde. Danach ist
ein Neustart des Systems zwingend notwendig, da ansonsten die bereits
laufenden Prozesse weiterhin die alte, angreifbare glibc-Version verwenden.
Das war es dann aber auch schon – Problem erkannt, Problem gebannt.

Kleine Marketing-Panne, sowas kann ja mal passieren…

Ein etwas pikantes Detail am Rande: Die Schwachstelle wurde zu früh
veröffentlicht. Zwar nur einige Stunden, aber immerhin. Qualys hatte eine
PR-Agentur mit der Veröffentlichung der Schwachstelle beauftragt, und die
hat eine
französische
Meldung
(Englische Übersetzung
via Google Translate)
zu früh veröffentlicht.
Allerdings nur
um einige Stunden
vor dem vereinbarten koordinierten Veröffentlichungstermin. Wofür sich Qualys
entschuldigt hat.

Der Vorfall hat einige Kritik nach sich gezogen, wobei die zu frühe
Veröffentlichung nur ein Kritikpunkt ist. Bedenklich ist auch, dass die
PR-Agentur einige Zeit vor Veröffentlichung der Patches über die
Schwachstelle informiert war. Normalerweise kennen bei vertraulich
gemeldeten Schwachstellen nur die Entdecker und Entwickler die
Schwachstelle (sofern sie nicht von Dritten unabhängig von den Entdeckern
ebenfalls entdeckt wird). Sollte das Einschalten von PR-Agenturen üblich
werden, werden die damit zu einem interessanten Angriffsziel für
Cyberkriminelle. Vom der ebenfalls möglichen unbefugten Weitergabe durch
Mitarbeiter der PR-Agentur ganz zu schweigen.

Außerdem erfolgt die Kommunikation zwischen den Entdeckern der Schwachstellen
und den Entwicklern im Allgemeinen verschlüsselt, was man bei der
Kommunikation mit PR-Agenturen wohl eher ausschließen kann.

Die Sache mit dem Logo…

Das Logo der Schwachstelle hat einigen Spott auf sich gezogen. Zum
Beispiel, weil der gezeigte Shell-Prompt doch eher dem von MS-DOS als dem
einer Unix-Shell ähnelt. Oder weil das verwendete JPEG-Format, dass
die Qualität des Logos im Vergleich zu einem besser geeigneten Format
wie PNG verschlechtert. Michal Zalewski hat eine
“Technical analysis of Qualys’ GHOST”
veröffentlicht. Die aber nicht die Schwachstelle, sondern das Logo
behandelt.

Ein Punkt ist dabei interessant: Der Webserver von Qualys liefert für
das Logo einen Last-Modified-Header mit dem Wert "Thu, 02 Oct 2014
02:36:26 GMT", also lange bevor die Schwachstelle
veröffentlicht wurde. Und zwar ungefähr 90 Tage früher –
die Zeit, die üblicherweise für das Vorbereiten und Testen von
Patches benötigt und zugestanden wird. Was laut Qualys aber ein
reiner Zufall ist, das Datum der Logo-Datei hat mit der Schwachstelle
nichts zu tun. Und der Name “GHOST” wurde erst am 23. Januar
geprägt.
Er war zum Beispiel noch nicht in dem am 18. Januar an die
Linux-Distributionen gesendeten Advisory-Entwurf enthalten. Eine
Erklärung für das vermutliche Alter des Logos steht noch aus.
Und rein zufällig ist die betreffende Logo-Datei vom Webserver
verschwunden.

Ein Schelm, der böses dabei denkt? Aber man sollte ja nicht mit
Böswilligkeit erklären, was sich auch mit Dämlichkeit
erklären lässt. Vermutlich hat da nur ein Praktikant den
Webserver aufgeräumt und gedacht, so ein merkwürdiges Logo
braucht ja keiner, also weg damit.

Aber das ist eigentlich auch egal. Patches/Updates installieren, Rechner
neu starten, und die Sache ist erledigt.

Carsten Eilers