Liebes Linux-Magazin-Team,
bitte beachten Sie die Informationen zu den verfügbaren Sicherheitsupdates
in der folgenden Sicherheitsmeldung.
Historie:
Version 6 (21.06.24):
Für Debian 10 Buster (LTS) steht ein Sicherheitsupdate für ‘putty’ in
Version 0.74-1+deb11u1~deb10u2 bereit, um die Schwachstelle zu beheben.
Version 5 (10.05.24):
Citrix informiert darüber, dass Versionen von XenCenter für Citrix
Hypervisor 8.2 CU1 LTSR die Drittanbieterkomponente PuTTY enthalten,
welche dazu dient SSH-Verbindungen von XenCenter zu virtuellen Maschinen
von Gästen (Guest VMs) aufzubauen, wenn ‘Open SSH Console’ ausgewählt
wird. Ab Version 8.2.6 ist die Verwendung von PuTTY in XenCenter für
Citrix Hypervisor 8.2 CU1 LTSR überholt, Versionen nach 8.2.7 werden PuTTY
nicht mehr enthalten.
Version 4 (22.04.24):
Für openSUSE-SU-2024:0111-1 steht ein Sicherheitsupdate für ‘putty’ auf
Version 0.81 bereit, um die Schwachstelle zu beheben.
Version 3 (18.04.24):
Für Fedora 38 und 39 sowie Fedora EPEL 8 und 9 stehen Sicherheitsupdates
in Form von ‘putty-0.81-1’- Paketen im Status ‘testing’ bereit, um die
Schwachstelle zu beheben.
Version 2 (17.04.24):
Für Fedora 38 und 39 stehen Sicherheitsupdates in Form von
‘filezilla-3.67.0-1’- und ‘libfilezilla-0.47.0-1’- Paketen im Status
‘testing’ bereit, um die Schwachstelle zu beheben.
Version 1 (16.04.24):
Neues Advisory
Ein Angreifer kann eine Schwachstelle aus der Ferne ausnutzen, um
Informationen auszuspähen.
Für die Ausnutzung der Schwachstelle sind keine Privilegien erforderlich.
Laut Hersteller sollte davon ausgegangen werden, dass jeder NIST P-521
Schlüssel, der mit PuTTY verwendet wurde, potentiell kompromittiert ist,
unabhängig davon, wo dieser generiert wurde.
Standardmäßig werden SSH-Schlüssel jedoch mit anderen Algorithmen generiert,
die nicht betroffen sind.
Ein Sicherheitsupdate auf die PuTTY Version 0.81 behebt die Schwachstelle.
Zusätzlich zum Update sollte dringend überprüft werden, ob NIST P-521 ECDSA-
Schlüssel mit älteren PuTTY Versionen verwendet wurden, welche an der
Signatur ‘ecdsa-sha2-nistp521’ erkennbar sind.
Kann dies nicht ausgeschlossen werden, sollte ein neuer Schlüssel generiert
und der möglicherweise kompromittierte Schlüssel zurückgerufen werden. Bei
SSH-Servern geschieht dies typischerweise durch Entfernen des Schlüssels aus
der SSH-Konfigurationsdatei ‘authorized_keys’.
Referenzen:
Dieses Advisory finden Sie auch im DFN-CERT Schwachstellenarchiv unter:
[https://adv-archiv.dfn-cert.de/adv/2024-0992]
Mit freundlichen Grüßen,
Ihr DFN-CERT Incident Response Team
—
(c) DFN-CERT Services GmbH, all rights reserved!
Bei einer Weitergabe der Informationen ist auf den Ursprung in
angemessener Weise hinzuweisen.
Im Übrigen gelten die Bestimmungen zum Copyright für die DFN-CERT
Webseite. https://www.dfn-cert.de/impressum.html
