Dirty Frag legt neue Schwachstelle im Linux Kernel offen

Loading

Ein neuer Fehler im Linux Kernel sorgt für Unruhe. Die Schwachstelle trägt den Namen Dirty Frag und ermöglicht lokalen Angreifern eine Privilegieneskalation. Sie reiht sich in eine Serie ähnlicher Probleme ein, die zuletzt mit Copy Fail bekannt wurden. Die Bandbreite der begroffenen Systeme ist weitreichend und umfasst z.B. Managed Servers, Container Hosts, CI Umgebungen und Shared Systeme.

Dirty Frag kombiniert zwei Fehler in der Page Cache Verarbeitung. Einer betrifft den IPsec ESP und XFRM Pfad (CVE-2026-43284), der andere das RxRPC Subsystem (CVE-2026-43500). Beide führen zu einem Schreibzugriff im Page Cache, der Angreifern Root Rechte verschaffen kann. Die Lücke ist lokal ausnutzbar und erlaubt keine direkte Remote Ausführung.

Forscher Hyunwoo Kim beschreibt Dirty Frag als neue Klasse von Angriffen auf Kernelpfade, die gepufferte Daten verarbeiten. Der Ansatz ähnelt Dirty Pipe und Copy Fail, bleibt aber technisch eigenständig. Ein öffentliches Proof of Concept erhöht den Druck auf Linux Distributionen und Administratoren.

Besonders gefährdet sind Server mit vielen Nutzern, Container Hosts, CI Runner und Kubernetes Knoten. Canonical warnt zudem vor möglichen Container Escapes, auch wenn dafür noch kein Beispiel veröffentlicht wurde. Systeme mit untrusted Workloads sollten Dirty Frag als akute Bedrohung einstufen.

Die Lage bei den Distributionen ist unterschiedlich. AlmaLinux bietet bereits Patches an. Debian hat nur in Sid einen Fix. Ubuntu listet fast alle LTS Versionen als betroffen und arbeitet an Updates. Red Hat bestätigt Probleme in RHEL 8 bis 10 sowie OpenShift 4. Auch openSUSE und SUSE prüfen ihre Kernel.

Als Lösung gilt ein aktualisierter Kernel. Bis dahin empfehlen einige Anbieter das Blacklisting der Module esp4, esp6 und rxrpc. Diese Maßnahme ist jedoch riskant, da sie IPsec VPNs, AFS und andere Dienste beeinträchtigt. Wer solche Funktionen nutzt, sollte auf ein Kernel Update warten.

Admins sollten ihre Systeme zeitnah aktualisieren und betroffene Module nur deaktivieren, wenn sie sicher nicht benötigt werden. In Umgebungen mit Containern oder vielen Nutzern zählt Dirty Frag zu den derzeit wichtigsten Linux Sicherheitsproblemen.

7 Kommentare zu „Dirty Frag legt neue Schwachstelle im Linux Kernel offen“

  1. Jörg

    Hallo.
    Mal eine Frage zum besserem Verständniss. Hier und auch in anderen Beiträgen zur Sicherheit, wird fast immer von “lokalen Angreifern” geredet.
    Heißt das, das der Angreifer physichen Zugang zu meinem PC haben muß und der Angriff nicht von außen (z.B. per Internet) entstehen kann?

  2. MK

    Ja, genau darum geht es meistens. Wenn bei Sicherheitslücken wie der aktuellen Dirty Frag Lücke im Linux Kernel von einem „lokalen Angreifer“ gesprochen wird, bedeutet das in der Regel, dass der Angreifer bereits Zugriff auf das System braucht. Das z.B. via ein eigenes Benutzerkonto, eine laufende Schadsoftware, Shell-Zugriff via SSH oder irgendein Weg, bereits Code auf Deinem Rechner auszuführen. Das heißt nicht zwingend, dass jemand physisch vor Deinem PC sitzen muss.

  3. Jens

    @MK:
    Ein weiterer Grund für Read-Only-Root, meiner Meinung nach. Auch wenn viele sich dann eingeschränkt fühlen, weil sie nichts mehr verbasteln können.

  4. Jörg

    @ MK
    Vielen Dank für die Aufklärung.
    Das beruhigt mich erst mal ungemein. Da ich alleine wohne und somit, außer mir, niemand Zugriff auf meinen PC bzw. irgendwelche Konten hat, nehme ich in Zukunft, solche Infos zwar wahr, kann aber danach beruhigt schlafen. 🙂
    Denn der einzige “lokale Angreifer”, wäre dann ich und da wäre ich ja schön blöd, wenn ich mir selber schaden wollte. 😉
    Danke nochmals.

  5. AH

    @Mk+Jörg:

    Ich glaube ihr habe etwas aneinander vorbei geredet.

    “Lokaler Angreifer” kann auch jemand sein, der über’s Internet normalen Zugriff auf den Rechner hat (von der Google-KI):

    —–
    “Eingeschränkter Zugriff” bedeutet in diesem Fall, dass der Angreifer zwar Befehle auf dem System ausführen kann, aber nur mit den Rechten eines normalen, “unwichtigen” Nutzers.

    So kommt ein Angreifer über das Internet zu diesem ersten Zugriff:

    * Schwachstelle in einer Web-Anwendung: Ein Hacker findet eine Lücke in einer Website (z. B. ein fehlerhaftes Kontaktformular), über die er einen sogenannten Webshell hochladen kann. Damit kann er Befehle ausführen, hat aber nur die Rechte des Webservers (oft ein Nutzer wie www-data), der fast nichts am System ändern darf.

    * Gestohlene Zugangsdaten: Der Angreifer erbeutet (z. B. durch Phishing) die SSH-Login-Daten eines normalen Mitarbeiters. Er kann sich einloggen, sieht aber keine fremden Dateien und kann keine Programme installieren.

    * Andere Dienste: Lücken in Programmen, die Verbindungen von außen annehmen (wie Datenbanken oder Chat-Server), können ebenfalls als Sprungbrett dienen.
    —–

    Oder einfach nur jemand, dem man z. B. über Teamviewer selbst Zugriff gegeben hat. Vielleicht einem Service-Mitarbeiter, oder jemandem der vorgibt einer zu sein.

    Normalerweise hat so jemanden dann nur die normalen Nutzerrecht, kann also nur das machen, was man auch selbst ohne Passworteingabe machen kann (was ja schon eine ganze Menge ist, da man ja Zugriff auf alle seine Daten hat). Über die Lücke kann derjenige dann auch noch Rootrechte bekommen und dann alles machen.

    Z. B. kann der vermeintliche Servicemitarbeiter sich eine Hintertür einrichten, um Zugriff zu bekommen, wenn niemand dabei zusieht.

  6. Thomas

    Hallo,

    ich bin ein Linux-Privatanwender (ein Debian 12 und ein Ubuntu 24.04 LTS) mit Internetanbindung aber ohne lokalen Zugriff weiterer Personen.
    Trotz Suche auf verschiedensten IT-News-Seiten und Linux-Foren weiss ich nach wie vor nicht sicher, was ich tun muss oder kann. Ist es ausreichend die von den Distributionen bereitgestellten Aktualisierungen einzuspielen? Sollte ich die Geräte erst wieder ins Netz lassen wenn die Aktualisierungen verfügbar sind? Wo kann ich erfahren ob diese Aktualisierungen schon verfügbar sind?

    Über eine Antwort wäre ich sehr dankbar
    Vielen Dank und Viele Grüße
    Thomas

  7. AH

    @Thomas: Das hatte ich in dem Beitrag vor deinem beantwortet: Beide Lücken sind nur ausnutzbar, wenn jemand physischen Zugriff auf deinen Rechner hat, oder er bereits gehackt wurde.

    Hat niemand mit entsprechenden Ambitionen Zugriff und ist dein Rechner nicht gehackt, kannst du wie gewohnt online gehen.

    Wie einfach man copy fail testen kann, hatte ich übrigens zu dessen Blogbeitrag geschrieben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert