Neue Schwachstelle in OpenSSH gefunden (24.8.2018)

In OpenSSH wurde eine neue Schwachstelle gefunden, die Oracle-Angriffe auf die Authentifizierung durch Erraten bestehender Benutzernamen ermöglicht. Die Schwachstelle besteht seit 2011.


Anzeige

Vor einer Woche hatte ich über eine Schwachstelle in OpenSSH berichtet (siehe Alle OpenSSH-Versionen der letzten 20 Jahre unsicher …), die inzwischen gefixt ist. Dort ließen sich, wegen eines Fehlers bei der Authentifizierung, bestehende Benutzernamen an Hand von Namenslisten herausfinden. Sicherheitsforscher von Qualys entdeckten das Problem während sie einen Commit im OpenBSD-Quellcode der Suite analysierten.

Der neue Fehler wurde durch Qualys auf die gleiche Weise, bei der Analyse eines Commits im OpenBSD-Quellcode der Suite, entdeckt. Bleeping Computer hat den neuen Fehler hier beschrieben. Auch bei dieser Schwachstelle geht es darum, bei der Benutzeranmeldung herauszufinden, ob ein Benutzername existiert.

Das Problem liegt diesmal in der auth2-gss.c-Komponente, die standardmäßig auf Fedora, CentOS und Red Hat Enterprise Linux und möglicherweise anderen Distributionen aktiv ist. Qualys Forscher schreiben auf seclists.org, dass, wenn ein Benutzer versucht, sich zu authentifizieren, zwar jeweils eine Antwort zurückgegeben wird, unabhängig davon, ob der Benutzername gültig ist oder nicht. Beim einem existierenden Nutzernamen wird jedoch in der Antwort ein 'server_caused_failure'-Flag in der Antwort gesetzt. Dieses Flag fehlt, wenn der Benutzer nicht auf dem Server existiert. Ein Angreifer könnte also Benutzernamen durch Anfragen (Oracle-Angriff) erraten.

Die Schwachstelle CVE-2018-15473 besitzt aber einen geringen Schweregrad. Die OpenSSH-Entwickler wollen diesen Fehler daher mit niedriger Priorität irgendwann beheben. Der Open-Source-Entwickler Damien Miller, der an OpenSSH arbeitet, schreibt hier dazu, dass Systembibliotheken diese Art der Offenlegung von Informationen nicht als Bedrohung behandeln. Denn Benutzernamen werden als der nicht geheime Teil der Benutzeridentität betrachtet, der für einen Angreifer ohne das zugehörige Passwort nutzlos ist.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.