Sporadische Verbindungsprobleme im kabelgebundenen KIT-Netzzugang möglich - UPDATE (09.04.24)

Störung bei kabelgebundenen Endgeräten am KIT CN - BEHOBEN

Heute wurde eine kritische Sicherheitslücke in OpenSSH veröffentlicht, die entfernte Codeausführung (Remote Code Execution) als root erlaubt. Die Finder der Lücke, Qualys, beschreiben die Lücke für technisch Interessierte ausführlich in Ihrem Blogpost [1]. Anfällig für die Schwachstelle sind alle Versionen von OpenSSH von 8.5p1 bis exklusive 9.8p1, die glibc verwenden. Das betrifft die meisten Linux-basierten Systeme. Eine Ausnutzbarkeit für entfernte Codeausführung wurde bisher nur für i386-basierte (32 Bit) Versionen nachgewiesen, die Ausnutzbarkeit auf 64 Bit Systemen gilt allerdings als wahrscheinlich und die Verfügbarkeit eines Exploits wird nur eine Frage der Zeit sein. Eine erfolgreiche Ausnutzung benötigt je nach Version und Konfiguration Stunden bis Tage und ca. 10.000 Verbindungen. Das kann zwar auffallen, aber auch schnell im Rauschen ständiger SSH-Scans untergehen, wenn OpenSSH ins Internet geöffnet ist. Daher müssen auf allen Systemen mit OpenSSH, vor allem solchen, die einen OpenSSH-Server ins Internet geöffnet haben, unverzüglich Patches eingespielt werden, sobald diese verfügbar sind. Bitte vergessen Sie nicht, den OpenSSH-Server nach einem Update auch neu zu starten. Bitte denken Sie außerdem daran, etwaige Base Images für Virtualisierungssysteme zu aktualisieren, damit auch neu angelegte VMs geschützt sind. Falls Sie noch ein 32-Bit System mit anfälliger Distribution und ins Internet geöffnetem OpenSSH betrieben, empfehlen wir dringend, das System als kompromittiert zu betrachten.
Hier eine Liste der aktuell bekannten Informationen zu einigen Linux- und BSD-Distributionen:
* Debian: Bookworm (Debian 12) ist betroffen, es steht ein Patch via Bookworm Security zur Verfügung [2]. Bei Bullseye (Debian 11) ist eine OpenSSH-Version mitgeliefert, die älter als 8.5p1 ist, wodurch Bullseye nicht betroffen ist. * Ubuntu: Aktuell gibt es noch kein Advisory der Entwickler, aber es stehen seit Kurzem Patches zur Verfügung. Alle Versionen ab Jammy (22.04) sind betroffen [3,4,5]. Vorherige Versionen sind nicht betroffen. * RHEL: Nur RHEL 9 ist betroffen, vorherige Versionen verwenden eine ältere OpenSSH-Version [6] * OpenBSD: Nicht betroffen laut Qualys-Post [1] * FreeBSD: Alle aktuell unterstützten Versionen betroffen, Patches stehen zur Verfügung [7]
Sollte für Ihre Linux-Distribution noch kein Patch verfügbar sein, kann eine Mitigation angewendet werden. Diese besteht daraus, in der `sshd_config` die Option `LoginGraceTime` auf 0 zu setzen. Auszug aus dem Blogpost von Qualys zu diesem Workaround:
"Finally, if sshd cannot be updated or recompiled, this signal handler race condition can be fixed by simply setting LoginGraceTime to 0 in the configuration file. This makes sshd vulnerable to a denial of service (the exhaustion of all MaxStartups connections), but it makes it safe from the remote code execution presented in this advisory." ...........
[1] https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt [2] https://security-tracker.debian.org/tracker/CVE-2024-6387 [3] https://launchpad.net/ubuntu/+source/openssh/1:8.9p1-3ubuntu0.10 [4] https://launchpad.net/ubuntu/+source/openssh/1:9.3p1-1ubuntu3.6 [5] https://launchpad.net/ubuntu/+source/openssh/1:9.6p1-3ubuntu13.3 [6] https://access.redhat.com/security/cve/cve-2024-6387#cve-cvss-v3 [7] https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc

BETROFFEN
Service: KIT E-Mails zu Google-Adressen (@gmail.com / @googlemail.com)
Personen: Alle, die Mails an Google-Adressen versenden oder weiterleiten

BESCHREIBUNG/MAßNAHME
Mails an Google-Mailadressen, die vom KIT-Spamfilter als Spam detektiert wurden, werden agressiver als bisher abgewiesen.
Details siehe https://www.scc.kit.edu/dienste/e-mail/2024-google-mail.php

Es wurde ein Fehlverhalten zwischen einem am KIT-Campus Süd eingesetzten Netzwerk-Switchtyps und einem Windows 11 Update (Version 22H2) festgestellt. Durch dieses Fehlverhalten wird der Netzwerkport am Switch automatisch abgeschaltet.
Daraufhin ist die Netzverbindung bzw. der Netzzugriff für das angeschlossene Gerät nicht mehr gegeben.
Für die Freischaltung des Netzzugriffes muss die verwendete Datendose dem IT-Beauftragten / IT-Admin der OE mitgeteilt werden, damit dieser die Freischaltung über das Netze-Team des SCC beantragen kann.

BETROFFEN
Windows 11 Clients mit Updatestand 22H2 (und voraussichtlich höher) in Verbindung mit spezifischem Netzwerk-Switchtyp

WORKAROUND
Damit der Netzwerkport nicht abgeschalten wird, kann der LLDP-Dienst unter Windows deaktiviert werden. Dies kann manuell (computerspezifisch) unter "Netzwerkadaptereigenschaften" erfolgen. Des Weiteren stellt das SCC die Gruppenrichtlinie "SCC-FMC-LLDP_disable" zur Verfügung, welche mit den Computerkonten verknüpft werden kann und automatisch LLDP unter Windows deaktiviert. Eine Freischaltung von bereits gesperrten Ports kann über den IT-Beauftragten/IT-Admin der OE beim Netze-Team beantragt werden.

TECHNISCHE DETAILS
Seit Windows 11 Updatestand 22H2 führt das Versenden von Link Layer Discovery Protokoll-Paketen (kurz LLDP-Paketen) an einem spezifischen Switchingtyp dazu, dass ein Dienst zur Erkennung von Netzwerkschleifen am Switch auslöst, wodurch der Netzwerkport automatisch gesperrt wird.