Linus Torvalds aprobó un documento para el kernel que describe el proceso para gestionar errores relacionados con la seguridad, define un modelo de amenazas, aclara qué errores del kernel se consideran vulnerabilidades y analiza cómo gestionar los errores identificados mediante inteligencia artificial. El documento fue elaborado por Willy Tarreau, autor de HAProxy y desarrollador veterano del kernel. Linux, responsable de mantener varias ramas estables del kernel. El marco se basó en acuerdos alcanzados durante discusiones sobre vulnerabilidades críticas del kernel recientemente identificadas (1, 2, 3, 4) reveladas antes de que se publicaran los parches y para las cuales, gracias a la IA, se crearon inmediatamente exploits funcionales.
La mayoría de los fallos de seguridad se harán públicos para llegar al mayor número de usuarios posible y encontrar la solución óptima. Se utilizará una lista de correo privada independiente para enviar únicamente informes urgentes sobre vulnerabilidades que sean fáciles de explotar, que supongan una amenaza para muchos usuarios y que permitan obtener privilegios o capacidades adicionales.
Siempre se recomienda que las vulnerabilidades descubiertas mediante asistentes de IA se discutan públicamente, ya que suelen ser detectadas simultáneamente por varios investigadores. Sin embargo, no es necesario revelar la vulnerabilidad en sí en el informe; basta con mencionar su disponibilidad y compartirla de forma privada a petición del responsable del mantenimiento.
Las reglas para enviar informes generados por asistentes de IA se describen por separado. Estos informes se envían en gran cantidad y, en ocasiones, ayudan a identificar errores en secciones de código poco revisadas, pero los responsables del mantenimiento suelen ignorarlos debido a su baja calidad e imprecisiones. Los principales requisitos para los informes generados por IA son:
- Breve, sin rodeos, y con la esencia y los detalles importantes expuestos desde el principio.
- Texto plano sin etiquetas Markdown ni formato.
- Comprender el modelo de amenazas y proporcionar hechos verificables (por ejemplo, "el error permite a cualquier usuario obtener CAP_NET_ADMIN") en lugar de especulaciones teóricas y conjeturas sobre las consecuencias de la vulnerabilidad.
- Antes de enviar un informe, asegúrese de probar exhaustivamente la funcionalidad del exploit generado por IA y de comprobar que el problema se puede reproducir.
- Utilizar la inteligencia artificial para desarrollar y probar una solución al problema identificado.
Según las estadísticas de los responsables del mantenimiento, la mayoría de los informes de errores que se envían bajo la apariencia de correcciones de vulnerabilidades no son realmente vulnerabilidades y deben tratarse como errores comunes. Se ha desarrollado un modelo de amenazas del kernel para distinguir entre vulnerabilidades y errores comunes. LinuxEntre las capacidades y garantías, cuya violación puede considerarse una vulnerabilidad:
- Aislamiento a nivel de usuario: acceso a archivos restringido al propietario, memoria del proceso inaccesible para otros usuarios, ptrace deshabilitado para otros procesos, aislamiento de la comunicación entre procesos (IPC) y de la comunicación de red.
- Protección basada en capacidades: sin CAP_SYS_ADMIN no se puede cambiar la configuración del kernel, la memoria ni el estado del sistema; sin CAP_NET_ADMIN no se pueden cambiar los ajustes de red ni interceptar el tráfico; sin CAP_SYS_PTRACE no se pueden supervisar los procesos de otros usuarios.
- El espacio de nombres de ID de usuario (CONFIG_USER_NS) permite a los usuarios sin privilegios crear sus propios entornos aislados desde los que no pueden influir en el espacio de nombres global, como por ejemplo, cambiar la hora, cargar módulos o montar dispositivos de bloques.
- Las interfaces de depuración (/proc/kmsg, perf, debugfs), a través de las cuales se puede acceder a información confidencial, solo son accesibles después de que el administrador haya otorgado acceso explícito.
Características que no se consideran vulnerabilidades:
- Utilizando ramas del kernel obsoletas.
- Compile con las opciones de desarrollador o las opciones que reducen la seguridad habilitadas (por ejemplo, CONFIG_NOMMU).
- Configurar ajustes de sysctl, opciones de línea de comandos, derechos de acceso al sistema de archivos o capacidades que no sean seguros, o permitir que usuarios sin privilegios accedan a interfaces privilegiadas (por ejemplo, acceso de escritura a procfs y debugfs).
- Problemas en funciones destinadas únicamente al desarrollo y la depuración del kernel, como LOCKDEP, KASAN y FAULT_INJECTION, que no están diseñadas para habilitarse en configuraciones de producción.
- Problemas en controladores, módulos y subsistemas que se encuentran en la sección STAGING o que están marcados como experimentales, inseguros o defectuosos.
- Utilizar módulos del kernel de terceros o bifurcaciones no oficiales del kernel.
- Requerir privilegios excesivos, como exigir que las acciones se realicen como root o por un usuario que tenga los derechos CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO y CAP_SYS_MODULE.
- Ataques teóricos que requieren condiciones de laboratorio, miles de millones de intentos, emulación o modificación de hardware, costes desproporcionados y configuraciones poco realistas (por ejemplo, sistemas con decenas de miles de núcleos de CPU).
- Eludir los mecanismos de seguridad (como ASLR) sin demostrar una vulnerabilidad. Falta de validación de argumentos y códigos de error que no tienen consecuencias evidentes.
- Fugas de información accidentales que escapan al control del atacante, como datos residuales en mensajes de error y fugas de direcciones/punteros de memoria del kernel sin posibilidad de explotación directa.
- Se producen errores al montar imágenes de disco dañadas si el controlador no está declarado como apto para su uso con medios no confiables. Los problemas con las imágenes de disco se pueden detectar y solucionar ejecutando la utilidad fsck.
- Ataques que requieren acceso físico al hardware, modificación del hardware o conexión de dispositivos de hardware como tarjetas de ataque DMA y analizadores lógicos, a menos que el sistema esté configurado específicamente para protegerse contra tales ataques (IOMMU).
- Se resolvieron los problemas de funcionalidad y rendimiento ajustando los permisos y los límites.
Fuente: opennet.ru
