Kritische Sicherheitsschwachstelle: glibc Stack Buffer Overflow in getaddrinfo() (CVE-2015-7547)

Das glibc-Paket enthält Standardbibliotheken, die von mehreren Programmen im System verwendet werden. Um Festplattenplatz und Arbeitsspeicher zu sparen sowie um Upgrades zu erleichtern, wird gemeinsamer Systemcode an einem Speicherort verwahrt und von den Programmen gemeinsam genutzt. Dieses Paket enthält die Standard C Bibliothek mit der alle GNU/Linux Programme verbunden sind. Die mit glibc gelieferte libresolv-Bibliothek bietet Funktionen, die zwischen Hostnamen und IP-Adressen übersetzen. nss_dns ist die glibc-Komponente, die das Modul für den Name Service Switch (NSS) Dienst liefert, der libresolv zur Durchführung von DNS-Lookups verwendet.

Hintergrund

Ein Stack Buffer Overflow wurde bei libresolv in dem Code entdeckt, der duale A/AAAA DNS-Anfrage durchführt. Ein Remote-Angreifer könnte speziell angefertigte DNS-Antworten erstellen, die zum Absturz von libresolv führen könnten oder möglicherweise Code mit den Berechtigungen des Benutzers ausführen, der die Bibliothek ausführt. Der Buffer Overflow tritt bei der Funktion send_dg (für UDP-Anfragen) and send_vc (für TCP-Anfragen) in libresolv auf. Das Problem wird nur beobachtet, wenn libresolv vom nss_dns NSS Dienst-Modul aufgerufen wird. Diese Sicherheitsschwachstelle wurde zugewiesen CVE-2015-7547.

Applikationen, die getaddrinfo mit der AF_UNSPEC Familie von Adressen aufrufen, sind betroffen, ausgenommen bei Red Hat Enterprise Linux 6.4, bei dem Applikationen auch betroffen sind, wenn Sie die AF_INET6 Familie von Adressen aufrufen. Applikationen, die nur die alten gethostbyname-Funktionen oder libresolv-Funktionen wie res_search (und nicht getaddrinfo) verwenden, sind nicht betroffen.

Dieses Problem betrifft nicht die openssl-Versionen, die in Red Hat Enterprise Linux 5 und Red Hat Enterprise Linux 6.4 und früheren Releases enthalten sind. Dieses Problem betrifft jedoch Red Hat Enterprise Linux 6.5, Red Hat Enterprise Virtualization Hypervisor 6.5 und Red Hat Storage 2.1, die openssl 1.0.1e enthalten.

Auswirkungen

Diese Sicherheitslücke wurde von Red Hat Product Security als Kritisch eingestuft.

Vorbeugung

In einer standardmäßigen libresolv-Konfiguration wird der UDP-basierte Vektor durch die Verwendung eines zuverlässigen, protokollkonformen DNS-Resolvers in einem zuverlässigen Netzwerk abgeschwächt. Ein konformer Resolver wird keine übergroßen Antworten erstellen, wie sie notwendig sind, um diese Schwachstelle auszunutzen, denn der glibc-Resolver aktiviert EDNS0 nicht standardmäßig und stellt keine Anfragen mit großen Antworten.

Der TCP-basierte Vektor könnte durch einen zuverlässigen, rekursiven Resolver in einem zuverlässigen Netzwerk entschärft werden, das die Größe einzelner DNS-Antworten auf 1023 Bytes oder weniger beschränkt. Diese Fähigkeit ist jedoch bei Implementierungen von DNS-Resolvers nicht üblich, da dies ein Verstoß gegen das DNS-Protokoll ist. (Die von den meisten Resolvern angebotene Konfigurationsoption für Zwischenspeicher gilt für UDP, nicht TCP.) Das Zurückweisen von AAAA-Antworten ohne die Größe von A-Antworten zu beschränken, behebt die Schwachstelle nicht.

Das Deaktivieren des IPv6-Support bei betroffenen Systemen entschärft die Schwachstelle nicht, da die dualen A/AAAA-Lookups selbst bei fehlendem IPv6-Support des Systems durchgeführt werden.

Betroffene Produkte und Lösung

Alle Versionen des »glibc«-Pakets, die in Red Hat Enterprise Linux 6 und 7 enthalten sind, sind von diesen Schwachstellen betroffen. In der folgenden Tabelle finden Sie Links für die jeweiligen Sicherheits-Advisorys, die dieses Problem beheben:

Auflösung

Nach Anwenden des Update müssen Sie das System erneut booten oder alle betroffenen Dienste neu starten:

Da diese Schwachstelle zahlreiche Applikationen im System betrifft, ist es am sichersten das System neu zu starten, denn nur dann ist gewährleistet, dass auch tatsächlich jede Applikation die aktualisierten glibc-Pakete verwendet.

Falls Sie nach der Aktualisierung nicht das gesamte System neu starten können, führen Sie den folgenden Befehl aus, um alle laufenden Prozesse aufzulisten (nicht auf Dienste beschränkt), die noch die alte [in-memory] Version von glibc in Ihrem System verwenden.

lsof +c0 -d DEL | awk 'NR==1 || /libc-/ {print $2,$1,$4,$NF}' | column -t

Identifizieren Sie in der Ergebnisliste die öffentlich zugänglichen Dienste und starten Sie diese neu. Dieser Prozess dient zwar der temporären Problemumgehung, wird von Red Hat jedoch nicht unterstützt. Sollte ein Problem auftreten, so werden Sie zum Reboot des Systems aufgefordert, ehe mit einer Problembehebung begonnen wird.

FAQ (häufig gestellte Fragen)

1. Blockiert SELinux diese Sicherheitsschwachstelle?
Eine passende SELinux Richtlinie kann einige der Schäden eines möglichen Angriffs in Grenzen halten und deren Zugriff auf das System beschränken, aber DNS wird von vielen Applikationen und Systemkomponenten verwendet, daher bieten SELinux nur einen eingeschränkten Schutz vor diesem Problem.

2. Kann ein zuverlässiger DNS-Resolver vor dem Problem schützen?
Ein zuverlässiger Resolver kann in einer standardmäßigen, protokollkonformen Konfiguration das Problem nicht abschwächen, da mögliche Sicherheitslücke syntaktisch wohlgeformte DNS-Antworten einbeziehen können.

3. Sind statisch verbundene Binärdateien von dieser Schwachstelle betroffen?
Red Hat unterstützt kein statisches Verbinden von glibc. Falls Kunden jedoch statisch verbundene Applikationen mittels »glibc-static«-Paket erstellt haben, so verwenden diese Applikationen nach wie vor Systemkopien von nss_dns und libresolv, so dass das Installieren aktualisierter glibc-Pakete die Schwachstelle behebt.

Danksagung

Die Schwachstelle wurde vom Google Security Team und Red Hat gefunden.