Intel

CVE-2024-50302

Red Hat Security Advisory: OpenShift Container Platform 4.14.49 bug fix and security update

criticalKEV: aktiv ausgenutztPoCEPSS 0.8 %

Beschreibung

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: Kern: Berichtspuffer bei der Zuweisung auf Null setzen Da der Berichtspuffer von verschiedenen Treibern auf unterschiedliche Weise verwendet wird, initialisieren wir ihn bei der Zuweisung mit Null, um sicherzustellen, dass er nicht zur Offenlegung von Kernel-Speicher durch speziell gestaltete Berichte genutzt werden kann.

Quelle: REDHAT_CSAFREDHAT_CSAFREDHAT_CSAFSIEMENS_ADVISORYBSI_CSAFBSIREDHAT_CSAFOSVCISA_KEVCVEORGCVELISTV5EUVDSIEMENS_ADVISORY

Behebung & Mitigation

Warum sofort handeln?

Priorisierung

CVE-2024-50302 ist trotz eines CVSS-Scores von 5.5 (lokal, kein Netzwerkzugang erforderlich) auf der CISA-KEV-Liste, weil aktive Ausnutzung nachgewiesen ist — typischerweise als Informationsgewinnungs-Primitiv in mehrstufigen Angriffsketten, bei denen ein lokaler Angreifer Kernel-Speicher ausliest, um ASLR zu umgehen oder Credentials/Schlüsselmaterial zu extrahieren. Der EPSS-Wert von 0.81 % (Perzentile 54,5 %) spiegelt die Einschränkung auf lokalen Zugang wider, unterschätzt aber das Risiko in Umgebungen mit geteilten Linux-Systemen, Android-Geräten im Unternehmenseinsatz oder KRITIS-Feldgeräten mit USB-HID-Schnittstellen. Für NIS2-pflichtige Organisationen mit Android-Flotten, industriellen HMIs oder Linux-basierten Netzwerkgeräten ist die Patch-Priorisierung hoch — insbesondere wenn lokale Benutzerkonten oder physischer Gerätezugang nicht vollständig kontrolliert werden können. Ein CISA-Flag für Ransomware-Nutzung liegt nicht vor.

Runbook · Schritt 1

Sofort-Response (0-24 h)

  • Kernel-Patch einspielen: Der Fix ist im Linux-Kernel-Upstream enthalten (Commit: „HID: core: zero-initialize the report buffer"). Android-Geräte: Vendor-Security-Bulletin des Geräteherstellers prüfen (Google Pixel: März-2025-Bulletin oder neuer). Embedded-Linux-Systeme: Patch-Version bitte im Vendor-Advisory nachschlagen.
  • Auf Android-Endgeräten sofort verfügbare OTA-Updates erzwingen — insbesondere für Geräte, die als privilegierte Endpunkte (MDM-verwaltete Geräte, KRITIS-Feldgeräte) eingesetzt werden.
  • Lokalen Benutzerzugang auf betroffenen Linux-Systemen einschränken: Nicht-privilegierte interaktive Shell-Zugänge deaktivieren oder auf Minimum reduzieren, solange der Patch nicht eingespielt ist.
  • Inventar aller Linux-Kernel-Versionen im Scope erstellen — Fokus auf Systeme mit HID-Subsystem-Nutzung (USB-HID-Geräte, Bluetooth-HID, virtuelle HID-Treiber). Diese Systeme priorisiert patchen.
  • Auf Systemen ohne sofort verfügbaren Patch: USB-HID-Geräteklassen per udev-Regel oder Kernel-Modul-Blacklist (blacklist usbhid in /etc/modprobe.d/) deaktivieren, sofern betrieblich vertretbar.

Runbook · Schritt 2

Mitigation-Layer

  • Kernel-Härtung (Endpoint): kernel.dmesg_restrict=1 und kernel.perf_event_paranoid=3 via sysctl setzen, um Kernel-Speicher-Leaks über Seitenkanäle zu erschweren. kernel.unprivileged_userns_clone=0 prüfen (Distro-abhängig).
  • Modul-Blacklisting (Endpoint): Nicht benötigte HID-Treiber per /etc/modprobe.d/hid-blacklist.conf deaktivieren — z. B. blacklist hid_generic, blacklist usbhid auf Servern ohne angeschlossene HID-Geräte.
  • Physischer Zugang / Netzwerksegmentierung: USB-Ports auf Servern und KRITIS-Systemen per BIOS/UEFI oder USBGuard (usbguard generate-policy) auf autorisierte Geräte beschränken. Nicht autorisierte USB-Geräte blockieren.
  • IAM / Least Privilege: Lokale Benutzerkonten auf betroffenen Systemen auf das betrieblich notwendige Minimum reduzieren. sudo-Rechte auditieren; kein interaktiver Root-Login über SSH.
  • IPS/WAF: Nicht direkt anwendbar (lokale Schwachstelle, AV:L). Kompensation liegt auf Endpoint- und Zugriffsebene.
  • SELinux / AppArmor: Sicherstellen, dass MAC-Profile (SELinux enforcing, AppArmor) aktiv sind und HID-bezogene Prozesse einschränken — verhindert Lateral Movement nach erfolgreichem Leak.

Runbook · Schritt 3

Detection-Regeln

  • Auditd — unerwartete HID-Gerätezugriffe: auditctl -a always,exit -F arch=b64 -S open -F path=/dev/hidraw* -k hid_access — Alarm bei Zugriffen durch unbekannte Prozesse oder Benutzer.
  • Syslog / dmesg — HID-Treiber-Anomalien: Nach Einträgen suchen, die hid-core, report buffer, usbhid oder hid_generic in Kombination mit Fehler-Codes enthalten: grep -E "(hid-core|usbhid|hidraw).*(error|warn|fail)" /var/log/kern.log
  • Sigma-Shape (Linux auditd): 
    title: Suspicious HID Device Access
logsource: {product: linux, service: auditd}
detection:
  selection:
    type: SYSCALL
    syscall: open
    key: hid_access
  filter:
    uid: 0
  condition: selection and not filter
  • EDR / Prozess-Ancestry: Prozesse, die /dev/hidraw* oder /sys/bus/hid/ öffnen und nicht zu bekannten HID-Verwaltungsdiensten (z. B. bluetoothd, inputattach) gehören — Alarm auslösen.
  • USBGuard-Events: USBGuard-Log auf block-Events für nicht autorisierte HID-Geräte überwachen: journalctl -u usbguard | grep -i "block.*hid"

Metriken

Severity
critical
Priority-Score
210.35
KEV-Status
Aktiv ausgenutzt
Exploit-Reife
aktiv ausgenutzt (KEV)
XIEM Effective CVSS
5.5
Quelle: nvd-v3
CVSS v3
5.5
CVSS v4
—
EPSS-Perzentil
54.8 %
Hoch — CVE rangiert über dem Median aller heute bewerteten CVEs (Rang ≥ 36 %).
EPSS-Score
0.8 %
Niedrig — Modell schätzt < 1 % Ausnutzungs-Wahrscheinlichkeit.
Veröffentlicht
2025-03-19 20:54 UTC
CWE
—

Betroffene Betriebssysteme

  • linux

    debian / debian_linux11.0

  • linux

    redhat / enterprise_linux8.0

  • linux

    redhat / enterprise_linux9.0

  • linux

    redhat / enterprise_linux_eus8.8

  • linux

    redhat / enterprise_linux_eus9.0

  • linux

    redhat / enterprise_linux_eus9.2

  • linux

    redhat / enterprise_linux_eus9.4

  • linux

    redhat / enterprise_linux_for_arm_648.0_aarch64

  • linux

    redhat / enterprise_linux_for_arm_649.0_aarch64

  • linux

    redhat / enterprise_linux_for_arm_64_eus8.8_aarch64

  • linux

    redhat / enterprise_linux_for_arm_64_eus9.0_aarch64

  • linux

    redhat / enterprise_linux_for_arm_64_eus9.2_aarch64

  • linux

    redhat / enterprise_linux_for_arm_64_eus9.4_aarch64

  • linux

    redhat / enterprise_linux_for_ibm_z_systems8.0_s390x

  • linux

    redhat / enterprise_linux_for_ibm_z_systems9.0_s390x

  • linux

    redhat / enterprise_linux_for_ibm_z_systems_eus8.8_s390x

  • linux

    redhat / enterprise_linux_for_ibm_z_systems_eus9.0_s390x

  • linux

    redhat / enterprise_linux_for_ibm_z_systems_eus9.2_s390x

  • linux

    redhat / enterprise_linux_for_ibm_z_systems_eus9.4_s390x

  • linux

    redhat / enterprise_linux_for_power_little_endian8.0_ppc64le

  • linux

    redhat / enterprise_linux_for_power_little_endian9.0_ppc64le

  • linux

    redhat / enterprise_linux_for_power_little_endian_eus8.8_ppc64le

  • linux

    redhat / enterprise_linux_for_power_little_endian_eus9.0_ppc64le

  • linux

    redhat / enterprise_linux_for_power_little_endian_eus9.2_ppc64le

Betroffene Produkte

Aus der Hersteller-/CERT-Meldung extrahierte Produkte und Versionsbereiche. Ein Version-Range wie „<4.14.6“ impliziert die Update-Empfehlung „auf 4.14.6 oder höher aktualisieren“.

  • android

    :linux_kernel::0

  • android

    :linux_kernel:Kernel

  • go

    github.com/containers/buildah1.35.0

  • go

    github.com/containers/buildah1.37.0

  • go

    github.com/containers/buildah1.38.0

  • go

    github.com/containers/buildah

  • go

    golang.org/x/net

  • linuxfoundation

    runc1.1.12

Öffentliche Exploit-Referenzen

Öffentliche Proof-of-Concepts und Detection-Templates für diese Schwachstelle. Die Reife reicht von gemeldeten PoCs über funktionsfähige Detection-Skripte bis hin zu vollständig waffenfähigen Exploit-Modulen. NEOSEC mirrort den Code intern für forensische Analysen; nach außen verlinken wir ausschließlich auf die Original-Quellen.

Quellen & Referenzen

Verknüpfte CVEs

IDCVE-2024-50302