Wie funktioniert die Sicherheitslücke?
Im blog trendmicro wurde das Problem folgendermaßen beschrieben: Die Lücke (CVE-2015-7547) kann angesprochen werden, wenn eine Anwendung, die Glibc nutzt, eine DNS-Anfrage stellt. Der Glibc DNS Client Resolver ist auf Stack-basierten Buffer Overflow anfällig, wenn die Funktion getaddrinfo() verwendet wird. Eine nicht korrekt formatierte Antwort auf diese Funktion verursacht einen Overflow.
Es gibt mehrere Möglichkeiten dafür, dass das Zielsystem eine bösartige Antwort erhält:
- Das Zielsystem könnte eine DNS-Anfrage für eine Domäne stellen, die von den Angreifern kontrolliert wird;
- Das Zielsystem könnte einen bösartigen DNS-Server kontaktieren;
- Die DNS-Antwort könnte unterwegs über einen Man-in-the-Middle-Angriff geändert worden sein.
Lesen Sie dazu auch unseren Beitrag auf trojaner-info.de
Jede Linux-Maschine gefährdet
Jede, mit dem Internet verbundene Linux-Maschine ist theoretisch gefährdet. Ein Angreifer könnte die Sicherheitslücke ausnutzen, um bösartigen Code auf einem Linux-System auszuführen. Doch wie verlautet gibt es bislang keinen bekannten Exploit-Code, der dies tut.
Die Sicherheitslücke stellt ein großes Problem dar, das unbedingt gelöst werden muss, ist aber nach Meinung der Experten nicht so dramatisch wie andere Linux-Fehler wie Heartbleed oder Shellshock. Eine einfache Ausnutzung ist nicht so ohne weiteres möglich.
Problem-Lösungen
Da große Linux-Distributionen bereits gepatcht worden sind, sollten Systemadministratoren prüfen, ob es einen Patch für die eingesetzte Distribution gibt.
Empfohlen wird, ausgehenden DNS-Verkehr nur zu erlauben, wenn er an DNS-Server auf der Whitelist geht. Die DNS-Software BIND ist nicht betroffen.
Trend Micro hat folgende Deep Security-Rules herausgegeben:
- 1007456 – DNS Malformed Response
- 1007458 – Glibc getaddrinfo Stack Based Buffer Overflow Vulnerability (CVE-2015-7547)
- 1007457 – Allowed DNS Resolvers
Zwei der Regeln blocken potenziell bösartigen DNS-Verkehr, eine davon ist speziell auf die Sicherheitslücke zugeschnitten und die andere erkennt große DNS-Antworten. Die dritte Regel kann für die Implementierung einer Whitelist für DNS-Server genutzt werden.
