RCE en Linux: evadir noexec con userland-exec

¿Qué es el ataque userland-exec y por qué importa ahora?

Un servidor Linux con noexec activo, SELinux en modo enforcing y AppArmor configurado sigue siendo vulnerable a ejecución arbitraria de código — y hay una prueba de concepto pública que lo demuestra en 2026. Eso debería encender alertas en cualquier equipo de ingeniería que corra cargas de trabajo en producción.

El proyecto hardenedlinux publicó el 13 de abril de 2026 un PoC (prueba de concepto) que implementa la técnica conocida como userland-exec: la capacidad de cargar y ejecutar binarios ELF directamente en memoria del proceso, sin tocar el sistema de archivos ni invocar la syscall execve. El resultado es ejecución sigilosa de código en entornos que, sobre el papel, deberían impedirlo.

¿Cómo funciona userland-exec técnicamente?

La técnica fue documentada por primera vez por el investigador conocido como grugq en 2004, en comunidades de seguridad ofensiva. Dos décadas después sigue siendo relevante porque ataca un problema estructural del kernel Linux vanilla, no un bug puntual con CVE.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El mecanismo es el siguiente:

Un loader escrito en ensamblador (NASM para x86_64 y ARM64) inyecta el binario objetivo directamente en una región de memoria del proceso atacante.
La ejecución se lanza mediante syscalls directas (como memfd_create) sin pasar por execve, que es el punto donde el kernel verifica los flags de montaje noexec.
Al no mapear ningún archivo del filesystem, se salta el chequeo de noexec. Al evitar las rutas estándar de memoria ejecutable, se sortean parcialmente SELinux execmem y la política W^X.
Versiones modernas del PoC de hardenedlinux (actualizadas en enero 2025) soportan tanto arquitectura x86 como ARM64, ampliando el alcance a servidores de nube modernos y dispositivos embebidos con SELinux.

El vector post-explotación es lo más preocupante: un atacante que ya tiene un foothold inicial puede usar userland-exec para elevar privilegios o moverse lateralmente sin dejar artefactos en disco.

¿Qué protecciones evade y cuáles no?

No todas las defensas caen igual. Esta tabla resume qué resiste y qué no:

noexec en particiones (/tmp, /var): bypasseado completamente. El código nunca toca el filesystem.
SELinux execmem: evasión parcial dependiendo de la política configurada. Dispositivos embebidos con SELinux son especialmente vulnerables.
AppArmor: efectividad limitada contra userland-exec directo, pero combinado con las 9 vulnerabilidades CrackArmor descubiertas en 2026 (que afectan a más de 12 millones de sistemas Ubuntu, Debian y SUSE), el riesgo escala significativamente.
PaX/GRsecurity: es la única defensa que bloquea la técnica de forma completa, restringiendo escritura en /proc/*/mem y controlando memfd_create mediante RBAC.

El hallazgo de CrackArmor (marzo 2026, reportado por Security Affairs) es relevante aquí: 9 vulnerabilidades en el módulo AppArmor del kernel Linux permiten a usuarios sin privilegios manipular perfiles directamente en /sys/kernel/security/apparmor/.load, colapsando el aislamiento de contenedores y abriendo escalada a root.

¿Qué significa esto para tu startup?

Si corres servicios en Linux — y casi con certeza lo haces — este PoC describe un escenario real de post-explotación que puede convertir una vulnerabilidad de bajo impacto (digamos, una inyección en un endpoint poco privilegiado) en un compromiso total del servidor.

Los riesgos concretos para un equipo técnico de startup:

Servidores de API en AWS, GCP o Azure con volúmenes EBS/GPD montados con noexec siguen siendo vulnerables si el kernel subyacente no tiene PaX/GRsecurity.
Pods de Kubernetes en Ubuntu con AppArmor en modo permissive (el default en muchos clusters no endurecidos) son blancos directos de CrackArmor.
Entornos Docker sin seccomp por contenedor no limitan las syscalls necesarias para userland-exec.
Un atacante que explota esta cadena no deja binarios en disco — los sistemas de detección basados en integridad de archivos (AIDE, Tripwire) son ciegos a este vector.

Para equipos con menos de 10 ingenieros, la brecha más común es AppArmor en modo complain en lugar de enforce: el perfil registra violaciones pero no las bloquea, lo cual da una falsa sensación de seguridad.

Acciones concretas para endurecer tu infraestructura Linux en 2026

Basado en las mitigaciones documentadas por hardenedlinux y en las mejores prácticas actualizadas para 2025-2026:

Activa AppArmor en modo enforce, no complain. Usa aa-genprof para generar perfiles para tus servicios críticos. Si usas Ubuntu, verifica el estado con aa-status y aplica parches del kernel para CrackArmor.
Aplica seccomp por contenedor en Docker/Kubernetes. El perfil de seccomp por defecto de Docker bloquea algunas syscalls críticas, pero para entornos de producción necesitas perfiles personalizados que denieguen explícitamente memfd_create, ptrace y escritura en /proc/*/mem.
Monta /tmp, /var y /home con noexec y nosuid como primera línea, sabiendo que no es suficiente por sí solo — pero sí eleva el costo del ataque.
Considera GRsecurity/PaX para cargas de trabajo críticas. Es la única defensa que bloquea userland-exec de forma completa. Tiene coste de licencia para producción, pero para un servidor que maneja datos sensibles o pagos, el ROI es claro.
Endurece sysctl: establece kernel.yama.ptrace_scope=2 (bloquea ptrace entre procesos no relacionados), kernel.kptr_restrict=2 y kernel.sysrq=0. Estos tres parámetros reducen la superficie de ataque de forma inmediata y no requieren reinicio en la mayoría de distribuciones.
Elimina compiladores de servidores de producción. apt remove gcc build-essential no evita userland-exec (el payload viene precompilado), pero sí dificulta la fase de preparación del ataque.
Implementa auditd con reglas para syscalls sospechosas. Monitoriza llamadas a memfd_create, ptrace y escrituras en /proc/PID/mem — señales de actividad userland-exec en tiempo real.

El contexto más amplio: por qué el hardening de Linux sigue siendo un problema no resuelto

La técnica userland-exec tiene 20 años de historia documentada y sigue siendo efectiva en 2026 porque el kernel Linux vanilla no incluye protecciones contra ella por defecto. El dilema para cualquier equipo de ingeniería es siempre el mismo: GRsecurity ofrece la protección más completa, pero su modelo de licencia comercial lo aleja de startups en etapa temprana.

El ecosistema cloud no resuelve esto por defecto. AWS, GCP y Azure ofrecen imágenes de Linux optimizadas para sus entornos, pero el hardening a nivel de kernel sigue siendo responsabilidad del equipo que despliega. Un cluster de Kubernetes con nodos worker en Ubuntu 24.04 sin perfiles de seccomp personalizados y AppArmor en modo complain es un blanco válido para esta cadena de ataque hoy mismo.

La combinación de userland-exec con las vulnerabilidades CrackArmor en AppArmor describe un escenario donde las dos capas de defensa más usadas en entornos cloud modernos pueden ser neutralizadas en secuencia. Eso no es teórico — hay PoCs públicos para ambas.

Para founders técnicos: el hardening de Linux no es una tarea de un día, pero hay un conjunto mínimo de configuraciones que pueden implementarse en menos de dos horas y que cubren los vectores más explotados. Los siete puntos de la sección anterior son ese conjunto mínimo.