Intel

CVE-2016-5195

Linux Kernel — Linux Kernel Race Condition Vulnerability

criticalKEV: aktiv ausgenutztPoCEPSS 84 %

Beschreibung

Racebedingung in mm/gup.c im Linux-Kernel 2.x bis 4.x vor 4.8.3 ermöglicht es lokalen Benutzern, durch die fehlerhafte Handhabung einer Kopie-bei-Schreib-Funktion (COW) auf eine schreibgeschützte Speicherzuordnung zuzugreifen und so Berechtigungen zu erlangen, wie im Oktober 2016 ausgenutzt, bekannt als "Dirty COW".

Quelle: CISA_KEVCVEORGCVELISTV5

Behebung & Mitigation

Warum sofort handeln?

Priorisierung

Dirty COW (CVE-2016-5195) ist eine der bekanntesten Linux-Privilege-Escalation-Schwachstellen überhaupt und wurde bereits im Oktober 2016 aktiv ausgenutzt — der EPSS-Wert von 83,5 % (Perzentile 99,7 %) spiegelt die extrem hohe Ausnutzungswahrscheinlichkeit wider. Der CVSS-v3-Vektor bewertet die Schwachstelle als HIGH (7.0, AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H), wobei der lokale Angriffsvektor die unmittelbare Gefahr für Systeme mit Shell-Zugang — insbesondere Shared-Hosting, CI/CD-Pipelines, Container-Hosts und Systeme mit SSH-Zugang für mehrere Nutzer — erheblich erhöht. Für KRITIS-Organisationen im NIS2-Scope ist die Priorität hoch, wenn ungepatchte Linux-Systeme mit interaktivem Nutzerzugang betrieben werden; der fehlende CISA-Ransomware-Flag ändert nichts daran, dass die Schwachstelle in Post-Exploitation-Ketten zur dauerhaften Kompromittierung genutzt wird.

Runbook · Schritt 1

Sofort-Response (0-24 h)

  • Kernel-Version auf allen Linux-Systemen prüfen (uname -r): Systeme mit Kernel < 4.8.3 sind verwundbar — Patch sofort einspielen (Distribution-spezifische Pakete: RHEL/CentOS via kernel-Paket aus Red Hat Security Advisory RHSA-2016:2098 o. ä., Ubuntu via USN-3107-1/-3107-2, Debian via DSA-3696-1).
  • Systeme, die nicht sofort gepatcht werden können, vom Netzwerk isolieren oder Zugang auf vertrauenswürdige, authentifizierte Nutzer beschränken — Dirty COW erfordert lokalen Zugriff, daher ist die Angriffsfläche primär über Shell-Zugang, SSH oder Web-Shells gegeben.
  • Alle interaktiven Nutzerkonten auf betroffenen Systemen auf unerwartete UID-0-Einträge oder SUID-Binaries prüfen (find / -perm -4000 -user root 2>/dev/null).
  • Laufende Prozesse auf verdächtige Kindprozesse von Webservern, Datenbank-Diensten oder Container-Runtimes untersuchen (ps auxf, EDR-Prozessbaum).
  • Auf Container-Hosts (Docker, LXC) sicherstellen, dass der Host-Kernel gepatcht ist — Container teilen den Host-Kernel und sind direkt betroffen.
  • Nach dem Patch System-Neustart durchführen, da der neue Kernel erst nach Reboot aktiv wird; Kexec als Notfall-Alternative prüfen, wenn Downtime kritisch ist.

Runbook · Schritt 2

Mitigation-Layer

  • Netzwerksegmentierung / Zugriffskontrolle: SSH-Zugang auf Bastion-Hosts beschränken; direkte interaktive Logins auf Produktionssystemen deaktivieren. Jede Reduktion der Anzahl lokaler Nutzer verkleinert die Angriffsfläche direkt.
  • Least Privilege / IAM: Unprivilegierte Nutzerkonten auf das absolute Minimum reduzieren; sudo-Rechte auditieren und nicht benötigte Einträge entfernen (visudo, /etc/sudoers.d/).
  • Kernel-Härtung (kurzfristig): vm.mmap_min_addr auf einen erhöhten Wert setzen (sysctl -w vm.mmap_min_addr=65536) — reduziert Null-Pointer-Exploitpfade, schützt aber nicht vollständig vor Dirty COW selbst. SELinux oder AppArmor in Enforcing-Modus versetzen, um Post-Exploitation-Schritte zu erschweren.
  • Datei-Integritätsüberwachung: AIDE oder ähnliche FIM-Lösungen auf kritische Binaries und /etc/passwd, /etc/shadow anwenden — Dirty COW wird häufig genutzt, um diese Dateien direkt zu überschreiben.
  • Container-Isolation: Seccomp-Profile und User-Namespaces aktivieren; --privileged-Container-Starts unterbinden (OPA/Gatekeeper-Policy oder PSP/PSA in Kubernetes).
  • Audit-Logging verschärfen: auditd-Regeln für Schreibzugriffe auf /proc/self/mem und /proc/*/mem aktivieren (siehe Detection-Regeln).

Runbook · Schritt 3

Detection-Regeln

  • auditd: Regel auf /proc/self/mem-Schreibzugriffe: -a always,exit -F arch=b64 -S write -F path=/proc/self/mem -k dirtycow — Alarm bei jedem Treffer, da legitime Nutzung extrem selten ist.
  • auditd / Datei-Integrität: Überwachung von Schreibzugriffen auf /etc/passwd und /etc/shadow durch Prozesse, die nicht passwd, useradd oder chpasswd sind: -w /etc/passwd -p wa -k passwd_modification.
  • Sysmon (Linux) / EDR-Prozessbaum: Alarm, wenn ein Prozess mit niedrigem UID (> 999) einen Kindprozess mit UID 0 erzeugt — Sigma-Shape: EventID: 1, User: != root, ParentUser: != root, IntegrityLevel: System.
  • KQL (Microsoft Sentinel / Defender for Endpoint): DeviceProcessEvents | where InitiatingProcessAccountSid != "S-1-5-18" and AccountSid == "S-1-5-18" | where FileName in ("bash","sh","python","perl") — erkennt Privilege-Escalation-Moment, wenn Shell mit Root-Kontext aus Nicht-Root-Prozess entsteht.
  • Netzwerk-Telemetrie (Zeek/Suricata): Ausgehende Verbindungen von Prozessen mit unerwartetem UID-0-Kontext kurz nach Login-Ereignissen eines Nicht-Root-Nutzers — korrelieren mit auth.log-Einträgen und Netzflow.

Metriken

Severity
critical
Priority-Score
160.86
KEV-Status
Aktiv ausgenutzt
Exploit-Reife
aktiv ausgenutzt (KEV)
XIEM Effective CVSS
—
CVSS v3
—
CVSS v4
—
EPSS-Perzentil
99.7 %
Kritisch — CVE liegt im obersten Fünftel aller heute bewerteten CVEs (Rang ≥ 80 %).
EPSS-Score
83.5 %
Hoch — Modell schätzt ≥ 50 % Chance auf reale Ausnutzung in 30 Tagen.
Veröffentlicht
2022-03-03 00:00 UTC
CWE
—

Ö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 Empfehlungen

IDCVE-2016-5195