Kernel Exploit Triage

Definición

Kernel exploit triage es el proceso de decidir si una vulnerabilidad de privilege escalation en el kernel Linux es relevante, segura de testear, ya está parcheada o conviene manejarla mediante remediación sin ejecutar exploit.

Por qué importa

Los kernel exploits pueden tener alto impacto, pero también pueden crashear sistemas, corromper estado y producir conclusiones falsas cuando los kernels de distribución backportean fixes sin cambiar los strings de versión.

Para defensores y estudiantes, el triage de kernel debería ser disciplinado, no un paso reflejo de "searchsploit and run it".

Cómo funciona

Usá 6 gates de triage:

Versión: release del kernel, arquitectura, distribución y nivel de patch.
Exposición: configuración requerida, namespace, capability, syscall, filesystem o condición local.
Estado de patch: advisories del vendor y fixes backporteados.
Calidad del exploit: fuente, confiabilidad, supuestos de compilación y reportes de crashes.
Riesgo del entorno: producción versus lab, snapshot, valor de datos y uptime.
Decisión: parchear, documentar, testear en clon o rechazar como no aplicable.

Técnicas / patrones

Recolectá detalles del kernel y la distribución antes de buscar exploits.
Preferí advisories del vendor por sobre matching crudo de versión.
Reproducí solo en clones descartables o hosts CTF/lab.
Registrá por qué un exploit no aplica.
Tratá la ejecución de kernel exploits como último recurso.

Ejemplo trabajado: rechazar un exploit tentador

Lead: public exploit claims kernel 5.x local root
Host: Ubuntu vendor kernel with patched package revision
Precondition: unprivileged user namespaces required
Host setting: user namespaces disabled
Environment: production-like lab with no snapshot
Decision: do not run exploit; record not-applicable evidence and patch status

Un buen triage muchas veces termina en "no explotar". Eso sigue siendo trabajo de seguridad valioso cuando la decisión está basada en evidencia.

Variantes y bypasses

1. Falso positivo por versión

La versión parece vulnerable, pero los patches de la distribución fueron backporteados.

2. Precondición faltante

El host no tiene un namespace, filesystem, opción de config o capability requerida.

3. Mismatch de arquitectura

Un exploit asume x86_64, offsets específicos o un compilador/toolchain no disponible en el target.

4. Prueba propensa a crash

El exploit puede funcionar pero arriesga kernel panic o corrupción de datos.

5. Confusión de límite de container

Un issue de kernel puede afectar al host, pero las condiciones y capabilities del container deciden la explotabilidad.

Impacto

Escalada de privilegios a root.
Crash del host o denial of service.
Precondiciones de escape de container.
Persistencia mediante compromiso a nivel kernel en casos severos.
Requisitos de patching de emergencia e incident response.

Detección y defensa

Parcheá por canales del vendor. Los kernels de vendor suelen incluir backports y mitigaciones no obvias desde los strings de versión.
Reducí la superficie de ataque local. Deshabilitá features innecesarias y hacé hardening de namespaces, unprivileged user namespaces y capabilities de containers.
Usá señales EDR/audit alrededor del comportamiento de exploits. Uso sospechoso de compiladores, abuso de namespaces o patrones de crash pueden señalar intentos.
Sacá snapshot antes de testing en lab. Las pruebas de kernel deberían ser reversibles.
Preferí remediación sobre prueba de exploit en producción. Una condición vulnerable creíble más un fix del vendor puede alcanzar.

Qué no funciona como defensa primaria

Matching de string de versión solamente. Pierde backports y requisitos de config.
Correr código de exploit público a ciegas. Eso es una falla de confiabilidad y seguridad operativa.
Ignorar vulnerabilidades "local only". Cualquier foothold convierte bugs locales en candidatos de privilege escalation.

Labs prácticos

Usá solo VMs descartables de lab.

Recolectar contexto de kernel

uname -a
cat /etc/os-release
sysctl kernel.unprivileged_userns_clone 2>/dev/null

Capturá contexto de distribución, no solo versión de kernel.

Armar una tarjeta de triage de kernel

CVE/name:
Kernel version:
Distribution:
Architecture:
Required preconditions:
Vendor patch status:
Exploit source quality:
Decision:

Esto separa aplicabilidad de entusiasmo.

Revisar metadata de patch del package

dpkg -l 'linux-image*' 2>/dev/null | head
rpm -q kernel 2>/dev/null

Usá el package manager y el camino de advisory del vendor antes de asumir vulnerabilidad.

Decidir nivel de prueba

Production host: no exploit execution
Staging clone: compile/test only with snapshot
CTF lab: exploit allowed within rules
Finding proof: version + preconditions + vendor advisory + fix

La prueba más segura depende del entorno.

Ejemplos prácticos

Un kernel parece viejo, pero Ubuntu backporteó el fix.
Un container no tiene la capability requerida por un exploit público.
Un target CTF espera intencionalmente práctica con kernel exploits.
Un servidor de producción debería parchearse en vez de explotarse.
Un proof of concept propenso a crash se rechaza porque la evidencia de configuración alcanza.

Notas relacionadas

Futuras notas atómicas sugeridas

linux-kernel-hardening
container-kernel-attack-surface
kernel-cve-advisory-triage
unprivileged-user-namespaces

Referencias

Documentación oficial: Linux kernel security bugs — https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html
Documentación oficial: uname — https://man7.org/linux/man-pages/man1/uname.1.html
Research / Deep Dive: MITRE ATT&CK Privilege Escalation — https://attack.mitre.org/tactics/TA0004/