Linus Torvalds ha incorporado al núcleo un documento que regula el proceso de manejo de errores relacionados con la seguridad, define el modelo de amenazas, explica qué errores en el núcleo se consideran vulnerabilidades y aborda las acciones relacionadas con los errores identificados mediante IA. El documento fue preparado por Willy Tarreau, autor de HAProxy y desarrollador veterano del núcleo de Linux, responsable del mantenimiento de varias ramas estables del núcleo. Las bases se fundamentan en los acuerdos alcanzados durante la discusión de vulnerabilidades críticas recientemente descubiertas en el núcleo (1, 2, 3, 4), reveladas antes de la publicación de correcciones y para las cuales, gracias a la IA, se han podido crear exploits funcionales de inmediato.
Se prescribe tratar la mayor parte de los errores relacionados con la seguridad de forma pública, con el fin de atraer a la audiencia más amplia posible y encontrar la solución óptima. Solo se sugiere enviar a una lista de correo privada mensajes urgentes sobre vulnerabilidades de fácil explotación que representen una amenaza para muchos usuarios y que puedan proporcionar privilegios ampliados o capacidades.
Las vulnerabilidades detectadas con la ayuda de asistentes de IA siempre se deben discutir públicamente, ya que este tipo de problemas a menudo son descubiertos simultáneamente por varios investigadores. No obstante, no se debe revelar el exploit en el informe; es suficiente mencionar que está disponible y enviarlo de manera privada en respuesta a una solicitud del responsable.
Se describen por separado las reglas para la presentación de informes generados con la ayuda de asistentes de IA. Se envían muchos de estos informes y, gracias a ellos, a veces se logran identificar errores en partes del código mal revisadas, pero los responsables a menudo los ignoran debido a su baja calidad e imprecisiones. Los principales requisitos para los informes generados con la participación de IA son:
- Concisión, sin relleno y con la esencia y detalles importantes al principio.
- Texto plano sin etiquetas Markdown ni decoraciones.
- Comprensión del modelo de amenazas y la indicación de 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 el informe, es imprescindible probar a fondo la funcionalidad del exploit generado a través de AI y asegurarse de poder reproducir el problema.
- Utilizar AI para el desarrollo y la prueba de la corrección del problema detectado.
Según las estadísticas de quienes dan soporte, la mayoría de los informes de errores enviados como correcciones de vulnerabilidades, en realidad no lo son y deben ser tratados en términos generales como errores normales. Para distinguir entre vulnerabilidades y errores comunes, se ha descrito un modelo de amenazas en el núcleo de Linux. Entre las posibilidades y garantías cuya violación puede ser considerada como vulnerabilidad están:
- Aislamiento a nivel de usuario: acceso a archivos solo para el propietario, la memoria del proceso no es accesible para otros usuarios, ptrace está prohibido para procesos ajenos, aislamiento de comunicaciones IPC y de red.
- Protección basada en capacidades: sin CAP_SYS_ADMIN no se puede cambiar la configuración del núcleo, la memoria, el estado del sistema; sin CAP_NET_ADMIN no se pueden cambiar las configuraciones de red ni interceptar el tráfico; sin CAP_SYS_PTRACE no se pueden rastrear procesos de otros usuarios.
- El espacio de nombres de identificadores de usuario (CONFIG_USER_NS) permite a los usuarios no privilegiados crear sus entornos aislados, de los cuales no pueden influir en el espacio de nombres global, por ejemplo, cambiando la hora, cargando módulos y montando dispositivos de bloque.
- Las interfaces de depuración (/proc/kmsg, perf, debugfs), a través de las cuales se puede acceder a información confidencial, solo están disponibles tras la concesión explícita de acceso por parte del administrador.
Las capacidades que no se consideran vulnerabilidades:
- Uso de ramas de núcleo obsoletas.
- Compilación con opciones habilitadas para desarrolladores o que disminuyen la seguridad (por ejemplo, CONFIG_NOMMU).
- Establecimiento de configuraciones inseguras en sysctl, opciones de línea de comandos, permisos de acceso en el sistema de archivos, capacidades o apertura de acceso a interfaces privilegiadas para usuarios no privilegiados (por ejemplo, acceso de escritura en procfs y debugfs).
- Problemas en funciones diseñadas únicamente para el desarrollo y la depuración del núcleo, como LOCKDEP, KASAN y FAULT_INJECTION, que no están destinados a incluirse en configuraciones en producción.
- Problemas en los controladores, módulos y subsistemas situados en la sección STAGING o marcados como experimentales, inseguros o inoperativos.
- Uso de módulos de núcleo de terceros o forks no oficiales del núcleo.
- Requisitos de privilegios excesivos, como la necesidad de realizar acciones con derechos de root o de un usuario con 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, costos desproporcionados y configuraciones poco realistas (como sistemas con decenas de miles de núcleos de CPU).
- Evasión de mecanismos de protección (por ejemplo, ASLR) sin demostrar un exploit. Ausencia de comprobaciones de argumentos y códigos de retorno de errores que no tengan consecuencias evidentes.
- Fugas de información aleatorias, incontrolables para los atacantes, como datos residuales en mensajes de error y fugas de direcciones/punteros de memoria del núcleo sin una posibilidad de explotación directa.
- Errores al montar imágenes de disco dañadas, si el controlador no está declarado como apto para su uso con medios no confiables. Problemas con imágenes de disco que se identifican y solucionan mediante la ejecución de la utilidad fsck.
- Ataques que requieren acceso físico al hardware, modificación del hardware o conexión de dispositivos de hardware, como placas para ataques DMA y analizadores lógicos, a menos que el sistema esté específicamente configurado para protegerse contra dichos ataques (IOMMU).
- Regresiones en funcionalidad y rendimiento que pueden solucionarse ajustando permisos y límites.
Fuente: opennet.ru
