CrackArmor: Investigating and Fixing the AppArmor Vulnerability on Ubuntu

What is CrackArmor

AppArmor enforces mandatory access control policies through kernel-level profiles. These profiles restrict what files a program can access, what capabilities it can use, and what network operations it can perform. The security of the entire system depends on the integrity of these profiles. CrackArmor exploits a fundamental design flaw: the pseudo-files used to manage profiles (.load, .replace, and .remove under /sys/kernel/security/apparmor/) are world-writable by default. Any local user with shell access can write to these files and manipulate the security policies protecting the system.

The Attack Chain

The illustration above maps the complete CrackArmor attack surface. The primary entry point is a confused deputy exploit where an attacker redirects the stderr of a privileged program (running in su PTY mode) to the world-writable AppArmor pseudo-files. This gives the attacker three capabilities: loading a malicious profile that denies specific capabilities to privileged binaries, replacing existing profiles to weaken security constraints, or removing profiles entirely to disable all enforcement. The most dangerous path loads a profile that denies CAP_SETUID to Sudo, which triggers Sudo’s error-handling mechanism. Sudo attempts to send a failure notification through Postfix’s sendmail, and because the attacker controls environment variables, Postfix executes arbitrary commands as root.

Confused Deputy: The Core Vulnerability

The confused deputy problem is the foundation of every CrackArmor attack. The three pseudo-files under /sys/kernel/security/apparmor/ are created with permissions -rw-rw-rw- (666), meaning any user on the system can write to them. These files are the kernel’s interface for loading, replacing, and removing AppArmor profiles. When a privileged program writes to these files on behalf of the attacker (the confused deputy), the kernel processes the data as a legitimate profile operation.

Kernel-Space Vulnerabilities

Beyond the confused deputy problem, CrackArmor includes four kernel-space bugs that become exploitable once an attacker can manipulate profiles.

• Uncontrolled Recursion: Deeply nested profile hierarchies exhaust the kernel stack through recursive calls in __remove_profile(), causing a system crash via CONFIG_VMAP_STACK guard page violation. This is a denial-of-service only, no privilege escalation.
• Out-of-Bounds Read: The match_char() macro increments a string pointer multiple times unsafely, allowing an attacker to read up to 64KB of kernel memory including KASLR-randomized pointers. Confirmed on Ubuntu 24.04.3 and Debian 13.1.
• Use-After-Free: A race condition in file-open operations involving aa_loaddata structures in the kmalloc-192 slab cache. Exploitable despite CONFIG_RANDOM_KMALLOC_CACHES, this achieves local privilege escalation to root through page-table manipulation. Extremely reliable on Ubuntu 24.04.3.
• Double-Free: The ns_name pointer is freed twice in aa_replace_profiles(), affecting kmalloc-8 through kmalloc-256 caches. Exploitable on Debian 13.1 despite CONFIG_SLAB_BUCKETS, enabling privilege escalation via AF_PACKET page vectors and credential structure manipulation.

Affected Systems

CrackArmor affects any Linux distribution that ships AppArmor with world-writable pseudo-files. The confirmed affected versions are:

• Ubuntu 24.04.3 LTS and earlier releases using AppArmor (including 22.04 LTS)
• Debian 13.1
• SUSE distributions shipping AppArmor

Systems running all three components (AppArmor, Sudo, and Postfix) are vulnerable to the complete root escalation chain. Systems without Postfix are still vulnerable to profile manipulation, denial-of-service, and the kernel-space exploits.

Investigating Your System

The following commands check whether your system is affected. Run each one and compare the output to determine your exposure level.

Check if AppArmor is Loaded

$ sudo aa-status

If AppArmor is loaded with profiles in enforce mode, your system uses AppArmor and may be affected. A system without AppArmor loaded is not vulnerable to CrackArmor.

apparmor module is loaded.

43 profiles are loaded.

43 profiles are in enforce mode.

Verify Pseudo-File Permissions

This is the critical check. If these files show -rw-rw-rw- (666), your system is vulnerable.

$ ls -la /sys/kernel/security/apparmor/.load /sys/kernel/security/apparmor/.replace /sys/kernel/security/apparmor/.remove

Vulnerable output looks like this:

-rw-rw-rw- 1 root root 0 Jan 27 07:54 /sys/kernel/security/apparmor/.load

-rw-rw-rw- 1 root root 0 Jan 27 07:54 /sys/kernel/security/apparmor/.remove

-rw-rw-rw- 1 root root 0 Jan 27 07:54 /sys/kernel/security/apparmor/.replace

Check for Sudo and Postfix

The full root escalation chain requires both Sudo and Postfix. Check if they are installed:

$ dpkg -l | grep -E ‘sudo|postfix’ | awk ‘{print $2, $3}’

postfix 3.6.4-1ubuntu1.3

sudo 1.9.9-1ubuntu2.4

If both are present alongside vulnerable AppArmor pseudo-files, your system is exposed to the complete escalation chain from unprivileged user to root.

Check Kernel and OS Version

$ uname -r && lsb_release -ds

5.15.0-164-generic

Ubuntu 22.04.5 LTS

List Active AppArmor Profiles

Review which profiles are currently enforcing. These are the profiles an attacker could replace or remove:

$ sudo aa-status –enforced

Remediation

The remediation flow above outlines four phases. Phase 1 detects the vulnerability by checking AppArmor status and pseudo-file permissions. Phase 2 applies the immediate fix by restricting permissions to root-only. Phase 3 ensures the fix survives reboots through a systemd oneshot service. Phase 4 addresses long-term hardening by monitoring for kernel patches, auditing local accounts, evaluating whether Postfix is needed, and restricting SSH access.

Immediate Fix: Restrict Pseudo-File Permissions

Change the permissions from 666 (world-writable) to 600 (root-only):

$ sudo chmod 600 /sys/kernel/security/apparmor/.load /sys/kernel/security/apparmor/.replace /sys/kernel/security/apparmor/.remove

Verify the change took effect:

$ ls -la /sys/kernel/security/apparmor/.load /sys/kernel/security/apparmor/.replace /sys/kernel/security/apparmor/.remove

-rw——- 1 root root 0 Jan 27 07:54 /sys/kernel/security/apparmor/.load

-rw——- 1 root root 0 Jan 27 07:54 /sys/kernel/security/apparmor/.remove

-rw——- 1 root root 0 Jan 27 07:54 /sys/kernel/security/apparmor/.replace

Confirm AppArmor is still fully operational after the permission change:

$ sudo aa-status | head -5

apparmor module is loaded.

43 profiles are loaded.

43 profiles are in enforce mode.

Persist the Fix Across Reboots

The pseudo-files under /sys/ are regenerated on every boot, so the chmod change reverts after a restart. Create a systemd oneshot service that re-applies the fix automatically after AppArmor loads:

# /etc/systemd/system/apparmor-harden.service
[Unit]

Description=Harden AppArmor pseudo-file permissions (CrackArmor mitigation)

After=apparmor.service

Requires=apparmor.service
[Service]

Type=oneshot

ExecStart=/bin/chmod 600 /sys/kernel/security/apparmor/.load /sys/kernel/security/apparmor/.replace /sys/kernel/security/apparmor/.remove

RemainAfterExit=yes
[Install]

WantedBy=multi-user.target

Create the file, reload systemd, and enable the service:

$ sudo tee /etc/systemd/system/apparmor-harden.service > /dev/null <<'EOF'
$ [Unit]
$ Description=Harden AppArmor pseudo-file permissions (CrackArmor mitigation)
$ After=apparmor.service
$ Requires=apparmor.service

$ [Service]
$ Type=oneshot
$ ExecStart=/bin/chmod 600 /sys/kernel/security/apparmor/.load /sys/kernel/security/apparmor/.replace /sys/kernel/security/apparmor/.remove
$ RemainAfterExit=yes

$ [Install]
$ WantedBy=multi-user.target
$ EOF
$ sudo systemctl daemon-reload
$ sudo systemctl enable apparmor-harden.service
$ sudo systemctl start apparmor-harden.service[/gsl_terminal]



$ Verify the service is active and enabled:


$ [gsl_terminal type="command"]sudo systemctl status apparmor-harden.service

● apparmor-harden.service – Harden AppArmor pseudo-file permissions (CrackArmor mitigation)

     Loaded: loaded (/etc/systemd/system/apparmor-harden.service; enabled; vendor preset: enabled)

     Active: active (exited)

    Process: 2084177 ExecStart=/bin/chmod 600 /sys/kernel/security/apparmor/.load

             /sys/kernel/security/apparmor/.replace /sys/kernel/security/apparmor/.remove

             (code=exited, status=0/SUCCESS)

Monitor for Kernel Patches

Upstream patches were submitted to Linus Torvalds’ kernel tree on March 12, 2026. Distribution packages are expected shortly. Check regularly for updates:

$ sudo apt update && apt list –upgradable 2>/dev/null | grep -E ‘linux-|apparmor’

When kernel or AppArmor patches appear in the upgradable list, apply them and reboot:

$ sudo apt upgrade -y && sudo reboot

Long-Term Hardening

The immediate fix addresses the vulnerability, but CrackArmor is a reminder that local access is the first link in most privilege escalation chains. The following steps reduce your overall attack surface.

Audit Local User Accounts

List all accounts with interactive shells. Every account here is a potential entry point for CrackArmor:

$ awk -F: ‘$7 ~ /(bash|sh|zsh|fish)$/ {print $1, $7}’ /etc/passwd

Remove shell access from service accounts that do not need it:

$ sudo usermod -s /usr/sbin/nologin <service-account>

Evaluate Postfix Necessity

Postfix is the third component in the root escalation chain. If your server does not need to send email, removing it eliminates this attack path entirely:

$ dpkg -l | grep postfix

If Postfix is not required:

$ sudo systemctl stop postfix

$ sudo systemctl disable postfix

$ sudo apt purge postfix -y

Restrict SSH Access

CrackArmor requires local shell access. Limiting who can SSH into the server directly reduces the pool of potential attackers:

# /etc/ssh/sshd_config – add at the end
AllowUsers deploy admin

# or restrict by group:

# AllowGroups sshusers

$ sudo systemctl restart sshd

Risk Summary

CrackArmor is a high-severity vulnerability set that affects most Ubuntu, Debian, and SUSE installations running AppArmor. The confused deputy problem at its core is trivially exploitable by any local user with shell access. Combined with Sudo and Postfix, it provides a reliable path to full root compromise. The immediate mitigation (chmod 600 on the pseudo-files) takes seconds to apply, costs nothing in terms of system functionality, and can be persisted through a simple systemd service. Every server running AppArmor should be checked and patched.

References

• Qualys Advisory: https://cdn2.qualys.com/advisory/2026/03/10/crack-armor.txt
• Upstream Patches: Submitted to Linus Torvalds’ kernel tree on 2026-03-12
• Affected Pseudo-Files: /sys/kernel/security/apparmor/.load, .replace, .remove
• No CVEs assigned at the time of advisory publication; CVEs are typically assigned 1 to 2 weeks after stable kernel releases