{"id":38197,"date":"2026-05-19T12:09:33","date_gmt":"2026-05-19T10:09:33","guid":{"rendered":"https:\/\/enginsight.com\/?p=38197"},"modified":"2026-05-19T12:56:01","modified_gmt":"2026-05-19T10:56:01","slug":"cve-2026-43284-dirty-frag-universelle-linux-rechteausweitung-teil-2","status":"publish","type":"post","link":"https:\/\/enginsight.com\/de\/blog\/cve-2026-43284-dirty-frag-universelle-linux-rechteausweitung-teil-2\/","title":{"rendered":"CVE-2026-43284 Dirty Frag &#8211; Universelle Linux-Rechteausweitung Teil 2"},"content":{"rendered":"<p>Sicherheitsforscher Hyunwoo Kim hat am 8. Mai 2026 eine Schwachstelle namens <strong>Dirty Frag<\/strong> ver&#xF6;ffentlicht, die es erm&#xF6;glicht, Root-Rechte auf allen g&#xE4;ngigen Linux-Distributionen zu erlangen. Dieser ist ein Nachfolger von <strong>Copy Fail<\/strong> (CVE-2026-31431, CVSS 7.8), einer k&#xFC;rzlich bekannt gewordenen LPE-Schwachstelle im Linux-Kernel.<\/p>\n\n\n\n<p>Es gibt mittlerweile einen Patch f&#xFC;r Dirty Frag. Den aktuellen Status dazu findet man unter <a href=\"https:\/\/cve.enginsight.com\/2026\/43284\/index.html\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/cve.enginsight.com\/2026\/43284\/index.html<\/a> oder bei den jeweiligen Distributionen (u.a. Debian: <a href=\"https:\/\/security-tracker.debian.org\/tracker\/CVE-2026-43284\" target=\"_blank\" rel=\"noopener\">https:\/\/security-tracker.debian.org\/tracker\/CVE-2026-43284<\/a>).<\/p>\n\n\n\n<p>Es ist au&#xDF;erdem m&#xF6;glich die betroffenen Module, in denen die Sicherheitsl&#xFC;cken aufreten, zu deaktivieren:<\/p>\n\n\n\n<div style=\"background:#FFFFFF;border:1px solid #E2E2E2;border-radius:8px;overflow:hidden;font-family:'Fira Code','Source Code Pro',Consolas,Monaco,monospace;font-size:14px;line-height:1.6;max-width:100%;margin:1.5em 0;\">\n<div style=\"background:#F6F6F6;color:#6B7280;font-size:12px;padding:8px 16px;border-bottom:2px solid #E91E8C;\">Code<\/div>\n<div style=\"overflow-x:auto;padding:12px 16px;color:#24292E;white-space:pre;\">sh <span style=\"color:#0E7490\">&#x2013;<\/span>c <span style=\"color:#22863A\">&bdquo;printf &sbquo;install esp4 \/bin\/false\\ninstall esp6 \/bin\/false\\ninstall rxrpc \/bin\/false\\n&lsquo; &gt; \/etc\/modprobe.d\/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2&gt;\/dev\/null; true&ldquo;<\/span><\/div>\n<\/div>\n\n\n\n<p><strong>Nachteil<\/strong>:<br>IPsec und der kAFS-Treiber (Kernel-AFS-Dateisystem) funktionieren danach nicht mehr. Das beeintr&#xE4;chtigt IPsec basierte Tunnel sowie kAFS basierte Netzlaufwerke.<\/p>\n\n\n\n<p><strong>Quellen:<\/strong><\/p>\n\n\n\n<p><a href=\"https:\/\/www.openwall.com\/lists\/oss-security\/2026\/05\/07\/8\" target=\"_blank\" rel=\"noopener\">https:\/\/www.openwall.com\/lists\/oss-security\/2026\/05\/07\/8<\/a><\/p>\n\n\n\n<p><a href=\"https:\/\/moselwal.com\/blog\/linux-kernel-dirty-frag-lpe-mitigation\" target=\"_blank\" rel=\"noopener\">https:\/\/moselwal.com\/blog\/linux-kernel-dirty-frag-lpe-mitigation<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"Wie-funktioniert-der-Angriff\">Wie funktioniert der Angriff<\/h2>\n\n\n\n<p><strong>Dirty Frag<\/strong> nutzt einen Fehler in der Art, wie der Linux-Kernel verschl&#xFC;sselte Netzwerkpakete verarbeitet. Normalerweise kopiert der Kernel empfangene Daten vor der Entschl&#xFC;sselung in einen eigenen, privaten Speicherbereich. In einem Performance-Optimierungspfad der Subsysteme IPsec (esp4\/esp6) und RxRPC pr&#xFC;ft er jedoch nicht, ob die betreffende Speicherseite wirklich ihm allein geh&#xF6;rt sondern entschl&#xFC;sselt direkt in-place.<\/p>\n\n\n\n<p>Ein Angreifer nutzt das aus, indem er &#xFC;ber den Systemaufruf <code>splice()<\/code> eine Speicherseite, die er &#xFC;ber eine Pipe kontrolliert, in den Netzwerkstack einschleust, so dass der Kernel sie als Empfangspuffer verwendet. Da der Angreifer das verschl&#xFC;sselte Paket selbst konstruiert, bestimmt er auch, was der Kernel beim Entschl&#xFC;sseln in diese Seite schreibt. Somit erh&#xE4;lt er damit einen kontrollierten Schreibzugriff auf den Kernel-Speicher.<\/p>\n\n\n\n<p>Dieser Schreibzugriff ist zun&#xE4;chst auf 4 Bytes begrenzt. Durch viele gezielte 4-Byte-Writes &#xFC;berschreibt der Angreifer schrittweise den Inhalt einer privilegierten Bin&#xE4;rdatei wie <code>sudo<\/code> im Kernel-Speicher (Page Cache), ohne jemals Root-Rechte gehabt zu haben. Beim n&#xE4;chsten Aufruf dieser Datei f&#xFC;hrt das System den eingeschleusten Code mit Root-Rechten aus.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"Vergleich-Dirty-Frag-und-CopyFail\">Vergleich Dirty Frag und CopyFail<\/h2>\n\n\n\n<p>Sowohl CopyFail als auch Dirty Frag geh&#xF6;ren zur gleichen Fehlerkategorie und funktionieren nach demselben Grundprinzip. Dabei wird eine Speicherseite, die einem unprivilegierten Prozess geh&#xF6;rt, durch einen Kernel-Subsystem-Fehler mit kontrollierten Daten &#xFC;berschrieben, wodurch sich Root Rechte erlangen lassen.<\/p>\n\n\n\n<p>Der Unterschied liegt dabei im Eintrittspunkt. Copy Fail nutzt das Modul <code>algif_aead<\/code> (mehr Infos unter <a href=\"https:\/\/enginsight.com\/de\/blog\/copyfail-cve-2026-31431-funktionsweise-erkennung-und-schutzmassnahmen-fuer-linux-systeme\/\">https:\/\/enginsight.com\/de\/blog\/copyfail-cve-2026-31431-funktionsweise-erkennung-und-schutzmassnahmen-fuer-linux-systeme\/<\/a>), wohingegen Dirty Frag gleich zwei andere Eintrittspunkte nutzt. Die IPsec-Subsysteme <code>esp4<\/code>\/<code>esp6<\/code> sowie <code>rxrpc<\/code> aus dem RxRPC-Netzwerkstack. Das macht Dirty Frag breiter aufgestellt und erkl&#xE4;rt, warum die Gegenma&#xDF;nahme gegen Copy Fail (Blacklisting von <code>algif_aead<\/code>) hier wirkungslos ist.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"Erkennung-&#xFC;ber-Enginsight\">Erkennung &#xFC;ber Enginsight<\/h2>\n\n\n\n<p>Die Sicherheitsl&#xFC;cke kann &#xFC;ber Enginsight zuverl&#xE4;ssig erkannt werden:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Der Pulsar erkennt betroffene Systeme direkt &#xFC;ber die ausgelesene Kernelversion.<\/li>\n\n\n\n<li>Dabei wird die CVE solange als vorhanden erkannt, bis:<ol start=\"1\"><li>der Sicherheits-Patch installiert wurde und<\/li><li>das System vollst&#xE4;ndig neu gestartet wurde, sodass der aktualisierte Kernel aktiv l&#xE4;uft.<\/li><\/ol>Zus&#xE4;tzlich wird die Schwachstelle auch erkannt &#xFC;ber:<\/li>\n\n\n\n<li>den Observer bei &#xF6;ffentlich erreichbaren Websystemen,<\/li>\n\n\n\n<li>sowie &#xFC;ber den Hacktor im Rahmen von einem Pentest auf Systemen, auf die kein direkter Zugriff m&#xF6;glich ist.<\/li>\n<\/ul>\n\n\n\n<p>Dadurch k&#xF6;nnen auch externe oder eingeschr&#xE4;nkt verwaltbare Systeme identifiziert werden.<\/p>\n\n\n\n<p><strong>Hinweis:<\/strong> Bitte beachten Sie, dass Sie bei einem Remote-Scan (wie Hacktor und Observer) ohne Authentifizierung meist nur eine Sch&#xE4;tzung erhalten, da exakte Kernel-Versionen oft absichtlich verborgen werden. Bei kritischen Systemen empfehlen wir daher zus&#xE4;tzlich eine manuelle Kontrolle.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img fetchpriority=\"high\" decoding=\"async\" width=\"1024\" height=\"200\" src=\"https:\/\/enginsight.com\/wp-content\/uploads\/grafik-3-1024x200.png\" alt=\"\" class=\"wp-image-38198\" srcset=\"https:\/\/enginsight.com\/wp-content\/uploads\/grafik-3-1024x200.png 1024w, https:\/\/enginsight.com\/wp-content\/uploads\/grafik-3-300x58.png 300w, https:\/\/enginsight.com\/wp-content\/uploads\/grafik-3-768x150.png 768w, https:\/\/enginsight.com\/wp-content\/uploads\/grafik-3-1536x299.png 1536w, https:\/\/enginsight.com\/wp-content\/uploads\/grafik-3.png 1611w\" sizes=\"(max-width: 1024px) 100vw, 1024px\"\/><\/figure>\n","protected":false},"excerpt":{"rendered":"<p>Sicherheitsforscher Hyunwoo Kim hat am 8. Mai 2026 eine Schwachstelle namens Dirty Frag ver&#xF6;ffentlicht, die es erm&#xF6;glicht, Root-Rechte auf allen g&#xE4;ngigen Linux-Distributionen zu erlangen. Dieser ist ein Nachfolger von Copy Fail (CVE-2026-31431, CVSS 7.8), einer k&#xFC;rzlich bekannt gewordenen LPE-Schwachstelle im Linux-Kernel. Es gibt mittlerweile einen Patch f&#xFC;r Dirty Frag. Den aktuellen Status dazu findet man [&#x2026;]<\/p>\n","protected":false},"author":36,"featured_media":38199,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","_eb_attr":"","footnotes":""},"categories":[334],"tags":[],"class_list":["post-38197","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-schwachstellen"],"_links":{"self":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/38197","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/users\/36"}],"replies":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/comments?post=38197"}],"version-history":[{"count":2,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/38197\/revisions"}],"predecessor-version":[{"id":38205,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/38197\/revisions\/38205"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/media\/38199"}],"wp:attachment":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/media?parent=38197"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/categories?post=38197"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/tags?post=38197"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}