CrackArmor: AppArmor-Schwachstellen ermöglichen Root-Zugriff auf über 12 Millionen Linux-Systemen

Sicherheitsforscher der Qualys Threat Research Unit (TRU) haben neun Schwachstellen im Linux Security Module AppArmor aufgedeckt, die unter dem Namen „CrackArmor“ zusammengefasst werden. Nicht privilegierte lokale Nutzer können damit Kernel-Schutzmechanismen aushebeln, Root-Rechte erlangen und die Isolation von Containern aufheben. Laut einer Analyse von Qualys CyberSecurity Asset Management sind weltweit über 12,6 Millionen Linux-Instanzen in Unternehmensumgebungen betroffen – darunter Cloud-Plattformen, Kubernetes-Cluster und IoT-Systeme. Die Schwachstellen existieren seit 2017 und wurden im Rahmen eines koordinierten Offenlegungsverfahrens gemeinsam mit den betroffenen Distributionsanbietern bekannt gemacht.

Hintergrund: Was ist AppArmor und warum ist es relevant?

AppArmor ist ein Mandatory Access Control (MAC)-Framework, das seit Kernel-Version 2.6.36 aus dem Jahr 2010 im Mainline-Linux-Kernel enthalten ist. Anders als klassische Zugriffskontrollmodelle, die Rechte an Benutzerkonten knüpfen, bindet AppArmor Sicherheitsprofile direkt an einzelne Anwendungen. Jeder Prozess unterliegt damit einem definierten Regelwerk, das Dateizugriffe, Netzwerkoperationen und Systemaufrufe einschränkt.

Auf Ubuntu, Debian und SUSE ist AppArmor standardmäßig aktiviert und gilt als fundamentale Sicherheitskomponente. In modernen Infrastrukturen – insbesondere in Kubernetes-Umgebungen, Cloud-Deployments und Edge-Systemen – bildet es eine der zentralen Vertrauensgrenzen für Millionen von Endpunkten. Genau diese weite Verbreitung macht die nun entdeckten Schwachstellen so weitreichend: Wer AppArmor kompromittiert, hebelt gleichzeitig die Schutzmechanismen aller darauf aufbauenden Systeme aus.

Die betroffene Codebasis reicht zurück bis Kernel-Version 4.11 aus dem Jahr 2017. Alle Systeme, die seitdem kein entsprechendes Sicherheitsupdate erhalten haben, sind angreifbar – unabhängig von der genutzten Distribution.

Das Angriffsprinzip: Confused Deputy

Das grundlegende Problem hinter CrackArmor ist ein klassischer „Confused Deputy“-Fehler. Dieses Angriffsmuster beschreibt eine Situation, in der ein nicht privilegierter Akteur einen privilegierten Prozess dazu bringt, Aktionen in seinem Namen auszuführen – Aktionen, zu denen der Angreifer selbst keine Berechtigung hätte.

Im Fall von CrackArmor lassen sich vertrauenswürdige Systemwerkzeuge wie sudo oder der Mail-Transfer-Agent Postfix als Mittler missbrauchen. Über die Pseudodateien /sys/kernel/security/apparmor/.load, .replace und .remove können AppArmor-Profile geladen, ersetzt oder entfernt werden – Operationen, die eigentlich Administratorrechte erfordern. Durch den Umweg über privilegierte Prozesse gelingt dies jedoch auch ohne entsprechende Berechtigungen.

Eine Analogie: Ein Angreifer überredet den Hausmeister eines Gebäudes – der einen Generalschlüssel besitzt –, gesperrte Tresore zu öffnen, zu denen der Angreifer selbst keinen Zugang hat. Der Hausmeister handelt dabei im guten Glauben, während er tatsächlich für fremde Zwecke instrumentalisiert wird.

Qualys betont ausdrücklich: Es handelt sich um einen implementierungsspezifischen Fehler im Kernel-Modulcode, nicht um einen konzeptionellen Mangel des MAC-Modells selbst. AppArmor als Sicherheitskonzept ist damit nicht grundsätzlich in Frage gestellt – wohl aber der konkrete Code, der Profile verarbeitet.

Technische Angriffsvektoren im Überblick

CrackArmor ermöglicht vier Arten von Angriffen:

• Schutzprofile manipulieren: Ohne Administratorrechte lassen sich AppArmor-Profile laden, ersetzen oder entfernen – um den Schutz von Diensten aufzuheben oder gezielt den SSH-Zugriff zu blockieren.
• System zum Absturz bringen: Speziell konstruierte, tief verschachtelte Profile bringen den Kernel-Stack zum Überlaufen und lösen einen Systemabsturz aus – ausführbar von jedem lokalen Nutzer.
• Root-Rechte erlangen: Über zwei unabhängige Wege – einen im User-Space via sudo und Postfix, einen weiteren direkt im Kernel – lassen sich vollständige Root-Rechte erlagen.
• Container-Isolation aufheben: Durch das Laden eines bestimmten Profils können nicht privilegierte Nutzer Benutzernamespaces erstellen und damit Schutzmechanismen in Ubuntu und Kubernetes-Umgebungen umgehen.

Betroffene Versionen und Distributionen

Betroffen sind alle Linux-Kernel ab Version 4.11, auf denen AppArmor aktiv ist. Im Einzelnen:

• Ubuntu (alle gängigen Releases mit AppArmor-Unterstützung)
• Debian und dessen Derivate
• SUSE Linux Enterprise sowie openSUSE
• Weitere Distributionen mit integriertem AppArmor
• Cloud-Instanzen, Kubernetes-Knoten und Edge-Deployments auf Basis dieser Distributionen

Für eine vollständige Liste anfälliger Versionen und verfügbarer Patches verweist Qualys auf die jeweiligen Sicherheitshinweise der Distributionsanbieter. Zusätzlich stehen auf der Qualys-Plattform QIDs zur Verfügung, mit denen betroffene Systeme in der eigenen Infrastruktur identifiziert werden können.

CVE-Status: Zum Zeitpunkt der Erstveröffentlichung lagen noch keine CVE-Kennungen vor, da diese vom Upstream-Kernel-Team in der Regel erst ein bis zwei Wochen nach Integration eines Fixes in eine stabile Kernel-Version vergeben werden. Inzwischen wurden zwei IDs zugewiesen: CVE-2026-23268 und CVE-2026-23269 (Stand: 19. März 2026). Für die übrigen Schwachstellen steht die Zuweisung noch aus.

Qualys weist ausdrücklich darauf hin, dass das Fehlen einer CVE-Kennung kein Maßstab für die Dringlichkeit eines Updates sein sollte. In der Praxis dienen CVE-IDs vielen Unternehmen als primäres Koordinationssignal für Patch-Entscheidungen – eine Abhängigkeit, die in diesem Fall zu einer Verzögerung notwendiger Updates führen könnte.

Exploit-Status und koordinierte Offenlegung

Qualys hat im Rahmen des Offenlegungsprozesses funktionierende Proof-of-Concept-Exploits entwickelt, die die vollständige Angriffskette für CrackArmor demonstrieren. Diese wurden dem Sicherheitsteam zur Verfügung gestellt, um schnelle Abhilfemaßnahmen zu ermöglichen.

Eine öffentliche Veröffentlichung des Exploit-Codes erfolgt vorerst nicht, um die Bereitstellung von Patches nicht zu gefährden und das Risiko für ungepatchte Systeme zu minimieren. Die technischen Details der Schwachstellen sind jedoch so beschrieben, dass eine unabhängige Validierung durch die Sicherheitscommunity möglich ist.

Der gesamte Koordinationsprozess erstreckte sich über mehrere Monate und umfasste mehrere Runden der Patch-Prüfung sowie Abstimmungen mit den Sicherheitsteams von Ubuntu, Debian und SUSE, den AppArmor-Entwicklern bei Canonical sowie dem Sudo-Maintainer. Die vollständigen technischen Details sind unter qualys.com/2026/03/10/crack-armor.txt abrufbar.

Empfohlene Sofortmaßnahmen

• Patchen: Sicherheitsupdates der jeweiligen Distributionsanbieter für AppArmor-Komponenten umgehend auf allen betroffenen Systemen einspielen – dies gilt als einzige zuverlässige Abhilfemaßnahme
• Scannen: Mittels Qualys QID 45097 („Linux Kernel Version Running“) und weiterer verfügbarer QIDs internetexponierte Assets sowie Container- und Kubernetes-Knoten mit ungepatchten Kerneln identifizieren und priorisieren
• Überwachen: Unerwartete Änderungen unter /sys/kernel/security/apparmor/ kontinuierlich auf mögliche Ausnutzungsversuche prüfen
• Container-Umgebungen prüfen: In Kubernetes-Clustern laufende Container auf mögliche Ausbrüche untersuchen und den Qualys Admission Controller nutzen, um neue Container vor der Bereitstellung auf Schwachstellen zu prüfen
• Asset-Inventar aktualisieren: Alle Linux-Endpunkte mit aktiviertem AppArmor erfassen und den Patch-Status zentral nachverfolgen

Vorübergehende Kompensationsmaßnahmen – etwa das manuelle Deaktivieren von AppArmor – bieten laut Qualys kein vergleichbares Schutzniveau wie ein vollständig eingespielter Kernel-Patch und sollten nur als kurzfristige Übergangslösung betrachtet werden.

Grafik Quelle: Qualys

Grafik Quelle: Qualys

Einordnung

CrackArmor zeigt, dass Sicherheitsmodule, die als verlässliche Grundlage für Container-Isolation, Rechteverwaltung und Systemhärtung gelten, selbst Angriffsflächen darstellen können. Da AppArmor in vielen Unternehmensinfrastrukturen als vertrauenswürdige Schutzbasis gilt und häufig als gegeben vorausgesetzt wird, ohne regelmäßig auf seinen Patch-Stand geprüft zu werden, offenbart dieser Fall eine strukturelle Schwäche im Umgang mit Standardkonfigurationen.

Besonders relevant ist die Kombination aus niedriger Angriffshürde – ein einfaches lokales Konto ohne Sonderrechte reicht aus – und weitreichenden Folgen: Root-Zugriff, Systemabstürze, Container-Ausbrüche und KASLR-Umgehung können durch dieselbe Schwachstellenklasse ermöglicht werden. Das unterstreicht, dass Patch-Management für Kernel-Komponenten denselben Stellenwert erhalten sollte wie das Patchen von Anwendungssoftware oder Netzwerkdiensten.

„Die in diesem Beitrag veröffentlichten Informationen wurden sorgfältig recherchiert. Dennoch übernehmen wir keine Gewähr für Vollständigkeit oder absolute Richtigkeit. Die Inhalte dienen der allgemeinen Orientierung und ersetzen keine fachkundige Beratung. Für etwaige Fehler, Auslassungen oder Folgen aus der Nutzung der Informationen übernimmt die Redaktion keine Haftung. Trotz sorgfältiger Prüfung können vereinzelt unbeabsichtigte Fehler oder Ungenauigkeiten, etwa bei Übersetzungen, auftreten.“

Mehr Lesestoff:

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky

Folgen Sie uns auf Mastodon

Hamsterrad Rebell – Cyber Talk