Container Security on KnightLi Blog

Impacto de cuatro problemas locales recientes en Linux: Copy Fail, Dirty Frag, Fragnesia y ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

En las últimas semanas aparecieron varios problemas locales de seguridad de alto perfil en el ecosistema Linux. Por separado, afectan zonas distintas: interfaces criptográficas, rutas de red e IPsec, manejo de page cache y comprobaciones de acceso ptrace. En conjunto, apuntan a la misma lección operativa: si un atacante ya tiene un punto de ejecución local con pocos privilegios, el riesgo para hosts Linux, nodos de contenedores, máquinas de CI y servidores multiusuario aumenta de forma clara.

Este artículo no repite todos los detalles técnicos de cada vulnerabilidad. Resume su impacto práctico y enlaza cuatro análisis separados dentro del sitio.

Qué afecta cada uno de los cuatro eventos

Los cuatro riesgos que conviene seguir son:

Copy Fail (CVE-2026-31431): un usuario local con pocos privilegios puede afectar la page cache mediante rutas relacionadas con criptografía del kernel y ampliar privilegios.
Dirty Frag (relacionado con CVE-2026-43284 / CVE-2026-43500): el riesgo se concentra en xfrm/ESP, RxRPC y rutas de datos de red y kernel, con alto impacto en fases posteriores a una intrusión.
Fragnesia (CVE-2026-46300): cercano a Dirty Frag, gira alrededor de XFRM ESP-in-TCP, fragmentos compartidos y riesgo de escritura en page cache.
ssh-keysign-pwn (CVE-2026-46333): no es un bug de root shell directo, sino un riesgo local de divulgación de información que puede exponer claves privadas SSH del host, /etc/shadow y otros archivos sensibles.

Los puntos de entrada son distintos y las mitigaciones también. Arreglar Copy Fail no cubre automáticamente Dirty Frag o Fragnesia. Desactivar algunos módulos de red tampoco elimina por sí solo el riesgo de divulgación de información de ssh-keysign-pwn.

Copy Fail: alta prioridad para contenedores y nodos CI

El impacto clave de Copy Fail no es que una aplicación se bloquee. Es que una capacidad de ejecución con pocos privilegios puede convertirse en permisos de root. Es especialmente sensible en estos entornos:

Nodos CI/CD que permiten subir o ejecutar código.
Hosts de contenedores que ejecutan cargas no confiables.
Máquinas de desarrollo y prueba, jump hosts y servidores compartidos.
Hosts cloud con kernels antiguos y ciclos de parcheo lentos.

El peligro de Copy Fail está en su umbral de explotación relativamente bajo y en que se combina fácilmente con escenarios de contenedores. Muchos equipos tratan los contenedores como una frontera fuerte de aislamiento, pero los contenedores ordinarios siguen compartiendo el kernel del host por defecto. Si un atacante obtiene una shell dentro de un contenedor, una LPE del kernel puede convertir un problema del contenedor en un problema del host.

Análisis detallado: Copy Fail CVE-2026-31431: riesgo de escape de contenedor en una ruta de copia de archivos del kernel Linux.

Dirty Frag: un amplificador posterior a la intrusión

Dirty Frag se parece más a una herramienta de ampliación de privilegios después de que el atacante ya entró al sistema. No es una vulnerabilidad remota sin autenticación típica. El requisito habitual es que el atacante ya tenga ejecución local mediante una contraseña débil, WebShell, cuenta de servicio con pocos privilegios, tarea de contenedor u otro punto de apoyo.

Su impacto práctico aparece en varios lugares:

Una cuenta comprometida con pocos privilegios puede convertirse en root.
Un punto de ejecución con pocos privilegios dentro de un contenedor puede amenazar al host.
Los sistemas que usan IPsec, ESP, RxRPC o capacidades de red relacionadas del kernel necesitan revisar con cuidado parches y mitigaciones temporales.
Los equipos de seguridad no deben mirar solo la defensa perimetral, sino también las cadenas de escalada posteriores a la intrusión.

Dirty Frag recuerda a los equipos de operaciones que una LPE local quizá no sea la primera entrada, pero puede decidir hasta dónde llega una intrusión. Si existe un punto de apoyo con pocos privilegios, el atacante buscará bugs del kernel para llegar al nivel más alto.

Análisis detallado: Dirty Frag CVE-2026-43284: guía de riesgo y mitigación de escalada local en Linux.

Fragnesia: una superficie similar no se limpia de una sola vez

Fragnesia importa porque muestra que la superficie alrededor de Dirty Frag no es un problema aislado. Incluso si un bug se corrige, rutas vecinas, estructuras de datos similares y combinaciones de módulos relacionados pueden conservar nuevos puntos explotables.

Su impacto operativo principal es:

No tratar solo el nombre de la vulnerabilidad una vez. Hay que seguir revisando por superficie de ataque.
esp4, esp6, rxrpc, XFRM y ESP-in-TCP deben evaluarse según dependencias reales del negocio.
Si el sistema no depende de esas capacidades de red, se puede considerar una desactivación temporal, pero primero debe probarse para no romper VPN, IPsec, túneles o redes internas.
Los riesgos de contaminación de page cache pueden crear puntos ciegos: el archivo parece no cambiar, pero la ruta de ejecución queda afectada.

Para empresas, la lección principal es que la gestión de parches no debe mirar solo un CVE aislado. Es más seguro inventariar por subsistemas y superficies de ataque, identificar qué máquinas exponen esas capacidades y qué servicios realmente necesitan esos módulos.

Análisis detallado: Fragnesia (CVE-2026-46300): impacto y mitigación de una escalada local en el kernel Linux.

ssh-keysign-pwn: no da root directo, pero sigue siendo peligroso

ssh-keysign-pwn es distinto de los tres anteriores. Se parece más a una divulgación local de información sensible que a una vulnerabilidad de root shell directo. Pero en ataques reales, la divulgación de información sensible puede convertirse rápidamente en un incidente mayor.

Sus impactos principales incluyen:

La filtración de SSH host private keys puede afectar la confianza en la identidad del host.
El acceso a archivos como /etc/shadow puede permitir cracking offline y toma de cuentas.
Servidores multiusuario, jump hosts, máquinas de build y máquinas de desarrollo compartidas tienen mayor riesgo.
Aunque el atacante no escale privilegios de inmediato, puede obtener material de credenciales útil para movimiento lateral.

Este tipo de problema se subestima fácilmente porque no luce tan dramático como una shell root directa. Sin embargo, en entornos empresariales, la exposición de claves y hashes de contraseñas suele implicar una limpieza más larga: rotar claves SSH del host, revisar relaciones de confianza, comprobar contraseñas de cuentas y auditar logs de acceso.

Análisis detallado: ssh-keysign-pwn (CVE-2026-46333): divulgación local en Linux, claves SSH del host y riesgo sobre /etc/shadow.

Impacto común: los contenedores no son una frontera fuerte por defecto

Juntos, estos cuatro eventos dejan claro un punto: el aislamiento ordinario de contenedores no es aislamiento de máquina virtual.

Docker, containerd y Kubernetes usan namespaces, cgroups, capabilities, seccomp, AppArmor y SELinux para reducir superficie de ataque, pero normalmente siguen compartiendo el kernel del host. Si la vulnerabilidad está en el kernel compartido, un punto de ejecución con pocos privilegios dentro de un contenedor puede convertirse en entrada de ataque.

Los entornos de alto riesgo deberían revisar:

Si se permite ejecutar código no confiable en hosts compartidos.
Si los contenedores corren como root por defecto.
Si se conceden capabilities innecesarias.
Si las políticas seccomp son demasiado amplias.
Si cargas multi-tenant deberían moverse a gVisor, Kata Containers, Firecracker microVM, máquinas virtuales dedicadas o nodos dedicados.

Las plataformas CI/CD merecen atención especial. Los jobs de build ejecutan de forma natural código externo, scripts de instalación de dependencias, scripts de prueba y binarios temporales. Si esos jobs comparten hosts con servicios de larga duración, una sola escalada local puede afectar infraestructura mucho mayor.

Impacto común: los parches deben llegar al kernel en ejecución

Un error común al parchear kernels Linux es asumir que un paquete instalado significa que la máquina está ejecutando el kernel corregido.

Como mínimo, operaciones debería verificar tres cosas:

`1`	`uname -a`

Confirmar el kernel actualmente en ejecución.

`1`	`dpkg -l \| grep linux-image`

O en distribuciones de la familia RHEL:

`1`	`rpm -qa \| grep kernel`

Confirmar los paquetes de kernel instalados.

Finalmente, confirmar que la máquina reinició con el kernel corregido. Para servicios críticos que no pueden reiniciarse de inmediato, evaluar livepatch, hot patching o aislamiento temporal, pero no tratar la mitigación temporal como arreglo final.

Impacto común: reducir superficie de ataque debe ser específico

Estas vulnerabilidades recuerdan que endurecer Linux no puede quedarse en “actualizar el sistema” y “activar firewall”.

Revisiones más concretas incluyen:

Si AF_ALG / algif_aead se usa en cargas del negocio.
Si XFRM, ESP, ESP-in-TCP e IPsec son necesarios para VPN, túneles o gateways de seguridad.
Si RxRPC es necesario.
Si user namespaces no privilegiados deben estar habilitados.
Si los contenedores pueden crear tipos de socket demasiado amplios.
Si las políticas de acceso ptrace son demasiado permisivas.

Si el negocio no necesita ciertas capacidades, se puede evaluar desactivar módulos, ajustar sysctl, endurecer seccomp y reducir capabilities. No copies comandos a producción a ciegas. Primero inventaría dependencias y luego despliega gradualmente.

Orden de respuesta recomendado

Primero, prioriza máquinas donde la ejecución local de código está expuesta:

Hosts de contenedores.
CI/CD runners.
Jump hosts.
Servidores multiusuario.
Hosts que ejecutan servicios expuestos.
Sistemas que ejecutan plugins, scripts o extensiones no confiables.

Segundo, confirma avisos de la distribución y el kernel realmente en ejecución. No dependas solo del número de versión upstream. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, SUSE, openEuler y otras distribuciones pueden aplicar backports de seguridad.

Tercero, endurece políticas de ejecución de contenedores. Prioriza usuarios no root, capabilities mínimas, no-new-privileges, sistemas de archivos de solo lectura y políticas explícitas de seccomp más AppArmor o SELinux.

Cuarto, revisa exposición de claves y credenciales. Especialmente en entornos afectados por ssh-keysign-pwn, evalúa si SSH host keys, /etc/shadow, credenciales de jump hosts y CI secrets necesitan rotación.

Quinto, mejora monitoreo. Observa root shells anómalas, PoCs locales sospechosas de LPE, cambios en archivos críticos, comportamiento ptrace anómalo, procesos de contenedor accediendo a rutas del host y conexiones de red inusuales desde nodos CI.

Conclusión

El punto de estos cuatro eventos no es “Linux es inseguro”. El punto es que la confianza por defecto ya no alcanza.

Linux sigue siendo transparente, reparable, configurable y endurecible. Pero en entornos donde contenedores, CI, multi-tenancy y ejecución de código impulsada por IA son cada vez más comunes, un punto de ejecución con pocos privilegios ya no puede tratarse como un problema menor. Si el kernel contiene bugs explotables de escalada local o divulgación de información sensible, una intrusión parcial puede convertirse en control del host, exposición de credenciales o movimiento lateral.

El enfoque más realista es tomar estos cuatro eventos como recordatorio: parchear rápido, confirmar kernels reiniciados, habilitar módulos solo cuando sean necesarios, endurecer contenedores, hacer posible la rotación de claves y reevaluar niveles de aislamiento en cargas multi-tenant.

Lecturas relacionadas en este sitio:

Copy Fail CVE-2026-31431: riesgo de escape de contenedor en la ruta de copia de archivos del kernel Linux

Fri, 01 May 2026 18:42:34 +0800

Copy Fail es una vulnerabilidad en la ruta de copia de archivos del kernel Linux, registrada como CVE-2026-31431. El análisis de Bugcrowd la describe como un problema de nivel kernel que merece atención: bajo condiciones específicas, un usuario sin privilegios puede abusar de la lógica de copia de archivos para provocar escrituras no autorizadas, lo que puede llevar a escalada de privilegios o escape de contenedor.

Desde una perspectiva de riesgo, no es una vulnerabilidad normal de capa de aplicación. El problema ocurre en la ruta del kernel que maneja copia de archivos y comportamiento de page cache, por lo que su impacto puede extenderse a contenedores, hosts compartidos, runners de CI/CD, plataformas PaaS y entornos Linux multi-tenant. Si un atacante ya puede ejecutar código con pocos privilegios en un sistema, la vulnerabilidad puede convertirse en un escalón para romper límites de aislamiento.

Dónde vive aproximadamente la vulnerabilidad

Copy Fail está relacionada con capacidades de copia de archivos del kernel Linux. Linux moderno ofrece varias rutas eficientes de copia, como copy_file_range, rutas tipo splice y optimizaciones de copia de datos entre distintos sistemas de archivos. Estos mecanismos están diseñados para reducir movimiento de datos entre espacio de usuario y espacio de kernel y mejorar el rendimiento de copia de archivos grandes.

El problema es que las rutas de copia de alto rendimiento suelen reutilizar page cache, offsets de archivo, comprobaciones de permisos y callbacks de sistemas de archivos. Si una condición de borde no se maneja con suficiente rigor, el kernel puede realizar una escritura en el contexto de permisos equivocado o exponer páginas de datos que el atacante no debería controlar.

El riesgo central de Copy Fail se puede resumir así:

el atacante no necesita privilegios root;
el punto de entrada del ataque proviene de capacidades comunes de copia de archivos;
la lógica afectada se ejecuta en espacio de kernel;
en entornos de contenedores, la vulnerabilidad puede saltarse aislamiento de namespaces y montajes;
una explotación exitosa puede escribir contenido del host que el contenedor no debería poder modificar.

Por eso ha llamado la atención. La seguridad de contenedores depende del aislamiento que proporciona el kernel Linux. Cuando una ruta del propio kernel permite escrituras no autorizadas, el límite del contenedor se vuelve frágil.

Por qué los escenarios de contenedores son más sensibles

Los contenedores no son máquinas virtuales. Los procesos dentro de un contenedor comparten el mismo kernel Linux con el host y se aíslan mediante mecanismos como namespaces, cgroups, capabilities, seccomp y AppArmor/SELinux.

Si una vulnerabilidad existe en un servicio de espacio de usuario, normalmente afecta solo a un contenedor o un proceso. Pero si la vulnerabilidad está en el kernel, especialmente una que puede activar un usuario sin privilegios, un atacante puede influir en el host desde dentro de un contenedor.

Ahí es donde Copy Fail se vuelve peligroso. Muchas plataformas permiten a usuarios enviar jobs de build, ejecutar scripts, iniciar contenedores o ejecutar plugins. Mientras un atacante pueda ejecutar código dentro de un contenedor, puede intentar usar la ruta de copia de archivos del kernel para romper el aislamiento.

Entornos de alto riesgo incluyen:

cargas no confiables en clusters Kubernetes;
runners compartidos en plataformas CI/CD;
plataformas sandbox que permiten a usuarios subir y ejecutar código;
hosts Linux multi-tenant;
entornos PaaS contenerizados;
sistemas que ejecutan plugins o extensiones de terceros.

Si estos entornos ejecutan kernels afectados y no tienen restricciones adicionales, el riesgo aumenta de forma significativa.

El impacto depende del estado de parcheo del kernel

No se puede juzgar este tipo de vulnerabilidad solo por el nombre de la distribución. Para la misma versión de Ubuntu, Debian, RHEL, Fedora o Arch, la exposición depende del paquete de kernel que realmente está en ejecución y de si la distribución hizo backport del arreglo.

Durante el triage, prioriza tres comprobaciones:

La versión del kernel actualmente en ejecución.
Si el aviso de seguridad de la distribución menciona CVE-2026-31431.
Si el proveedor cloud o la plataforma gestionada parcheó el kernel del host.

Primero puedes confirmar la versión del kernel en el sistema:

`1`	`uname -a`

Luego revisa avisos de seguridad de la distribución, changelogs del kernel o comunicados de la plataforma cloud. No juzgues la seguridad solo por la versión mayor, porque muchas distribuciones empresariales hacen backport de correcciones de seguridad a ramas de kernel antiguas.

Ideas de mitigación temporal

La solución más confiable sigue siendo actualizar el kernel. Pero en entornos donde los parches no pueden desplegarse de inmediato, puedes reducir exposición primero.

Direcciones comunes de mitigación incluyen:

impedir que usuarios no confiables ejecuten contenedores privilegiados;
evitar montar rutas sensibles del host dentro de contenedores;
endurecer capabilities de contenedores, especialmente evitando CAP_SYS_ADMIN innecesario;
usar seccomp, AppArmor o SELinux para restringir syscalls peligrosas y acceso a archivos;
mover cargas no confiables a aislamiento más fuerte mediante máquinas virtuales;
destruir runners de CI/CD por job en lugar de reutilizar el mismo host durante mucho tiempo;
monitorear escrituras anómalas de archivos, cambios de permisos y señales de escape de contenedor.

Estas medidas no reemplazan parches. Su papel es reducir la probabilidad de explotación y el impacto, especialmente antes de que los parches lleguen a producción.

Prioridad de parcheo

Prioriza la remediación según el riesgo del entorno.

Parchear primero:

plataformas que exponen ejecución de contenedores a usuarios externos;
nodos CI/CD que ejecutan código no confiable;
nodos Kubernetes multi-tenant;
sistemas con plugins o ejecución de scripts definidos por usuarios;
máquinas de desarrollo compartidas, equipos de enseñanza y plataformas de laboratorio.

Prioridad relativamente menor:

escritorios de un solo usuario;
hosts internos que solo ejecutan servicios confiables;
entornos que ya aíslan código no confiable mediante máquinas virtuales.

Incluso cuando el riesgo es menor, sigue siendo mejor actualizar el kernel mediante la distribución. Las vulnerabilidades de kernel a menudo se encadenan en ataques más complejos, y retrasar parches rara vez aporta mucho beneficio.

Checklist para equipos de operaciones

Puedes procesarlo en este orden:

Inventariar todos los hosts Linux y nodos de contenedores.
Marcar máquinas que ejecutan código no confiable.
Comprobar versión actual de kernel y avisos de seguridad de la distribución.
Actualizar primero los nodos de alto riesgo.
Aplicar políticas temporales de aislamiento a nodos que no pueden actualizarse de inmediato.
Revisar configuración del runtime de contenedores y eliminar privilegios y montajes de host innecesarios.
Reiniciar nodos después de actualizar y confirmar que el nuevo kernel está realmente en ejecución.
Mantener registros de cambios para auditoría posterior.

Instalar un paquete de kernel no significa que el sistema ya esté ejecutando el nuevo kernel. Debes reiniciar después de actualizar y confirmar de nuevo:

`1`	`uname -a`

Resumen

El punto clave de Copy Fail / CVE-2026-31431 no es que una aplicación se cierre, sino que existe un problema de límite de permisos en la ruta de copia de archivos del kernel Linux. Da a código sin privilegios una oportunidad de tocar rutas de escritura con mayor privilegio, por lo que merece atención especial en entornos de contenedores y multi-tenant.

Al manejar este tipo de vulnerabilidad, las dos acciones más importantes son:

seguir cuanto antes los parches de kernel de tu distribución o proveedor cloud;
antes de desplegar parches, restringir código no confiable, contenedores privilegiados y montajes sensibles del host.

Para escritorios personales, quizá no sea un motivo de pánico inmediato. Pero para equipos que operan plataformas de contenedores, CI/CD, sandboxes y hosts compartidos, debe tratarse como una actualización de seguridad de kernel de alta prioridad.

Referencias: