CrackArmor Linux Vulnerabilty

Da AppArmor die Containerisolierung und die Durchsetzung des Prinzips der geringsten Privilegien in diesen Umgebungen untermauert, gefährdet eine funktionierende Umgehung nicht nur einen einzelnen Prozess – sie bricht die Vertrauensgrenze für jede davon abhängige Workload zusammen.

Der verwirrte Stellvertreter: So funktioniert der Angriff

AppArmor stellt unter /sys/kernel/security/apparmor/ eine Reihe von Pseudodateien bereit – darunter .load, .replace und .remove –, über die Profile verwaltet werden. Diese Schnittstellen sollen nur privilegierten Administratoren zugänglich sein. Sobald die Profil-Schnittstelle für einen Angreifer beschreibbar ist, eröffnen sich mehrere unterschiedliche Ausnutzungswege:

• Umgehung der Richtlinien: Ein Angreifer kann ein „Deny-All“-Profil für einen kritischen Dienst wie sshd laden und so sofort jeden legitimen Fernzugriff blockieren. Alternativ führt das Entfernen des Profils für einen Daemon wie rsyslogd oder cupsd dazu, dass die Schutzmaßnahmen, die diese Prozesse zuvor umgaben, aufgehoben werden.
• Denial-of-Service durch Stack-Erschöpfung: Die rekursive Routine von AppArmor zum Entfernen von Profilen kann dazu gebracht werden, den Kernel-Stack – etwa 16 KB auf x86-64 – zu erschöpfen, indem die Entfernung einer tief verschachtelten Unterprofilhierarchie ausgelöst wird. Auf Systemen mit CONFIG_VMAP_STACK-Guard-Seiten führt der Überlauf zu einem Kernel-Panic und erzwingt einen Neustart.
• Lokale Privilegienerweiterung auf Root – Benutzerbereich: Durch das Laden eines Profils, das die CAP_SETUID-Fähigkeit von Sudo blockiert, und die Manipulation der Umgebungsvariable MAIL_CONFIG veranlasst ein Angreifer Sudo, die Postfix-Binärdatei sendmail als Root aufzurufen, wodurch er eine Root-Shell erhält.
• Lokale Rechteausweitung auf root – Kernel-Bereich: Eine Use-after-free-Schwachstelle in der Funktion aa_loaddata ermöglicht es einem Angreifer, eine freigegebene Speicherseite als Seitentabelleneintrag neu zuzuweisen, der auf /etc/passwd verweist, den Passwort-Hash des root-Kontos zu überschreiben und über su vollständigen Root-Zugriff zu erlangen.
• Ausbruch aus Container und Namespace: Durch das Laden eines User-Namespace-Profils für /usr/bin/time kann ein nicht privilegierter Benutzer auf Ubuntu-Systemen, auf denen die Erstellung solcher Namespaces zuvor eingeschränkt war, voll funktionsfähige User-Namespaces erstellen – und damit eine Schutzmaßnahme umgehen, die viele Organisationen als Sicherheitskontrolle für Container betrachten.
• KASLR-Offenlegung: Lesezugriffe außerhalb des zulässigen Bereichs beim Parsen von Profilen legen Kernel-Speicheradressen offen, wodurch der Offset der Kernel Address Space Layout Randomisation (KASLR) preisgegeben wird und weitere Ausnutzungsschritte ermöglicht werden, für die andernfalls zunächst diese Schutzmaßnahme umgangen werden müsste.

Ein weiteres strukturelles Problem verstärkt das Risiko: Die Initialisierungs- und Dienstlogik von AppArmor selbst kann Profile während Paket-Upgrades oder Dienstneustarts entladen, wodurch Prozesse uneingeschränkt weiterlaufen – ohne Warnung an die Administratoren –, bis die Profile neu geladen werden.

Umfang und betroffene Systeme

Alle Linux-Kernel ab Version 4.11 sind auf jeder Distribution betroffen, die AppArmor integriert. Die Schwachstelle besteht daher seit etwa neun Jahren. Zu den betroffenen Distributionen gehören Ubuntu, Debian, SUSE und deren Derivate.

Zum Zeitpunkt der Veröffentlichung wurden noch keine CVE-Kennungen vergeben. Das Fehlen einer CVE-Kennung sollte nicht als Hinweis auf eine geringere Schweregrad interpretiert werden.

Behebung und Erkennung

Ein Kernel-Patch ist die einzige vollständige Abhilfe. Vorläufige Abhilfemaßnahmen stellen die Sicherheitsgarantien, die die Profildurchsetzung von AppArmor bieten soll, nicht wieder her. Distributionsanbieter haben aktualisierte Kernel-Pakete veröffentlicht; Administratoren sollten die Sicherheitshinweise ihrer Distribution konsultieren, um die spezifischen Paketversionen zu ermitteln, die die Korrekturen enthalten.

Parallel zur Patch-Bereitstellung werden drei operative Schritte empfohlen. Erstens: Erfassen Sie alle Linux-Endpunkte, auf denen AppArmor läuft – einschließlich Cloud-Instanzen, Container-Hosts und Kubernetes-Knoten –, um den Umfang der Gefährdung vor der Bereitstellung der Patches zu ermitteln. Zweitens: Implementieren Sie eine Überwachung der Dateiintegrität oder Audit-Überwachung unter /sys/kernel/security/apparmor/, um unbefugte Profiländerungen zu erkennen, die auf eine aktive Ausnutzung hindeuten könnten. Drittens sollte überprüft werden, ob AppArmor-Profile nach System-Upgrades korrekt neu geladen werden; Prozesse, die nach einer Paketaktualisierung nicht mehr eingeschränkt sind, stellen selbst ohne aktive Ausnutzung eine unbeabsichtigte Sicherheitslücke dar.

Because AppArmor underpins container isolation and least-privilege enforcement across those environments, a working bypass does not merely compromise a single process — it collapses the trust boundary for every workload depending on it.

The Confused Deputy: How the Attack Works

AppArmor exposes a set of pseudo-files under /sys/kernel/security/apparmor/ — including .load, .replace, and .remove — through which profiles are managed. These interfaces are intended to be accessible only to privileged administrators. Once the profile interface is writable by an attacker, several distinct exploitation paths open:

• Policy bypass: An attacker can load a deny-all profile for a critical service such as sshd, immediately blocking all legitimate remote access. Alternatively, removing the profile for a daemon like rsyslogd or cupsd strips away protections that previously contained those processes.
• Denial of service via stack exhaustion: AppArmor’s recursive profile-removal routine can be driven to exhaust the kernel stack — approximately 16 KB on x86-64 — by triggering removal of a deeply nested subprofile hierarchy. On systems with CONFIG_VMAP_STACK guard pages, the overflow produces a kernel panic and forces a reboot.
• Local privilege escalation to root — user space: By loading a profile that blocks Sudo’s CAP_SETUID capability and manipulating the MAIL_CONFIG environment variable, an attacker causes Sudo to invoke Postfix’s sendmail binary as root, obtaining a root shell.
• Local privilege escalation to root — kernel space: A use-after-free vulnerability in the aa_loaddata function allows an attacker to reallocate a freed memory page as a page table entry pointing to /etc/passwd, overwrite the root account’s password hash, and gain full root access via su.
• Container and namespace breakout: By loading a user-namespace profile for /usr/bin/time, an unprivileged user can create fully capable user namespaces on Ubuntu systems where such namespace creation was previously restricted — bypassing a mitigation that many organisations treat as a container security control.
• KASLR disclosure: Out-of-bounds reads in profile parsing expose kernel memory addresses, leaking the Kernel Address Space Layout Randomisation offset and enabling further exploitation steps that would otherwise require defeating that protection first.

A further structural concern compounds the risk: AppArmor’s own initialisation and service logic can unload profiles during package upgrades or service restarts, leaving processes running unconfined — with no alert to administrators — until profiles are reloaded.

Scope and Affected Systems

All Linux kernels from version 4.11 onward are affected on any distribution that integrates AppArmor. The flaw has therefore been present for approximately nine years. Affected distributions include Ubuntu, Debian, SUSE, and their derivatives.

No CVE identifiers have been assigned at the time of publication. The absence of a CVE should not be interpreted as an indication of lower severity.

Remediation and Detection

Kernel patching is the only complete remediation. Interim mitigations do not restore the security guarantees that AppArmor’s profile enforcement is intended to provide. Distribution vendors have released updated kernel packages; administrators should consult their distribution’s security advisories for the specific package versions that include the fixes.

Three operational steps are recommended in parallel with patch deployment. First, inventory all Linux endpoints running AppArmor — including cloud instances, container hosts, and Kubernetes nodes — to establish the scope of exposure before patches are deployed. Second, implement file-integrity or audit monitoring on /sys/kernel/security/apparmor/ to detect unauthorised profile modifications that may indicate active exploitation. Third, review whether AppArmor profiles are being correctly reloaded after system upgrades; processes left unconfined after a package update represent an unintended exposure even absent active exploitation.