Cybersicherheit

OpenSSH 10.6 deaktiviert einen Teil der Komprimierung und lehnt aus Sicherheitsgründen bestimmte Benutzernamen ab

OpenSSH 10.6 deaktiviert die LZ77-Komponente der sitzungsübergreifenden Komprimierung von SSH-Kanälen, nachdem nachgewiesen wurde, dass sie zur Wiederherstellung geheimer Daten genutzt werden kann. Außerdem lehnt es die Zeichen $ und \ in Benutzernamen ab, die über die Befehlszeile übergeben werden, um das Risiko von Shell-Befehlsinjektionen zu begrenzen. Einige Automatisierungsaufgaben sowie weitere Änderungen an Post-Quanten-Schlüsseln und dem Tool scp können betroffen sein.

2026-10-07
4 Min. Lesezeit
0 Aufrufe
certi.news Editorial Team
OpenSSH 10.6 deaktiviert einen Teil der Komprimierung und lehnt aus Sicherheitsgründen bestimmte Benutzernamen ab

Die Version OpenSSH 10.6 enthält zwei Sicherheitsänderungen, die einige bisherige Nutzungsszenarien beeinträchtigen können: die Deaktivierung der LZ77-Komponente, die für den Aufbau eines Wiederholungswörterbuchs bei der SSH-Komprimierung zuständig ist, sowie die Ablehnung von Benutzernamen, die bei der Übergabe über die Befehlszeile die Zeichen $ und \ enthalten. Die Projektentwickler trafen diese Entscheidung in Kenntnis dessen, dass einige Umgebungen und Tools angepasst werden müssen.

Warum wurde die SSH-Komprimierung abgeschwächt?

Eine einzelne SSH-Sitzung kann einen interaktiven Terminalkanal, eine Portweiterleitung oder einen dynamischen SOCKS-Proxy übertragen. Wenn die Komprimierung aktiviert war, teilten sich die Kanäle einen gemeinsamen Komprimierungszustand. Die Forscher Fabian Bäumer und Marcus Brinkmann von der Ruhr University Bochum zeigten, dass ein Angreifer von ihm ausgewählten Text in einen Kanal einschleusen und den verschlüsselten Datenverkehr überwachen kann, um geheime Daten zu erschließen, die über einen anderen Kanal derselben Sitzung übertragen werden.

Der Angriff beruht auf dem LZ77-Speicher: Sequenzen, die zuvor aufgetreten sind, werden wiederverwendet, statt vollständig codiert zu werden. Wenn die Vermutung des Angreifers mit einem Teil des Geheimnisses übereinstimmt, kann das komprimierte Ergebnis geringfügig kürzer werden und dadurch ein Signal liefern, das bei der Wiederherstellung der Daten hilft. Diese Methode gehört zur Familie der CRIME- und BREACH-Angriffe, erfordert jedoch eine spezielle Konfiguration: aktivierte SSH-Komprimierung, die Möglichkeit, einen Teil des Datenverkehrs zu kontrollieren, sowie das Vorhandensein des Geheimnisses und des vom Angreifer kontrollierten Kanals innerhalb einer SSH-Sitzung mit mehreren Kanälen.

In den weniger verrauschten Tests stellten die Forscher ein acht Zeichen langes Geheimnis aus einem Alphabet mit 26 Zeichen mit durchschnittlich 276 Vermutungen über 100 Versuche wieder her. In einem browserbasierten und stärker verrauschten Szenario stieg die Zahl auf etwa 27.600 Vermutungen. Laut dem Ausgangsmaterial wurden die Proof-of-Concept-Modelle mit Claude Code erstellt.

Was ändert sich praktisch bei der Komprimierung?

OpenSSH behält die Huffman-Codierung bei, deaktiviert jedoch den LZ77-Teil sowohl in ssh als auch in sshd. Die Komprimierung verschwindet daher nicht vollständig, wird aber weniger effektiv. Das Projekt erklärt, dass gewöhnliche interaktive Sitzungen wahrscheinlich keinen großen Unterschied feststellen werden, während automatisierte Aufgaben, die große Mengen komprimierbarer Daten über Verbindungen mit begrenzter Kapazität übertragen, beeinträchtigt werden können.

Die Empfehlung von OpenSSH lautet, die Komprimierung auf die Anwendungsschicht zu verlagern, wo sie normalerweise effizienter ist und dieser Art von Angriff nicht ausgesetzt ist. Praktisch sollten Betreiber von Automatisierungssystemen, die auf SSH-Komprimierung angewiesen sind, nach dem Upgrade die Übertragungsgröße und Ausführungszeit messen und anschließend bestimmen, ob die Datenkomprimierung vor dem Senden geeigneter ist als die Nutzung der SSH-Komprimierung.

Benutzernamen und Automatisierungspfade

Version 10.6 lehnt die Zeichen $ und \ in Benutzernamen ab, die über die Befehlszeile übergeben werden. Dies richtet sich gegen interne Tools, CI-Aufgaben und Agenten, die einen Befehl wie ssh "$INPUT_USER@host" erzeugen. Anschließend kann der Benutzername an Direktiven wie ProxyCommand oder Match exec gelangen, wo diese Zeichen als Teil eines Shell-Aufbaus interpretiert werden können, statt als gewöhnliche Daten betrachtet zu werden.

Dieselbe Einschränkung gilt nicht, wenn der Benutzername über die Direktive User in einer SSH-Konfigurationsdatei festgelegt wird. Daher können legitime Konten, die diese Zeichen enthalten, auf diese Weise weiterhin nutzbar sein. Skripte und Tools, die sie direkt über die Befehlszeile übergeben, müssen jedoch möglicherweise geändert werden. Dies folgt auf eine verwandte Korrektur in OpenSSH 10.3: Die Prüfung auf Shell-Zeichen erfolgte zu spät, sodass sie den Expansionspfad in ssh_config erreichen konnten.

Weitere Änderungen, die den Arbeitsablauf beeinflussen können

  • Der hybride Post-Quanten-Signaturalgorithmus ssh-mldsa44-ed25519 verliert das experimentelle Suffix @openssh.com. Das bedeutet, dass mit der vorherigen Implementierung erzeugte Schlüssel neu erstellt oder entfernt werden müssen.
  • Das Projekt hat damit begonnen, die Einstellung von scp -R zum Kopieren von einem entfernten Host zu einem anderen entfernten Host vorzubereiten. Die Option funktioniert in Version 10.6 weiterhin, gibt jedoch eine Warnung aus und soll künftig ignoriert werden.

Diese Änderungen zeigen, dass die Kompatibilität mit dem bisherigen Verhalten keine absolute Priorität mehr hat, wenn die automatisierte Nutzung einen Weg zur Datenexfiltration oder Befehlsinjektion eröffnet. Die praktischen Einschränkungen sind jedoch nicht gleich: Das Risiko eines Lecks durch die Komprimierung erfordert eine bestimmte Sitzung und spezifische Bedingungen, während die Ablehnung von Benutzernamen in Skripten, die auf externen Eingaben beruhen, sofort sichtbar werden kann. Daher müssen Betriebsteams das Upgrade testen, den Aufbau von SSH-Befehlen überprüfen sowie Schlüssel und Kopieroptionen kontrollieren, bevor sie die Version umfassend einsetzen.

Nachrichtenquelle
The New Stack - Software Development
Originalquelle öffnen ↗
c
Autor

certi.news Editorial Team

Thema erkunden

Verwandte Themen und Entitäten

Aus derselben Kategorie

Das könnte Sie interessieren

Alle Nachrichten anzeigen