Sicherheit

Nähere Informationen gibt es auf der OpenBSD-Sicherheitsseite.

• OpenSSH 5.0 und neuer sind nicht anfällig für den X11-Übernahmeangriff, der in CVE-2008-1483 und den OpenSSH-5.0-Releasenotes beschrieben wird.

• OpenSSH 4.9 und neuer führen nicht ~/.ssh/rc für Sitzungen aus, deren ForceCommand-Direktive in sshd_config(5) überschrieben wurde. Dies wurde zwar dokumentiert, war aber ein unsicheres Verhalten (beschrieben in den OpenSSH-4.9-Releasenotes).

• OpenSSH 4.7 und neuer werden keine vertrauenswürdigen X11-Authentifikationscookies erstellen, wenn die Erstellung von nicht vertrauenswürdigen Cookies fehlschlägt (z. B. wegen absichtlicher Ressourcenüberlastung), wie in den OpenSSH-4.7-Releasenotes beschrieben.

• OpenSSH 4.5 und neuer beheben eine Schwachstelle in der Überwachung der Privilegientrennung, die genutzt werden könnte, um erfolgreiche Authentifikation vorzutäuschen (beschrieben in den OpenSSH-4.5-Releasenotes). Beachte, dass für die Ausnutzung dieser Schwachstelle ein Angreifer bereits den sshd(8)-Prozess unterwandert haben muss, der auf dem Netzwerk lauscht - keine derartige Schwachstelle ist bekannt.

• OpenSSH 4.4 und neuer sind nicht anfällig für die Schwachstelle im Signalhandler, die in den OpenSSH 4.4-Releasenotes beschrieben wird.

• OpenSSH 4.4 und neuer sind nicht anfällig für den Denial-of-Service-Angriff über das SSH-Protokoll 1, der in den OpenSSH-4.4-Releasenotes beschrieben wird.

• OpenSSH 4.3 und neuer sind nicht anfällig für die Erweiterung von Shell-Metacharakteren in Kopien über scp(1) von lokal-lokal oder remote-remote (CVE-2006-0225), wie in den OpenSSH 4.3-Releasenotes beschrieben wird.

• OpenSSH 4.2 und neuer erlauben keine Delegation von GSSAPI-Berechtigungsnachweisen nach der Authentifikation über eine Nicht-GSSAPI-Methode, wie in den OpenSSH-4.2-Releasenotes beschrieben wird.

• OpenSSH 4.2 und neuer aktivieren nicht fälschlicherweise GatewayPorts für dynamische Weiterleitungen (Fehler eingeführt in OpenSSH 4.0), wie in den OpenSSH 4.2-Releasenotes beschrieben wird.

• Portable OpenSSH 3.7.1p2 und neuere Versionen sind nicht angreifbar durch die »23. September 2003: Portable OpenSSH Multiple PAM vulnerabilities« (OpenSSH-Sicherheitshinweis). (Die OpenBSD-Versionen sind hiervon nicht betroffen.)

• OpenSSH 3.7.1 und neuere Versionen sind nicht anfällig für den »16. September 2003: OpenSSH Buffer Management bug« (OpenSSH-Sicherheitshinweis und CERT-Hinweis CA-2003-24).

• OpenSSH 3.4 und neuer sind nicht anfällig für die »26. Juni 2002: OpenSSH Remote Challenge Vulnerability« (OpenSSH-Sicherheitshinweis).

• OpenSSH 3.2.1 und neuer sind nicht anfällig für den »21. April 2002: Pufferüberlauf im AFS/Kerberos-Tokenpassing-Code« (OpenSSH-Sicherheitshinweis: Versionen vor OpenSSH 3.2.1 erlauben privilegierten Zugriff falls AFS/Kerberos-Tokenpassing einkompiliert und aktiviert ist (entweder im System oder in sshd_config).

• OpenSSH 3.1 und neuer sind mit dem »7. März 2002: Off-by-one-Fehler im Channel-Code« nicht angreifbar (OpenSSH-Sicherheitshinweis).

• OpenSSH 3.0.2 und neuer erlauben keinem Benutzer, die Umgebungsvariablen von login(1) zu umgehen, wenn UseLogin eingeschaltet ist. Die UseLogin-Option ist standardmäßig bei allen OpenSSH-Versionen abgeschaltet.

• OpenSSH 2.9.9 und neuer sind nicht anfällig für die »26. Sep 2001: Schwachstelle in OpenSSHs Quell-IP-basierten Zugriffskontrolle für die Publickey-Authentifizierung im SSH-Protokoll v2« (OpenSSH-Sicherheitshinweis).

• OpenSSH 2.9.9 und neuer erlauben einem Anwender nicht, Dateien mit dem Namen »cookies« zu löschen, wenn die X11-Weiterleitung aktiviert wurde. X11-Weiterleitung ist standardmäßig abgeschaltet.

• OpenSSH 2.3.1, eine niemals veröffentlichte Entwicklungsversion, war anfällig für die »8. Feb 2001: Authentication By-Pass Vulnerability in OpenSSH-2.3.1« (OpenBSD-Sicherheitshinweis). In Protokoll 2 konnte die Authentifikation umgangen werden, wenn die Publickey-Authentifikation erlaubt war. Dieses Problem existiert nur in OpenSSH 2.3.1, einer drei Wochen bestehenden Entwicklerversion. OpenSSH 2.3.0 und Versionen, die neuer als 2.3.1 sind, sind dementsprechend nicht anfällig für dieses Problem.

• OpenSSH 2.3.0 und neuere Versionen erlauben es keinen böswilligen Servern, auf das X11-Display oder den ssh-agent des Clients zuzugreifen. Dieses Problem wurde in OpenSSH 2.3.0 korrigiert.

• OpenSSH 2.3.0 und neuere Versionen sind nicht anfällig für die »8. Feb 2001: SSH-1 Daemon CRC32 Compensation Attack Detector Vulnerability« (RAZOR Bindview Hinweis CAN-2001-0144). Ein Pufferüberlauf im »CRC32 compensation attack detector« kann zu einem Remotezugriff auf root führen. Dieses Problem wurde ab Version 2.3.0 beseitigt. Somit sind Versionen vor 2.3.0 angreifbar.

• OpenSSH 2.2.0 und neuere Versionen sind nicht anfällig für die »7. Feb 2001: SSH-1-Sitzungsschlüssel-Wiederherstellungs-Verwundbarkeit« (CORE-SDI-Hinweis CORE-20010116). OpenSSH legt der Verbindungsrate Beschränkungen auf und macht damit den Angriff undurchführbar. Zusätzlich wurde das Bleichenbacher Orakel seit dem 29. Januar 2001 komplett beseitigt.

• OpenSSH 2.1.1 und neuer erlauben einem Angreifer nicht, beliebige Kommandos mit den Berechtigungen von sshd auszuführen, wenn UseLogin vom Administrator eingeschaltet ist. UseLogin ist standardmäßig abgeschaltet. Dieses Problem wurde in OpenSSH 2.1.1 korrigiert.

• OpenSSH war niemals anfällig für die »5. Feb 2001: SSH-1 Brute Force Password Vulnerability« (Crimelabs-Sicherheitshinweis CLABS200101).

• OpenSSH war nicht anfällig für die RC4-Chiffre-Passwordcracking-, Replay- oder Modification-Angriffe. Zu der Zeit, als OpenSSH aus der Taufe gehoben wurde, war bereits bekannt, dass SSH 1 die RC4-Stromchiffre komplett falsch benutzt hat. Deshalb wurde die RC4-Unterstützung aus OpenSSH entfernt.

• OpenSSH war nicht anfällig für Clientforwarding-Angriffe in unverschlüsselten Verbindungen, da die Unterstützung für nicht verschlüsselte Verbindungen gleich zu Beginn des OpenSSH-Projekts entfernt wurde.

• OpenSSH war nicht anfällig für die IDEA-Verschlüsselungsalgorithmen-Attacken auf das letzte Paket, da der IDEA-Algorithmus nicht unterstützt wird. Das IDEA-Patent macht es unattraktiv für eine Unterstützung in OpenSSH.

• OpenSSH lässt den localhost nicht aus, wenn es um die Hostkey-Überprüfung geht; somit ist sie nicht verwundbar mit dem Angriff, in dem die Hostkey-Authentifikation umgangen wird.

• OpenSSH konnte nicht über unkontrollierbares X11-Weiterleiten angegriffen werden, da X11-Weiterleitung standardmäßig deaktiviert ist und der Anwender es ablehnen kann.

• OpenSSH hat die SSH-1-Protokollunzulänglichkeiten, die einen Insertion-Angriff schwierig aber möglich machen. Der CORE-SDI-Deattack-Mechanismus wird benutzt, um den normalen Fall zu eliminieren. Wege, das Problem beseitigen zu können, werden untersucht, da das SSH-1-Protokoll noch nicht tot ist.