CrackArmor: vulnerabilidades críticas en AppArmor y cómo defender tus entornos Linux

CrackArmor es el nombre que Qualys ha dado a un conjunto de nueve vulnerabilidades críticas en AppArmor, el módulo de control de acceso obligatorio (MAC) integrado en el kernel Linux y habilitado por defecto en distribuciones como Ubuntu, Debian y SUSE. Estas fallas permiten a un atacante local escalar privilegios hasta root, evadir políticas de confinamiento e incluso escapar de contenedores, afectando potencialmente a unos 12,6 millones de servidores Linux expuestos en Internet.

El problema afecta a todos los kernels Linux desde la versión 4.11 en adelante siempre que AppArmor esté habilitado, lo que incluye la mayoría de las versiones soportadas de Ubuntu, Debian y SUSE, mientras que distribuciones centradas en SELinux como Red Hat Enterprise Linux (RHEL), Fedora o Amazon Linux no se ven afectadas en su configuración por defecto. Los fabricantes han publicado ya actualizaciones de kernel y, en el caso de Ubuntu, también mitigaciones adicionales en sudo y util-linux, por lo que la principal recomendación es aplicar los parches de seguridad y reiniciar los sistemas lo antes posible.

Además del parcheo, es posible complementar la defensa con reglas de detección en Microsoft Defender for Endpoint y Microsoft Sentinel, empleando KQL para identificar patrones de explotación típicos de CrackArmor en sistemas Linux monitorizados.

¿Qué es CrackArmor?

CrackArmor es el nombre asignado por el equipo de Threat Research Unit (TRU) de Qualys a una familia de nueve vulnerabilidades descubiertas en la implementación de AppArmor dentro del kernel Linux. Estas vulnerabilidades abarcan desde desbordamientos lógicos y fallos de verificación hasta problemas en el manejo de perfiles anidados, y pueden encadenarse para conseguir:​

• Escalada de privilegios locales a root.
• Evasión completa de las restricciones impuestas por AppArmor.
• Escape de contenedores mediante user namespaces.
• Denegación de servicio a nivel de kernel (kernel panic / crash).

El hallazgo es especialmente relevante porque AppArmor se presenta como una capa de endurecimiento de seguridad, y CrackArmor demuestra que un fallo en esa capa puede convertirse en un vector de ataque de alto impacto.

El software afectado: AppArmor

AppArmor (Application Armor) es un módulo de seguridad del kernel Linux que implementa controles de acceso obligatorios (MAC), diseñados para restringir las acciones que puede realizar cada proceso mediante perfiles predefinidos. A diferencia de SELinux, que se basa en etiquetas de seguridad, AppArmor identifica las aplicaciones por su ruta en el sistema de archivos, lo que simplifica considerablemente la creación y mantenimiento de perfiles.

AppArmor proporciona dos modos de funcionamiento principales:

• Enforce: las acciones no incluidas en el perfil se bloquean y se registran en los logs.
• Complain: AppArmor no bloquea, pero registra las acciones que habrían sido denegadas, facilitando el ajuste fino de perfiles.

Distribuciones como Ubuntu, Debian y openSUSE integran AppArmor en sus kernels y lo habilitan por defecto en muchas instalaciones, de modo que se convierte en una pieza central de su estrategia de hardening. Precisamente por ello, un conjunto de fallos en AppArmor tiene implicaciones amplias en la seguridad de estas plataformas.

Alcance: versiones de kernel y distribuciones afectadas

Versiones de kernel vulnerables

Los análisis públicos y la documentación de Qualys coinciden en que CrackArmor afecta a todos los kernels Linux desde la versión 4.11 (lanzada en 2017) en adelante, siempre que AppArmor esté habilitado como LSM. Esto implica un rango muy amplio de versiones, incluyendo ramas LTS todavía muy presentes en producción, como 5.15 y 6.1.

Las ramas de kernel donde ya se han publicado parches incluyen, entre otras:​

Rama de kernel	Estado frente a CrackArmor
6.8.x	Parches disponibles en ramas estables
6.6.x LTS	Parches disponibles
6.1.x LTS	Parches disponibles
5.15.x LTS	Parches disponibles

Versiones anteriores a la introducción de AppArmor en el kernel moderno (pre‑4.11) no se ven afectadas por estas vulnerabilidades concretas, aunque suelen estar fuera de soporte en la mayoría de distribuciones.​

Distribuciones afectadas

Las distribuciones afectadas son, principalmente, aquellas que:

1. Compilan el kernel con soporte AppArmor.
2. Habilitan AppArmor como LSM por defecto o lo utilizan de forma activa en producción.

En esta categoría se encuentran:

• Ubuntu (todas las versiones soportadas), donde AppArmor está activado por defecto y se emplea para proteger servicios clave del sistema.
• Debian, que desde hace años integra AppArmor y lo habilita en muchas instalaciones por defecto.
• SUSE Linux Enterprise y openSUSE, que utilizan AppArmor como componente central de su modelo de seguridad.
• Derivadas directas de estas distribuciones, como Linux Mint, Pop!_OS, Kali Linux, entre otras.

Distribuciones populares que pueden no estar afectadas

Existen distribuciones populares que, en su configuración estándar, no utilizan AppArmor y, por tanto, no se ven afectadas por CrackArmor en su configuración por defecto:

• Red Hat Enterprise Linux (RHEL): emplea SELinux como LSM principal, no AppArmor.
• Fedora: también utiliza SELinux por defecto.
• Amazon Linux: sigue el modelo de RHEL y Fedora, con SELinux en lugar de AppArmor.
• Arch Linux: ofrece AppArmor como opción, pero no viene activado por defecto; un sistema Arch sin AppArmor no es vulnerable a CrackArmor, aunque sí lo sería si un administrador decidiera habilitarlo.​

En la práctica, la gran mayoría de entornos empresariales basados en RHEL/Fedora/Amazon Linux con SELinux en modo enforcing quedan fuera del alcance de CrackArmor, salvo que se haya compilado e instalado AppArmor manualmente, algo muy poco habitual.​

Disponibilidad de parches

Qualys llevó a cabo una investigación en profundidad sobre AppArmor y reportó de forma privada las nueve vulnerabilidades a los mantenedores del kernel Linux y a los principales proveedores de distribuciones. Tras un periodo de embargo y coordinación, se publicaron los parches en el kernel upstream y se inició el proceso de backport a las ramas LTS mantenidas por las distintas distribuciones.​

Artículos técnicos y notas de prensa sitúan la divulgación pública en torno al 11–13 de marzo de 2026, fecha a partir de la cual Ubuntu, Debian y SUSE comenzaron a publicar sus propios avisos y actualizaciones de seguridad.

Parches en Ubuntu

Canonical ha publicado una página específica en su Base de Conocimiento de vulnerabilidades donde detalla el impacto de CrackArmor en Ubuntu y lista, por release, las versiones de kernel parcheadas. Entre otros puntos, se indica que:​

• Todas las versiones soportadas de Ubuntu (incluyendo 24.04 LTS, 22.04 LTS y 20.04 LTS) reciben actualizaciones de kernel que corrigen CrackArmor.
• Cada flavour de kernel (generic, lowlatency, cloud, AWS, GCP, Oracle, etc.) dispone de una versión específica ya corregida.

Adicionalmente, Canonical ha publicado un artículo de blog anunciando que los parches de AppArmor están disponibles desde el 11 de marzo de 2026, con instrucciones para actualizar los sistemas mediante los mecanismos habituales de apt y unattended-upgrades.

Parches en Debian

Debian ha difundido al menos dos avisos de seguridad (Debian Security Advisories, DSA) relacionados con las vulnerabilidades de AppArmor descubiertas por Qualys:

• DSA‑6162‑1 (linux): actualiza el paquete del kernel Linux en la distribución estable para corregir vulnerabilidades críticas de escalada de privilegios y denegación de servicio.
• DSA‑6163‑1 (linux): advisory complementario para otras variantes y arquitecturas del kernel.

Fuentes secundarias señalan que estos avisos se publicaron los días 12 y 13 de marzo de 2026, lo que sitúa la ventana de disponibilidad de parches de Debian prácticamente en paralelo a Ubuntu.

Parches en SUSE

SUSE ha emitido varios avisos de seguridad para el kernel Linux en sus productos, marcando actualizaciones como important para SLES y openSUSE a principios de 2026. Aunque los advisories del kernel suelen agrupar múltiples CVEs, diversas fuentes de seguridad indican que estas actualizaciones incluyen las correcciones correspondientes a las vulnerabilidades de AppArmor reportadas por Qualys como parte de CrackArmor.

Las instrucciones de SUSE recomiendan aplicar las actualizaciones de kernel mediante zypper patch o mecanismos de gestión centralizada, seguidas de un reboot obligatorio para cargar el nuevo kernel.​

Situación de los CVE

En el momento de la divulgación inicial, los informes públicos señalan que las vulnerabilidades de CrackArmor aún no tenían CVE asignados, ya que el equipo del kernel Linux es quien debe coordinar esos identificadores una vez estabilizados los parches. Este proceso suele tardar entre una y dos semanas, por lo que los fabricantes han insistido en que la ausencia de CVE no debe retrasar el parcheo.

Recomendaciones de corrección y mitigación

Prioridad de parcheo

Qualys, Canonical y otros analistas coinciden en que CrackArmor debe tratarse como un incidente de parcheo urgente, dado que permite escalada a root, evasión de mecanismos de confinamiento y, en algunos casos, escape de contenedores y denegación de servicio a nivel de kernel.

Las recomendaciones principales son:

1. Actualizar el kernel a una versión parcheada en todos los sistemas que utilicen AppArmor.
2. Reiniciar los servidores para que el nuevo kernel entre en funcionamiento.
3. Aplicar mitigaciones adicionales en el espacio de usuario (sudo, util-linux) donde estén disponibles.

Acciones específicas en Ubuntu

Para Ubuntu, Canonical propone el siguiente enfoque:

• Actualizar el sistema y el kernel:

sudo apt update && sudo apt upgrade
sudo reboot

• Instalar mitigaciones en user-space incluso antes de poder reiniciar todos los hosts, aplicando las actualizaciones de sudo y util-linux:

sudo apt update
sudo apt install sudo util-linux

Estas mitigaciones reducen la superficie de ataque relacionada con la cadena de explotación que emplea su, sudo y Postfix, pero no sustituyen al parche de kernel.

Acciones específicas en Debian

En Debian, la recomendación es aplicar los advisories DSA correspondientes y reiniciar:

sudo apt update
sudo apt full-upgrade
sudo reboot

Se aconseja verificar que el metapaquete linux-image-* ha sido actualizado a la versión indicada en el DSA para la rama concreta de la distribución.

Acciones específicas en SUSE

SUSE indica que las actualizaciones de kernel deben desplegarse mediante zypper, seguidas también de un reinicio:

sudo zypper refresh
sudo zypper patch
sudo reboot

En entornos con capacidades de livepatching, pueden existir parches live para algunas ramas; sin embargo, dado que CrackArmor afecta a la lógica de AppArmor en el kernel, la recomendación general es avanzar igualmente hacia el kernel completo parcheado.

Mitigaciones adicionales

Mientras se completa el despliegue de parches, las organizaciones pueden considerar medidas compensatorias:

• Restringir el acceso local y por SSH a usuarios estrictamente necesarios.
• Revisar el uso de su y sudo, endureciendo la configuración de sudoers y limitando el número de cuentas con privilegios elevados.
• Minimizar el uso de contenedores de procedencia no confiable en nodos donde AppArmor esté activo.
• Monitorizar cambios anómalos en los perfiles de AppArmor y reinicios inesperados de sistema que puedan indicar explotación.

Detección con KQL en Microsoft Defender

Aunque la corrección definitiva pasa por el parcheo del kernel, es posible mejorar la capacidad de detección en entornos integrados con Microsoft Defender for Endpoint y Microsoft Sentinel mediante consultas KQL dirigidas a comportamientos anómalos asociados a CrackArmor.

Accesos sospechosos a ficheros de control de AppArmor

CrackArmor explota la posibilidad de escribir en pseudo‑ficheros de AppArmor bajo /sys/kernel/security/apparmor/ (.load, .replace, .remove) para cargar o reemplazar perfiles de seguridad. En sistemas con el agente de Defender para Endpoint en Linux, pueden detectarse estas operaciones así:

DeviceFileEvents
| where FolderPath startswith "/sys/kernel/security/apparmor"
| where FileName in (".load", ".replace", ".remove")
| project Timestamp, DeviceName, InitiatingProcessAccountName,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          FolderPath, FileName
| order by Timestamp desc

Esta consulta ayuda a identificar procesos que manipulan directamente la configuración de AppArmor, algo que en entornos de producción suele estar restringido a herramientas de administración muy concretas.

Abuso de sudo y MAIL_CONFIG para escalar a root

Una de las cadenas de ataque descritas se apoya en la manipulación de la variable de entorno MAIL_CONFIG en combinación con sudo y Postfix, permitiendo la ejecución de comandos como root. Esto puede investigarse con:

DeviceProcessEvents
| where FileName == "sudo" or FileName == "sendmail"
| where ProcessCommandLine has_any ("MAIL_CONFIG", "sendmail", "postfix")
| where InitiatingProcessAccountName != "root"
| where AccountName == "root" or ProcessTokenElevation == "TokenElevationTypeFull"
| project Timestamp, DeviceName, AccountName, InitiatingProcessAccountName,
          ProcessCommandLine, InitiatingProcessCommandLine, FileName
| order by Timestamp desc

Esta regla busca usos de sudo o sendmail donde se manipulan parámetros relacionados con la cadena de explotación y se obtiene un contexto de ejecución privilegiado.

Creación anómala de user namespaces (escape de contenedores)

CrackArmor también puede emplearse para facilitar escapes de contenedor mediante la creación de user namespaces desde procesos no privilegiados. Esto puede detectarse con consultas enfocadas a comandos como unshare o llamadas a clone con opciones de user namespace:

DeviceProcessEvents
| where ProcessCommandLine has_any ("unshare", "clone", "--user", "userns")
| where InitiatingProcessAccountName !in ("root", "system")
| project Timestamp, DeviceName, AccountName, InitiatingProcessAccountName,
          ProcessCommandLine, FileName, FolderPath
| order by Timestamp desc

Este tipo de actividad puede ser legítima en entornos de contenedores avanzados, por lo que resulta clave contextualizar los hallazgos, pero constituye un indicador relevante de posible explotación.

Modificaciones sospechosas de /etc/passwd

Algunas variantes de explotación incluyen la modificación directa de /etc/passwd desde contextos no privilegiados tras aprovechar fallos en el kernel. Defender puede ayudar a detectar estos eventos:

DeviceFileEvents
| where FolderPath == "/etc" and FileName == "passwd"
| where ActionType in ("FileModified", "FileCreated")
| where InitiatingProcessAccountName != "root"
| project Timestamp, DeviceName, InitiatingProcessAccountName,
          InitiatingProcessFileName, InitiatingProcessCommandLine, ActionType
| order by Timestamp desc

Cualquier modificación de /etc/passwd por procesos que no se ejecutan como root debería ser objeto de análisis inmediato.

Regla de hunting consolidada

Para los equipos de threat hunting que deseen una visión unificada, es posible combinar varios de estos indicadores en una única consulta KQL que etiquete los eventos según el tipo de comportamiento sospechoso:

let AppArmorWrite = DeviceFileEvents
    | where FolderPath startswith "/sys/kernel/security/apparmor"
    | extend AlertType = "AppArmor pseudofile write";
let SudoAbuse = DeviceProcessEvents
    | where ProcessCommandLine has_any ("MAIL_CONFIG", "sendmail")
      and FileName == "sudo"
    | extend AlertType = "Sudo MAIL_CONFIG abuse";
let PasswdModify = DeviceFileEvents
    | where FolderPath == "/etc" and FileName == "passwd"
      and InitiatingProcessAccountName != "root"
    | extend AlertType = "Passwd modified by non-root";
let NamespaceEscape = DeviceProcessEvents
    | where ProcessCommandLine has_any ("unshare --user", "userns")
    | extend AlertType = "User namespace creation";
union AppArmorWrite, SudoAbuse, PasswdModify, NamespaceEscape
| project Timestamp, AlertType, DeviceName, AccountName,
          InitiatingProcessAccountName, ProcessCommandLine, FolderPath, FileName
| order by Timestamp desc

Esta consulta permite visualizar, en una sola vista, distintos patrones de actividad relacionados con posibles intentos de explotación de CrackArmor, facilitando la priorización de investigaciones.

Regla de hunting para validar si nuestros kernels están afectados

DeviceInfo
| where TimeGenerated > ago(24h)
| where OSPlatform == "Linux"
| summarize arg_max(TimeGenerated, *) by DeviceId, DeviceName
// Extract kernel version components
| extend KernelFull  = tostring(OSVersion)
| extend KernelMajor = toint(extract(@"^(\d+)\.", 1, KernelFull))
| extend KernelMinor = toint(extract(@"\.(\d+)\.", 1, KernelFull))
| extend KernelPatch = toint(extract(@"\.(\d+)-", 1, KernelFull))
| extend KernelBuild = toint(extract(@"-(\d+)\.", 1, KernelFull))
| extend KernelBranch = strcat(tostring(KernelMajor), ".", tostring(KernelMinor))
| extend KernelNum = (KernelMajor * 1000000) + (KernelMinor * 10000) + (KernelPatch * 1000) + KernelBuild
// Identify distro and release name
| extend DistroRaw = tolower(strcat(tostring(OSDistribution), " ", tostring(OSVersionInfo)))
| extend UbuntuRelease = case(
    DistroRaw has "25.10" or DistroRaw has "questing", "Ubuntu 25.10 (Questing Quokka)",
    DistroRaw has "24.04" or DistroRaw has "noble",    "Ubuntu 24.04 LTS (Noble Numbat)",
    DistroRaw has "22.04" or DistroRaw has "jammy",    "Ubuntu 22.04 LTS (Jammy Jellyfish)",
    DistroRaw has "20.04" or DistroRaw has "focal",    "Ubuntu 20.04 LTS (Focal Fossa)",
    DistroRaw has "18.04" or DistroRaw has "bionic",   "Ubuntu 18.04 LTS (Bionic Beaver)",
    DistroRaw has "16.04" or DistroRaw has "xenial",   "Ubuntu 16.04 LTS (Xenial Xerus)",
    KernelBranch == "6.8",  "Ubuntu 24.04 LTS [inferred from kernel]",
    KernelBranch == "5.15", "Ubuntu 22.04 LTS [inferred from kernel]",
    KernelBranch == "5.4",  "Ubuntu 20.04 LTS [inferred from kernel]",
    KernelBranch == "4.15", "Ubuntu 18.04 LTS [inferred from kernel]",
    KernelBranch == "4.4",  "Ubuntu 16.04 LTS [inferred from kernel]",
    strcat("Unknown distro (kernel ", KernelBranch, ")")
)
// Impact level per release
| extend ImpactLevel = case(
    UbuntuRelease has "25.10", "CRITICAL - LPE + Container Escape",
    UbuntuRelease has "24.04", "CRITICAL - LPE + Container Escape",
    UbuntuRelease has "22.04", "CRITICAL - LPE + Container Escape",
    UbuntuRelease has "20.04", "HIGH - Partial Container Escape",
    UbuntuRelease has "18.04", "HIGH - Partial Container Escape",
    UbuntuRelease has "16.04", "LOW - DoS only",
    "Not evaluated"
)
// Patch status for patched releases (24.04 / 22.04 / 25.10)
| extend PatchBase = case(
    UbuntuRelease has "25.10" and KernelNum >= 6170019, "PATCHED",
    UbuntuRelease has "25.10" and KernelNum <  6170019, "VULNERABLE",
    UbuntuRelease has "24.04" and KernelNum >= 6080106,  "PATCHED",
    UbuntuRelease has "24.04" and KernelNum <  6080106,  "VULNERABLE",
    UbuntuRelease has "22.04" and KernelNum >= 5150173,  "PATCHED",
    UbuntuRelease has "22.04" and KernelNum <  5150173,  "VULNERABLE",
    ""
)
// Patch status for releases with no fix yet
| extend PatchPending = case(
    UbuntuRelease has "20.04", "PENDING",
    UbuntuRelease has "18.04", "PENDING",
    UbuntuRelease has "16.04", "PENDING",
    ""
)
// Consolidate final status
| extend CrackArmorStatus = case(
    PatchBase    == "PATCHED",    "PATCHED",
    PatchBase    == "VULNERABLE", "VULNERABLE",
    PatchPending == "PENDING",    "PENDING - No patch available",
    "NOT EVALUATED"
)
// Filter only vulnerable or pending devices
| where CrackArmorStatus in ("VULNERABLE", "PENDING - No patch available")
// Final output
| project
    DeviceName,
    UbuntuRelease,
    ImpactLevel,
    KernelFull,
    KernelBranch,
    CrackArmorStatus,
    OSDistribution,
    OSVersionInfo,
    TimeGenerated
| sort by ImpactLevel asc, DeviceName asc

CrackArmor pone de manifiesto hasta qué punto la seguridad de las capas de control de acceso del kernel es crítica: una vulnerabilidad en AppArmor puede dar lugar no solo a la evasión de sus políticas, sino a escaladas de privilegios y escapes de contenedores de amplio alcance. La buena noticia es que ya existen parches de kernel para las principales ramas y distribuciones afectadas, y que Ubuntu, Debian y SUSE han reaccionado con rapidez publicando actualizaciones y guías de mitigación.

Para los equipos de seguridad, las prioridades son claras: inventariar qué sistemas utilizan AppArmor, aplicar sin demora las actualizaciones de kernel y de user-space proporcionadas por los vendors, y reforzar la monitorización con reglas de detección específicas en plataformas como Microsoft Defender y Sentinel. De esta forma, es posible reducir sustancialmente la ventana de exposición y detectar intentos de explotación mientras se completa el ciclo de parcheo.

Más info [EN]

Technical Details