Sporadic connection problems in the wired KIT network access possible - UPDATE (09.04.24)

Today a critical vulnerability was published in OpenSSH that allows remote code execution as root. The researchers that discovered the vulnerability, Qualys, describe the vulnerability in detail in their blog post [1]. All versions of OpenSSH from 8.5p1 to exclusive 9.8p1 that use glibc are susceptible to the vulnerability, which basically means that most Linux-based systems are affected. Exploitability for remote code execution has so far only been demonstrated for i386-based (32-bit) versions, but exploitability on 64-bit systems is considered likely and the availability of an exploit will only be a matter of time. Depending on the version and configuration, successful exploitation requires hours to days and around 10,000 connections. Although this may be noticeable, it can quickly be lost in the noise of constant SSH scans if OpenSSH is open to the Internet. Therefore, patches must be applied immediately to all systems with OpenSSH, especially those that have an OpenSSH server open to the Internet, as soon as they are available. Please do not forget to restart the OpenSSH server after applying the update. Please also remember to update any base images for virtualization systems so that newly created VMs are also protected. If you are still running a 32-bit system with a vulnerable distribution and OpenSSH open to the Internet, we strongly recommend that you consider the system to be compromised.
Here is a list of currently known information on some Linux and BSD distributions:
* Debian: Bookworm (Debian 12) is affected, there is a patch available via Bookworm Security [2]. Bullseye (Debian 11) comes with an OpenSSH version older than 8.5p1, which means that Bullseye is not affected. * Ubuntu: Currently there is no advisory from the developers, but patches have recently become available. All versions from Jammy (22.04) onwards are affected [3,4,5]. Previous versions are not affected. * RHEL: Only RHEL 9 is affected, previous versions use an older OpenSSH version [6] * OpenBSD: Not affected according to the Qualys post [1] * FreeBSD: All currently supported versions affected, patches are available [7]
If no patch is yet available for your Linux distribution, a mitigation can be applied. This consists of setting the `LoginGraceTime` option to 0 in `sshd_config`. Excerpt from the Qualys blog post on this 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

AFFECTED
Service: KIT mails to Google addresses (@gmail.com / @googlemail.com)
Persons: Everybody sending or forwarding mails to google addresses

DESCRIPTION/ACTION
Mail to Google addresses detected by the KIT spam filter will be rejected more aggressively
Details see https://www.scc.kit.edu/en/services/e-mail/2024-google-mail.php

A misbehavior has been detected between a network switch type used at KIT South Campus and a Windows 11 update (version 22H2). Due to this misbehavior, the network port on the switch is automatically switched off.
As a result, the network connection or network access for the connected device is no longer available.
To enable network access, the data socket used must be communicated to the IT representative / IT admin of the OU so that he can apply for enabling via the SCC network team.

WORKAROUND
To prevent the network port from being switched off, the LLDP service can be disabled under Windows. This can be done manually (computer-specific) under "Network adapter properties". Furthermore, the SCC provides the group policy "SCC-FMC-LLDP_disable", which can be linked to the computer accounts and automatically disables LLDP under Windows. Unlocking of already blocked ports can be requested from the network team via the IT representative/IT admin of the OU.

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

TECHNICAL DETAILS
As of Windows 11 update level 22H2, sending Link Layer Discovery Protocol (LLDP for short) packets on a specific type of switching causes a network loop detection service to trigger on the switch, automatically blocking the network port.

(translated with DeepL.com)