Was ist Copy Fail?

CVE-2026-31431 (CVSS 7.8) ist ein Logikfehler in der AEAD-Socket-Schnittstelle (AF_ALG) des Linux-Kernels, der 2026 entdeckt wurde. Die Schwachstelle ermöglicht es jedem nicht privilegierten lokalen Benutzer, innerhalb von Sekunden Root-Rechte zu erlangen.

Technische Details

• Betroffene Komponente: algif_aead-Kernelmodul (AF_ALG-Krypto-Schnittstelle)
• Schwachstellentyp: Logikfehler bei der Verarbeitung von Kopiervorgängen
• Angriffsvektor: Lokal
• Erforderliche Privilegien: Keine (nicht privilegierter Benutzer)
• Benutzerinteraktion: Keine
• Auswirkung: Vollständige Systemkompromittierung (Root-Zugriff)

Betroffene Systeme

Kernel-Versionen: Linux-Kernel >= 4.10 (veröffentlicht 2017)

Betroffene Distributionen:

• Red Hat Enterprise Linux 7, 8, 9
• CentOS 7, 8, 9 (und Stream)
• Fedora (alle derzeit unterstützten Versionen)
• Ubuntu 17.04 und später
• Debian 9 (Stretch) und später
• SUSE Linux Enterprise 12, 15

Hinweis: Jede Linux-Distribution mit Kernel 4.10 oder neuer ist potenziell verwundbar.

Warum dies wichtig ist

Diese Schwachstelle ist besonders gefährlich, weil:

1. Keine Privilegien erforderlich – Jedes Benutzerkonto kann sie ausnutzen
2. Sofortige Eskalation – Root-Zugriff in Sekunden
3. Weitreichende Auswirkung – Betrifft 7+ Jahre Kernel-Veröffentlichungen
4. Lokale Ausführung – Kein Remote-Zugriff erforderlich, aber Angreifer, die einen ersten Fußabdruck erlangen, können sofort eskalieren
5. Aktive Ausnutzung – Öffentliche Exploits sind verfügbar

Auswirkungen in der Praxis

Sobald ein Angreifer irgendeine Form von lokalem Zugriff hat (SSH, Web-Shell, Container-Escape usw.), kann er:

• Vollständige Kontrolle über das System erlangen
• Permanente Hintertüren installieren
• Auf sensible Daten zugreifen
• Zu anderen Systemen im Netzwerk wechseln
• Ransomware oder Kryptominer einsetzen

Verfügbare Behebungen

Während auf vom Hersteller bereitgestellte Kernel-Patches gewartet wird, stehen mehrere Abschwächungsstrategien zur Verfügung. cfDr implementiert alle davon, mit intelligenten Empfehlungen basierend auf Ihrer Systemkonfiguration.

Schutzstufen verstehen

Nicht alle Behebungen sind gleichwertig. Hier ist, was Sie wissen müssen:

Empfohlener Ansatz: Defense-in-Depth

cfDr's Standardempfehlung: Flag 3 (Modul-Blacklist + SELinux)

Dies bietet zwei unabhängige Schutzebenen:``` ┌─────────────────────────────────────────────────┐ │ Layer 1: Module Blacklist │ │ • Prevents modprobe algif_aead │ │ • Persists across reboots │ │ • CAN be bypassed by malicious root (insmod) │ ├─────────────────────────────────────────────────┤ │ Layer 2: SELinux Policy │ │ • Blocks AF_ALG socket() at syscall level │ │ • Works even if module is loaded │ │ • CANNOT be bypassed from userspace │ │ • Covers user_t, unconfined_t (majority cases) │ └─────────────────────────────────────────────────┘

Result: If either layer fails, the other still protects

Dies ist jedoch akzeptabel, weil:

1. Die Schwachstelle zielt auf Privilege Escalation (nicht privilegiert → root) ab
2. Wenn ein Angreifer bereits root ist, kann er direkt ausnutzen, ohne das Modul zu laden
3. Die Modul-Blacklist schützt vor dem primären Angriffsvektor

Vollständige Schutzstrategie

Für vollständigen, nicht umgehbaren Schutz benötigen Sie:

Modul-Blacklist + mindestens eines von:

• SELinux-Richtlinie (empfohlen für Enterprise Linux)
• systemd seccomp-Filter (Schutz pro Dienst)
• eBPF-LSM-Programm (nur RHEL 9+, systemweit)

Referenz der Minderungs-Flags

cfDr verwendet bitweise Flags, um mehrere Minderungen zu aktivieren:

Flags berechnen: 1 (Blacklist) + 2 (SELinux) + 4 (seccomp) + 8 (eBPF) = Summe

Bekannte Abdeckungslücken

SELinux-Schutz:

• Deckt nur die in der Richtlinie angegebenen Domänen ab: user_t, unconfined_t, httpd_t, postgresql_t, mysqld_t
• Prozesse, die in anderen SELinux-Domänen laufen, sind möglicherweise nicht geschützt
• In der Praxis decken user_t und unconfined_t die überwiegende Mehrheit der Angriffsszenarien ab

systemd seccomp-Schutz:

• Schützt nur explizit konfigurierte Dienste
• Die Standardkonfiguration deckt ab: httpd, nginx, postgresql, mariadb, redis, memcached
• Prozesse außerhalb dieser Dienste sind nicht geschützt

eBPF-LSM-Schutz:

• Erfordert Kernel 5.7+ (RHEL 9, Fedora 34+)
• Die Komplexität erfordert Fachwissen für eine korrekte Implementierung
• Kann umfassenden systemweiten Schutz bieten, wenn er richtig konfiguriert ist

Erkennungsmethodik

Wie cfDr Schwachstellen erkennt

cfDr führt eine umfassende Bewertung über mehrere Dimensionen hinweg durch:

1. Kernel-Versionsprüfung```bash

uname -r

• Überprüft, ob das Modul algif_aead im Kernel vorhanden ist
• Prüft Modulpfad und Metadaten

3. Ladestatus des Moduls```bash

lsmod | grep algif_aead

• Identifiziert aktive AF_ALG-Sockets
• Weist auf potenzielle aktive Ausnutzung hin

5. Erkennung vorhandener Gegenmaßnahmen

Modul-Blacklist:```bash grep -E "blacklist algif_aead|install algif_aead" /etc/modprobe.d/*.conf

systemd seccomp:```bash systemctl show | grep RestrictAddressFamilies

Wie cfDr funktioniert

Architektur

cfDr ist als moderne Ansible-Rolle mit mehreren Playbook-Einstiegspunkten aufgebaut:``` cfDr/ ├── roles/ │ └── cve_2026_31431/ # Main role │ ├── tasks/ │ │ ├── main.yml # Role orchestration │ │ ├── assessment.yml # Vulnerability detection │ │ ├── remediation_module_blacklist.yml │ │ ├── remediation_selinux.yml │ │ ├── remediation_seccomp.yml │ │ ├── remediation_ebpf.yml │ │ ├── reporting.yml # Status reporting │ │ └── inventory_update.yml # Inventory generation │ ├── templates/ # Config file templates │ ├── defaults/ # Default variables │ └── handlers/ # Service restarts, etc. ├── quickstart.yml # Simplest usage ├── sample_playbook.yml # Multiple examples └── cve_2026_31431_playbook.yml # Full-featured playbook

Remediationsmodus (apply_remediation=true)```

1-8. [Same as Assessment Mode] ↓ 9. Apply Module Blacklist (if flag 1) • Unload module if loaded • Create blacklist config • Update initramfs/initrd • Verify blacklist works ↓ 10. Apply SELinux Policy (if flag 2) • Install policy packages • Compile policy module • Install policy • Verify policy active ↓ 11. Apply systemd seccomp (if flag 4) • Create drop-in files • Reload systemd • Restart services • Verify filters active ↓ 12. Apply eBPF LSM (if flag 8) • Compile eBPF program • Load into kernel • Verify program attached ↓ 13. Re-assess protection status ↓ 14. Generate reports ↓ 15. Create summary

3. Aktualisiert initramfs/initrd, damit die Änderungen Neustarts überdauern:
   • Debian/Ubuntu: update-initramfs -u
   • RHEL/Fedora: dracut -f
4. Überprüft, dass das Modul nicht über modprobe geladen werden kann

Schutz: Sofortig, kein Neustart erforderlich Persistenz: Übersteht Neustarts und Kernel-Updates

SELinux-Richtlinie (Flag 2)

Was sie tut:

1. Installiert erforderliche Pakete:
   • policycoreutils
   • policycoreutils-python-utils
   • selinux-policy-devel
   • checkpolicy
2. Erstellt ein SELinux-Richtlinienmodul, das die Erstellung von AF_ALG-Sockets verweigert
3. Kompiliert die Richtlinie mit dem SELinux-Build-System
4. Installiert das Richtlinienmodul: semodule -i cve_2026_31431_af_alg_deny.pp
5. Überprüft, dass die Richtlinie aktiv ist

Geschützte Domänen (Standard):

• user_t - Prozesse regulärer Benutzer
• unconfined_t - Unbeschränkte Prozesse
• httpd_t - Apache-Webserver
• postgresql_t - PostgreSQL-Datenbank
• mysqld_t - MySQL/MariaDB-Datenbank

Schutz: Blockiert auf der LSM-Ebene, kann nicht umgangen werden Persistenz: Richtlinie übersteht Neustarts

systemd seccomp (Flag 4)

Was es tut:

1. Erstellt systemd-Drop-in-Dateien: /etc/systemd/system/<service>.service.d/90-cve-2026-31431-block-af-alg.conf
2. Fügt die Direktive RestrictAddressFamilies=~AF_ALG hinzu
3. Lädt den systemd-Daemon neu
4. Startet betroffene Dienste neu
5. Überprüft, dass die Filter aktiv sind

Geschützte Dienste (Standard):

• httpd, nginx - Webserver
• postgresql, mariadb - Datenbanken
• redis, memcached - Cache-Server

Schutz: Blockiert die Socket-Erstellung auf Syscall-Ebene pro Dienst Persistenz: Übersteht Neustarts und Dienst-Updates

eBPF LSM (Flag 8)

Was es tut:

1. Kompiliert ein eBPF-Programm, um die Erstellung von AF_ALG-Sockets zu blockieren
2. Lädt das Programm in den Kernel
3. Hängt es an LSM-Hooks an
4. Überprüft, dass das Programm aktiv ist

Anforderungen:

• Kernel 5.7+ mit CONFIG_BPF_LSM=y
• RHEL 9, Fedora 34+ oder ein selbst kompilierter Kernel

Schutz: Dynamische, programmierbare systemweite Richtlinie Persistenz: Erfordert einen Systemdienst, der beim Booten neu geladen wird

Inventar-Generierung

cfDr kann gebrauchsfertige Inventardateien generieren, die nur verwundbare Hosts enthalten:

Generierte Dateien:``` inventory_output/ ├── vulnerable_hosts.yml # YAML inventory ├── vulnerable_hosts.ini # INI inventory ├── group_vars_vulnerable_hosts.yml # Group variables └── host_vars/ ├── host1.yml # Per-host details └── host2.yml

Was könnte betroffen sein (seltene Randfälle)

Laut R-fx Networks Analyse:

„Für die meisten HPC-Umgebungen wird dies nichts kaputt machen – AF_ALG ist eine Userspace-Eingangstür zur Kernel-Krypto, die fast niemand tatsächlich nutzt."

Nur diese extrem seltenen Konfigurationen könnten betroffen sein:

1. OpenSSL mit explizit aktiviertem afalg-Engine

NICHT standardmäßig auf RHEL. Die afalg-Engine muss explizit konfiguriert werden:```bash

Check if afalg engine is enabled (rare)

openssl engine afalg

If this returns "afalg is not available", you're safe

Erwartetes Ergebnis: Alle Dienste funktionieren weiterhin normal.

Konsens der professionellen Sicherheits-Community

Mehrere maßgebliche Sicherheitsorganisationen bestätigen unsere Bewertung:

CERT-EU (30. April 2026):

„dm-crypt / LUKS, kTLS, IPsec, SSH und Standard-Builds von OpenSSL / GnuTLS hängen nicht von AF_ALG ab"

Sysdig (29. April 2026):

Dokumentiert, dass Standard-Krypto-Operationen In-Kernel-APIs verwenden, nicht AF_ALG-Sockets

R-fx Networks (2. Mai 2026):

„Hosting-Workloads nutzen AF_ALG nicht legitim, sodass es sicher deaktiviert werden kann als Maßnahme, ohne Produktionsdienste zu beeinträchtigen"

HPCsec (30. April 2026):

„Für die meisten HPC-Umgebungen wird dies nichts brechen – AF_ALG ist eine Userspace-Eingangstür zur Kernel-Krypto, die fast niemand tatsächlich nutzt"

Empfehlung für Produktionsbereitstellung

Für Standard-RHEL/CentOS/Fedora-Umgebungen:

1. ✅ cfDr-Flag 3 sofort bereitstellen – Null betriebliche Auswirkungen
2. ✅ Alle kritischen Dienste funktionieren weiterhin – Von der Sicherheits-Community verifiziert
3. ✅ Keine Anwendungsänderungen erforderlich – Standard-Krypto-Pfade unberührt
4. ✅ Red Hat auf Kernel-Patches überwachen – Aber nicht mit der Abschwächung warten
5. ✅ Defense-in-Depth nach dem Patchen beibehalten – Zusätzliche Sicherheitsebene ohne Kosten

Entscheidungsmatrix:

Zusammenfassung

Die Maßnahmen von cfDr sind für alle Standard-RHEL-Bereitstellungen sicher. Das algif_aead-Modul und die AF_ALG-Socket-Schnittstelle werden von keiner kritischen System-Kryptografie auf Enterprise-Linux-Systemen verwendet.

Was das bedeutet:

• ✅ Ihre Festplattenverschlüsselung (LUKS) funktioniert weiterhin
• ✅ Ihre VPNs (IPsec) funktionieren weiterhin
• ✅ Ihre SSH-Verbindungen funktionieren weiterhin
• ✅ Ihre Webserver (HTTPS) funktionieren weiterhin
• ✅ Ihre Datenbanken funktionieren weiterhin
• ✅ Alle Authentifizierungssysteme funktionieren weiterhin

Das einzige theoretische Risiko betrifft benutzerdefinierte Anwendungen, die explizit für die Nutzung von AF_ALG-Sockets programmiert wurden – ein so seltenes Szenario, dass mehrere Sicherheitsorganisationen unabhängig voneinander bestätigt haben, dass es sicher ist, AF_ALG in Unternehmensumgebungen zu blockieren.

Empfohlener Workflow

Standard-Enterprise-Workflow

Dieser Workflow balanciert Gründlichkeit mit betrieblicher Sicherheit:

Schritt 1: Erste Bewertung (Nur-Lese-Modus)```bash

Scan all hosts without making changes

ansible-playbook -i inventory quickstart.yml

Schritt 2: Schwachstelleninventar erstellen```bash

Create inventory of vulnerable hosts with recommendations

ansible-playbook -i inventory quickstart.yml -e generate_inventory=true -e inventory_output_dir=./vulnerable_hosts

Schritt 3: Behebung in der Nicht-Produktionsumgebung testen```bash

Apply to test/dev hosts first

ansible-playbook -i vulnerable_hosts/vulnerable_hosts.yml cve_2026_31431_playbook.yml
-e apply_remediation=true
--limit 'dev*:test*'

Testanwendungen:

• Überprüfen, dass kritische Dienste funktionieren
• Anwendungsfunktionalität prüfen
• Logs auf Probleme überwachen

Schritt 4: Produktionsbehebung (gestaffelt)```bash

Apply to production in stages

Stage 1: Web tier

ansible-playbook -i vulnerable_hosts/vulnerable_hosts.yml cve_2026_31431_playbook.yml
-e apply_remediation=true
--limit 'web*'

Stage 2: Application tier

ansible-playbook -i vulnerable_hosts/vulnerable_hosts.yml cve_2026_31431_playbook.yml
-e apply_remediation=true
--limit 'app*'

Stage 3: Database tier (most critical)

ansible-playbook -i vulnerable_hosts/vulnerable_hosts.yml cve_2026_31431_playbook.yml
-e apply_remediation=true
--limit 'db*'

Dokument:

• Erfassen, welche Hosts behoben wurden
• Notieren Sie alle aufgetretenen Probleme
• Aktualisieren Sie die Änderungsmanagement-Aufzeichnungen

Erwartete endgültige Ausgabe:``` CVE-2026-31431 Summary Report

Total hosts scanned: 50 Vulnerable hosts: 0

All hosts protected with defense-in-depth mitigations

Verwenden Sie diesen Ansatz, wenn:

• Aktive Ausnutzung erkannt wurde
• Kritische Systeme unmittelbar gefährdet sind
• Zeit wichtiger ist als der Prozess

Vorsicht: Dies wendet Gegenmaßnahmen gleichzeitig auf ALLE verwundbaren Hosts an. Überwachen Sie genau.

Workflow für kontinuierliche Überwachung

Für laufende Compliance und Erkennung neuer Systeme:```bash

Weekly automated scan

0 2 * * 0 ansible-playbook -i inventory quickstart.yml -e generate_inventory=true

Alert on new vulnerabilities

(integrate with monitoring system)

Verifizierungs-Workflow

Nach der Behebung die Schutzmaßnahmen verifizieren:```bash

On remediated host:

sudo lsmod | grep algif_aead

Should return nothing (module not loaded)

sudo modprobe algif_aead

Should fail: "modprobe: ERROR: could not insert 'algif_aead'"

cat /etc/modprobe.d/blacklist-algif_aead-cve-2026-31431.conf

Should show blacklist configuration

Check SELinux policy

sudo semodule -l | grep cve_2026_31431

Should show: cve_2026_31431_af_alg_deny

Check seccomp (for services)

systemctl show httpd | grep RestrictAddressFamilies

Should show: RestrictAddressFamilies=~AF_ALG

Verwendung mit einem benutzerdefinierten Inventar```bash

Assess with your inventory

ansible-playbook -i /path/to/your/inventory quickstart.yml

Remediate vulnerable hosts

ansible-playbook -i /path/to/your/inventory quickstart.yml
--limit vulnerable_hosts
-e apply_remediation=true

Erweiterte Konfiguration

Anpassen der Mitigations-Flags

Standard-Mitigationen pro Playbook-Lauf überschreiben:```bash

Module blacklist only

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=1

SELinux only

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=2

Module blacklist + SELinux (default recommended)

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=3

Enhanced: Blacklist + SELinux + seccomp

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=7

Maximum: All mitigations (RHEL 9+ only)

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=15

Anpassen von seccomp-Diensten

Bearbeiten Sie roles/cve_2026_31431/defaults/main.yml:```yaml

Add additional services to protect

seccomp_protected_services:

• httpd
• nginx
• postgresql
• mariadb
• redis
• memcached
• your-custom-service # Your service

Verwenden von Beispiel-Playbook-Vorlagen

Die sample_playbook.yml enthält mehrere Beispiele:```yaml

Example 1: Assessment only

• hosts: all roles:
  • cve_2026_31431

Example 2: Module blacklist only

• hosts: all vars: apply_remediation: true mitigation_flags: 1 roles:
  • cve_2026_31431

Example 3: Recommended (Blacklist + SELinux)

• hosts: all vars: apply_remediation: true mitigation_flags: 3 roles:
  • cve_2026_31431

4. Automatisierte Überwachung: ```bash

   Install Red Hat Security Advisories plugin for yum

   sudo yum install yum-plugin-security

   Check for security updates

   sudo yum updateinfo list security

   Check specifically for kernel updates

   sudo yum updateinfo list security kernel

   root@kitploit:~

Wonach suchen:

• RHSA (Red Hat Security Advisory) für den Kernel
• Advisory-Titel mit „CVE-2026-31431“
• Betroffene RHEL-Versionen, die zu Ihrer Umgebung passen

Beispielformat für ein Advisory:``` RHSA-2026:XXXX - Important: kernel security update Severity: Important CVEs: CVE-2026-31431 Affected Products: RHEL 7, 8, 9

Ubuntu

Primärquelle: Ubuntu Security Notices

• USN-Datenbank: https://ubuntu.com/security/notices
• CVE-Tracker: https://ubuntu.com/security/CVE-2026-31431

Benachrichtigungsmethoden:```bash

Subscribe to security announcements

Visit: https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce

Check for security updates

sudo apt update sudo apt list --upgradable | grep security

Ubuntu Security Notices tool

sudo apt install ubuntu-security-tools usn list --cve CVE-2026-31431

SUSE / openSUSE

Primärquelle: SUSE Security

• Sicherheitsupdates: https://www.suse.com/support/update/
• CVE-Datenbank: https://www.suse.com/security/cve/CVE-2026-31431.html

Benachrichtigungsmethoden:```bash

Check for security patches

sudo zypper list-patches --category security

Specific CVE check

sudo zypper info --cve CVE-2026-31431

Automatisiertes Patch-Überwachungsskript

Erstellen Sie ein Überwachungsskript für Ihre Umgebung:```bash #!/bin/bash

check-cve-2026-31431-patch.sh

Monitors for CVE-2026-31431 kernel patches

DISTRO=$(grep ^ID= /etc/os-release | cut -d= -f2 | tr -d '"')

case $DISTRO in rhel|centos|rocky|alma) yum updateinfo list security kernel 2>/dev/null | grep -i CVE-2026-31431 ;; fedora) dnf updateinfo list security kernel 2>/dev/null | grep -i CVE-2026-31431 ;; ubuntu|debian) apt-get update -qq apt-cache show linux-image-$(uname -r) | grep CVE-2026-31431 ;; sles|opensuse*) zypper info --cve CVE-2026-31431 kernel-default ;; esac

Check Red Hat Security Data API

curl -s "https://access.redhat.com/labs/securitydataapi/cve/CVE-2026-31431.json" |
jq -r '.affected_release[] | select(.package | startswith("kernel")) | "(.product_name): (.advisory) - (.package)"'

Was zu tun ist, wenn Patches veröffentlicht werden

1. Patch-Verfügbarkeit prüfen: ```bash

   Check your distribution's update mechanism

   sudo yum check-update kernel # RHEL/CentOS/Fedora sudo apt update && apt list --upgradable linux-image-* # Ubuntu/Debian

   root@kitploit:~

2. Versionshinweise prüfen:

   • Herstellerhinweis für Installationsanweisungen lesen
   • Auf bekannte Probleme oder Voraussetzungen prüfen
   • Kernel-Versionsnummern verifizieren

3. In einer Nicht-Produktionsumgebung testen: ```bash

   Apply kernel update to test systems first

   sudo yum update kernel # RHEL/CentOS/Fedora sudo apt upgrade linux-image-* # Ubuntu/Debian sudo reboot

   root@kitploit:~

4. Wirksamkeit des Patches überprüfen: ```bash

   After reboot, verify kernel version

   uname -r

   Run cfDr assessment to confirm patch

   ansible-playbook -i inventory quickstart.yml

   root@kitploit:~

5. Produktions-Rollout planen:

   • Wartungsfenster einplanen
   • Kernel-Updates stufenweise ausrollen
   • Dienstneustarts/Reboots einplanen

6. Temporäre Maßnahmen entfernen (optional): ```bash

   After patching, temporary mitigations can be removed

   However, defense-in-depth recommends keeping them

   If you choose to remove:

   sudo rm /etc/modprobe.d/blacklist-algif_aead-cve-2026-31431.conf sudo semodule -r cve_2026_31431_af_alg_deny # SELinux policy

   Remove seccomp drop-in files

   Update initramfs/initrd

   root@kitploit:~

Empfehlung: Auch nach dem Patchen des Kernels sollten Sie Defense-in-Depth-Maßnahmen beibehalten, um sich vor zukünftigen Schwachstellen zu schützen.

Unterstützung und Beiträge

Probleme melden

Einen Fehler gefunden oder eine Funktionsanfrage?

1. Bestehende Issues prüfen: https://github.com/parmstro/cfDr/issues
2. Neues Issue erstellen: Fügen Sie Folgendes hinzu:
   • cfDr-Version
   • Ansible-Version
   • Zielbetriebssystem und -version
   • Vollständige Fehlermeldungen
   • Schritte zur Reproduktion

Beitragen

Wir freuen uns über Beiträge! Siehe docs/CONTRIBUTORS.md für:

• Wie Sie Code beitragen können
• Verbesserungen der Dokumentation
• Tests und Fehlerberichte
• Funktionsvorschläge

Hilfe erhalten

• Issues: https://github.com/parmstro/cfDr/issues
• Diskussionen: https://github.com/parmstro/cfDr/discussions

Mitwirkende

cfDr basiert auf dem kollektiven Fachwissen von Sicherheitsexperten:

• Paul Armstrong (@parmstro) – Projektleitung, Modul-Blacklist & seccomp-Implementierungen
• Anthony Green (@atgreen) – eBPF-LSM-Mitigationsimplementierung
• Greg Procunier (@gprocunier) – SELinux-Policy-Mitigationsimplementierung
• Claude Sonnet 4.5 – Entwicklungsunterstützung, Dokumentation und Forschung

Siehe docs/CONTRIBUTORS.md für vollständige Beitragsdetails.

Lizenz

Dieses Projekt wird unter der MIT-Lizenz für Schwachstellenbewertungs- und Behebungszwecke bereitgestellt.

Siehe LICENSE für Details.

Haftungsausschluss

WICHTIG: Dieses Tool bietet temporäre Mitigationen, während auf vom Anbieter bereitgestellte Kernel-Patches gewartet wird. Diese Mitigationen reduzieren das Risiko erheblich, bieten jedoch möglicherweise nicht in allen Szenarien vollständigen Schutz.

cfDr wird "wie besehen" ohne Gewährleistung bereitgestellt. Beachten Sie immer:

• Testen Sie zuerst in einer Nicht-Produktionsumgebung
• Verstehen Sie die Schutzabdeckung und -lücken
• Überwachen Sie die Kanäle des Anbieters auf offizielle Patches
• Wenden Sie Anbieter-Patches an, sobald sie verfügbar sind
• Behalten Sie Defense-in-Depth auch nach dem Patchen bei

Die Mitwirkenden und Betreuer von cfDr sind nicht verantwortlich für Schäden oder Datenverluste, die durch die Verwendung dieses Tools entstehen.

Zuletzt aktualisiert: 2026-05-02T23:30:00Z