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