Sicherheitslücke in OpenSSH (Update)
8. November 2013
Update 11. November 2013 CERT.at ersucht um Beachtung der folgenden Meldung.
Da OpenSSH häufig zur Fernadministration von Unix/Linux-Servern und auch diversen Netzwerk-Komponenten eingesetzt wird, empfiehlt CERT.at dringend, den angegebenen Workaround zu implementieren bzw. auf die entsprechend gepatchte Version upzugraden. Noch ist nicht bekannt, dass Exploits die dieses Problem ausnützen können, existieren bzw. in Verwendung sind - da der Quellcode von OpenSSH offen ist, ist jedoch davon auszugehen, dass dies sehr bald der Fall sein wird.
Wenn dies mit Unknown cipher type 'aes256-gcm@openssh.com' abbricht, dann unterstützt das lokale System die verwundbare Kombination nicht und sollte daher auch nicht betroffen sein.
Informationsquelle(n):
Advisory von OpenSSH (englisch)
http://openssh.org/txt/gcmrekey.adv
Update 11. November 2013 CERT.at ersucht um Beachtung der folgenden Meldung.
Beschreibung
Das OpenSSH-Projekt hat ein Advisory zu einem Memory Corruption-Problem veröffentlicht, das im Prinzip zu einer aus der Ferne ausnützbaren Sicherheitslücke führen kann.Da OpenSSH häufig zur Fernadministration von Unix/Linux-Servern und auch diversen Netzwerk-Komponenten eingesetzt wird, empfiehlt CERT.at dringend, den angegebenen Workaround zu implementieren bzw. auf die entsprechend gepatchte Version upzugraden. Noch ist nicht bekannt, dass Exploits die dieses Problem ausnützen können, existieren bzw. in Verwendung sind - da der Quellcode von OpenSSH offen ist, ist jedoch davon auszugehen, dass dies sehr bald der Fall sein wird.
Update (2013-11-11):
Wie im Original-Advisory angegeben: dieses Problem tritt nur nach erfolgreicher Authentisierung (Post-Authentication) auf, ein Angreifer benötigt daher gültige Credentials (Username/Passwort, Key etc.).
Dies ist also vor allem für Zugänge mit ansonsten eingeschränkter Funktionalität (zB SFTP-Accounts) interessant.
Wie im Original-Advisory angegeben: dieses Problem tritt nur nach erfolgreicher Authentisierung (Post-Authentication) auf, ein Angreifer benötigt daher gültige Credentials (Username/Passwort, Key etc.).
Dies ist also vor allem für Zugänge mit ansonsten eingeschränkter Funktionalität (zB SFTP-Accounts) interessant.
Auswirkungen
Da ein Angreifer prinzipiell beliebigen Code auf betroffenen Systemen ausführen kann, sind alle Daten auf diesen Systemen, sowie potenziell alle durch diese erreichbaren (etwa durch ausspionierte Zugangsdaten, VPN, Fileshares, etc.) Daten und anderen Systeme gefährdet.Betroffene Systeme
Systeme, auf die folgende Bedingungen zutreffen:- OpenSSH 6.2 oder 6.3 installiert
- AES-GCM-Unterstützung in der verwendeten OpenSSL-Version
- ssh-Daemon aktiv und von aussen erreichbar
- Arch Linux (OpenSSH_6.3p1, AES-GCM)
- Fedora 19 (OpenSSH_6.2p2, AES-GCM))
- Ubuntu 13.10 (OpenSSH_6.2p2, AES-GCM)
ssh -c aes256-gcm@openssh.com localhost
Wenn dies mit Unknown cipher type 'aes256-gcm@openssh.com' abbricht, dann unterstützt das lokale System die verwundbare Kombination nicht und sollte daher auch nicht betroffen sein.
Abhilfe
- Das OpenSSH-Projekt gibt im Advisory folgenden Workaround an:
Abschalten von AES-GCM in der Server-Konfiguration
Dies kann durch Setzen der folgenden Zeile in der Dateisshd_config
erfolgen:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc
Dadurch werden nur noch die angegebenen Ciphers unterstützt. - Upgrade auf OpenSSH 6.4
Hinweis
Generell empfiehlt CERT.at, wo möglich die "automatisches Update"-Features von Software zu nutzen, parallel Firewall-Software aktiv und den Virenschutz aktuell zu halten.Informationsquelle(n):
Advisory von OpenSSH (englisch)
http://openssh.org/txt/gcmrekey.adv