Fragnesia und Partner: Wenn Schwachstellen im Page-Cache immer wieder auftreten

Vor ein paar Wochen schrieb ich über Copy-Fail (CVE-2026-31431) und darüber, wie der Defense in Depth-Ansatz (Tiefenverteidigung) von Red Hat OpenShift ein Ausbrechen von Containern trotz eines anfälligen Kernels verhinderte. Ich verbrachte einige Zeit damit, aktiv aus einem OpenShift-Container auszubrechen, erlangte fast sofort Root-Rechte innerhalb des Pods und konnte dennoch nicht auf den Host entkommen. Die Kernel-Schwachstelle war real. Der Exploit-Pfad war real. Die Schutzmaßnahmen hielten stand. 

Während ich diesen Artikel abschloss, begann eine andere verwandte Variante, DirtyDecrypt (CVE-2026-31635), öffentlich zu zirkulieren – zusammen mit Diskussionen über Exploits und Berichten zum Proof of Concept. Zu diesem Zeitpunkt beobachteten wir 4 große Schwachstellen bei der Eskalation von Linux-Berechtigungen innerhalb von etwa 14 Tagen, die Variationen desselben umfassenden Musters nutzten.

Das ist der entscheidende Teil für mich.

Ab einem bestimmten Punkt betrachten Sie diese nicht mehr als isolierte CVEs, sondern erkennen ein systemisches Problem. Verschiedene Subsysteme. Verschiedene Exploit-Pfade. Das zugrunde liegende Konzept bleibt gleich: Manipulation des Copy-on-Write-Verhaltens im Kernel-Page-Cache, Beschädigung vermeintlich unveränderlicher Dateien und Eskalation von Berechtigungen.

Wenn Sie derzeit eine Produktionsinfrastruktur betreiben, ändert diese Erkenntnis die Diskussion sehr schnell. Die Verfolgung einzelner CVEs nacheinander fühlt sich weniger nach einer Sicherheitsstrategie an, sondern eher wie der Versuch, während einer Lawine Schneeflocken mit der Zunge zu fangen. Das Endergebnis ist nicht schön. 

Es kommt darauf an, ob Ihre Architektur resilient bleibt, wenn die nächste Variante unweigerlich auftaucht.

Denn zum jetzigen Zeitpunkt wird sie das wahrscheinlich tun.

Verschiedene CVEs, gleiches Muster

In den letzten 2 Wochen haben Forschende mehrere ähnliche Schwachstellen aufgedeckt: Copy-Fail zielt auf die allgemeine Manipulation des Page-Cache ab, Dirty Frag dringt in ESP/XFRM- und RxRPC-Pfade vor, Fragnesia konzentriert sich auf ESP-in-TCP, und nun taucht DirtyDecrypt öffentlich im Zusammenhang mit rxgk auf. Die Implementierungsdetails variieren, die allgemeine Philosophie der Ausnutzung bleibt jedoch bemerkenswert konsistent. Forschende finden eine konzeptionelle Schwachstelle in einem Bereich des Kernel-Netzwerkcodes und suchen anschließend in benachbarten Subsystemen nach ähnlichen Annahmen und fehlenden Sicherheitsvorkehrungen. Immer häufiger entdecken sie diese.

Dieses wiederkehrende Muster beunruhigt mich mehr als einzelne CVE-Nummern.

Ich startete einen ROSA-Cluster und entschied mich, Fragnesia direkt gegen OpenShift zu testen. Auf dem Cluster lief OpenShift 4.21.15 auf Red Hat Enterprise Linux (RHEL) CoreOS 9.6 mit einem anfälligen Kernel 5.14.0-570.113.1.el9_6.x86_64. Das anfällige Subsystem war vorhanden. Theoretisch hätte die Umgebung ausnutzbar sein müssen.

Ich wollte nicht einfach nur verstehen, ob der Kernel anfällig war. Das wussten wir bereits. Ich wollte sehen, an welcher Stelle die Exploit-Kette bei verschiedenen Sicherheitskonfigurationen tatsächlich unterbrochen wird.

Zuerst habe ich einen völlig standardmäßigen Pod mit standardmäßigen OpenShift-Schutzfunktionen bereitgestellt. Nichts Besonderes. Keine erweiterten Berechtigungen. Keine gelockerten SCCs. Lediglich ein einfacher Fedora-Container, in dem sleep infinity ausgeführt wird.

Die Exploit-Kette scheiterte fast sofort.

Die Erstellung von User Namespaces wurde blockiert, bevor der Angriff nennenswerte Fortschritte machen konnte. Das anfällige Subsystem war zwar weiterhin vorhanden, aber der Container verfügte nie über die erforderlichen Funktionen, um den gefährlichen Codepfad überhaupt zu erreichen. Die standardmäßigen Security Context Constraints (SCCs) von OpenShift in Kombination mit der SELinux-Erzwingung verhinderten den Angriff, noch bevor der Exploit wirklich aktiv werden konnte.

Dieser Teil war nicht überraschend.

Mehr interessierte mich das nächste Szenario – jene Art von Konfiguration, die viele Unternehmen tatsächlich nutzen.

Ich habe eine Workload mit der SCC anyuid erstellt und den Container explizit mit der User-ID (UID) 0 ausgeführt. Dies kommt in Brownfield-Umgebungen sehr häufig vor – bestehende Umgebungen, in denen Legacy-Anwendungen nie nach dem Least Privilege-Prinzip konzipiert wurden und Unternehmen oft Kompromisse eingehen, weil „die App dies erfordert“.

Innerhalb des Pods hatte ich Root-Rechte.

Die Exploit-Kette scheiterte dennoch.

Selbst mit anyuid setzte SELinux die Einschränkungen der Domain container_t weiterhin durch und verhinderte so die für die weitere Eskalation erforderlichen Namespace-Operationen. Das ist der Punkt, den viele beim Modell von OpenShift oft übersehen: Die Sicherheitsschichten sind absichtlich überlappend konzipiert. Das Lockern einer Sicherheitsmaßnahme führt nicht automatisch dazu, dass die restliche Abgrenzung aufgehoben wird.

An diesem Punkt beschloss ich, nicht länger vernünftig vorzugehen.

Ich erstellte eine bewusst gefährliche Konfiguration mit privilegierter SCC, Root-Benutzer und unbeschränktem Seccomp. Dies ist so freizügig, wie man eine OpenShift-Workload realistischerweise konfigurieren kann, ohne den Host direkt zu übergeben.

Und schließlich kam Bewegung in die Sache.

User Namespaces funktionierten. unshare -U war erfolgreich. Die Exploit-Kette schritt nun auf eine Weise voran, die in den vorherigen Szenarien nicht möglich gewesen wäre. Bei vielen Kubernetes-Distributionen ist dies in etwa der Punkt, an dem aus „Sicherheitsforschung“ eine „Reaktion auf Vorfälle“ wird.

Doch der Exploit scheiterte dennoch.

Fragnesia erfordert nicht nur die Erstellung von Namespaces. Es erfordert ein erfolgreiches UID/GID-Mapping innerhalb des Namespaces, damit Angreifende die notwendigen Berechtigungen für den Zugriff auf die anfälligen Netzwerkpfade erhalten können.

Dieser letzte Schritt wurde jedoch blockiert.

Selbst mit privilegierter SCC, Root und uneingeschränktem Seccomp verweigerte SELinux weiterhin Schreibvorgänge in /proc/self/uid_map. Ohne erfolgreiches UID-Mapping brach die Eskalationskette zusammen. Ohne Namespace-Root-Berechtigungen war kein XFRM/ESP-Zugriff möglich. Ohne Subsystemzugriff kam es zu keiner Beschädigung des Page-Caches.

Der Kernel blieb durchweg anfällig, aber der Exploit schlug dennoch fehl. Diese Unterscheidung ist wichtig.

Die Tests haben mich in einer Überzeugung bestätigt, die ich schon lange vertrete: Eine gute Defense in Depth-Strategie bleibt besonders dann wertvoll, wenn etwas schiefgeht. Nicht nur dann, wenn die Konfiguration perfekt ist. Nicht nur, wenn sämtliche Workloads makellos sind, das Least Privilege-Prinzip gilt und Sicherheitsteams sämtliche Anforderungen erfüllt bekommen. Reale Umgebungen sind komplex. Sicherheitskontrollen weichen oft auf. Es existieren Legacy-Workloads. Operative Kompromisse kommen häufig vor.

Die Frage ist, ob die Architektur nach solchen Kompromissen immer noch Bestand hat.

In diesem Fall war das so.

Selbst nach der gleichzeitigen Schwächung mehrerer Sicherheitsebenen behandelte SELinux den Container weiterhin als grundlegend nicht vertrauenswürdig. Dies verhinderte den letzten Schritt der Rechteerweiterung, der für den Abschluss des Angriffs erforderlich war.

Das ist der Unterschied zwischen „Sicherheitsfunktionen“ und einer kohärenten Sicherheitsarchitektur. Diese umfassendere Architekturdiskussion ist wichtiger als die Fragnesia-CVE selbst. Die letzten Wochen haben gezeigt, dass die Entwicklung dieser Schwachstellenfamilie wahrscheinlich noch nicht abgeschlossen ist.

Die operative Frage, die sich Organisationen stellen müssen, lautet nicht mehr: „Haben wir CVE-2026-46300 gepatcht?“. Die eigentliche Frage ist: „Was passiert im Unternehmen, wenn am nächsten Dienstag CVE-2026-XXXXX erscheint und ein anderes Subsystem angreift, das bisher niemand beobachtet hat?“

Der Exploit entwickelt sich weiter. Die Signale hingegen nicht.

Seien wir ehrlich: An diesem Punkt fühlt sich das Szenario nicht mehr nur hypothetisch an.

An dieser Stelle erweist sich Red Hat Advanced Cluster Security for Kubernetes als deutlich wertvoller als eine rein CVE-orientierte Denkweise. Das Interessante an Red Hat Advanced Cluster Security in diesem Zusammenhang ist nicht die Kenntnis von Fragnesia im Speziellen. Vielmehr sind die Verhaltensmuster dieser Exploit-Ketten oft erkennbar, selbst wenn sich die genaue Schwachstelle ändert.

Es ist ungewöhnlich, wenn ein Webanwendungscontainer plötzlich User Namespaces erstellt. Ebenso ist es ungewöhnlich, wenn ein Anwendungs-Workload /bin/su ausführt. Diese Signale bleiben interessant, unabhängig davon, ob der Exploit Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt heißt oder welchen Namen Forschende nächste Woche erfinden.

Die CVE ändert sich, aber in diesen Fällen bleibt das Verhalten gleich.

Das ist wichtig, weil Offenlegungszyklen sich schneller verändern, als viele Unternehmen große Flotten realistisch patchen können, ohne die operative Stabilität zu gefährden. Architektur und Einblick in das Verhalten verschaffen Ihnen Zeit. Manchmal entscheidet diese Zeit darüber, ob Sie einen kontrollierten Plan zur Fehlerbehebung ausführen oder die nächsten 18 Stunden auf einer Incident Bridge festsitzen und sich fragen, welche Cluster betroffen sind.

Dasselbe gilt für den Betrieb auf Flottenebene.

Das Testen von 3 Pods in einer Testumgebung ist einfach. Richtlinienänderungen über Dutzende oder Hunderte von Clustern hinweg zu koordinieren, während Produktions-Workloads online bleiben, ist eine völlig andere Herausforderung. Hier wandelt Red Hat Advanced Cluster Management for Kubernetes reaktive Hektik in einen kontrollierten Rollout um. Anstatt jeden Cluster einzeln manuell zu prüfen, gefährliche Konfigurationen manuell zu identifizieren und Änderungen der Sicherheitslage manuell teamübergreifend zu koordinieren, legen Sie konsistente Richtlinien zentral fest und übertragen diese gleichzeitig auf alle Systeme.

Diese Unterscheidung wird besonders wichtig, wenn alle paar Tage neue Varianten auftauchen.

Auf meinem Red Hat OpenShift on AWS (ROSA) Cluster blieb der Kernel während der gesamten Testphase anfällig. Die anfälligen Subsysteme blieben vorhanden. Die Voraussetzungen für den Exploit waren technisch gesehen gegeben.

Die Angriffskette brach weiterhin zusammen, da mehrschichtige Kontrollen die Eskalation an mehreren Punkten unterbrachen.

Dann begann die öffentliche Verbreitung von DirtyDecrypt, während ich noch an diesem Artikel schrieb.

Dieselbe umfassende Philosophie bei der Ausnutzung. Ein anderes Subsystem. Die gleichen Verteidigungsmechanismen greifen bereits.

Das ist kein Glück. Das ist Architektur. Das ist Defense in Depth.

Mehr erfahren

• Wenn KI Fehler findet: Warum Defense in Depth schon immer die Antwort war
• OpenShift kostenlos testen
• Mehr über OpenShift Platform Plus erfahren