Proyecto Openwall lanzamiento del módulo del núcleo (Linux Kernel Runtime Guard), diseñado para detectar y bloquear ataques y violaciones de integridad de las estructuras del núcleo. Por ejemplo, el módulo puede proteger contra modificaciones no autorizadas en un núcleo en funcionamiento y contra intentos de cambiar los privilegios de los procesos de usuario (definición de aplicación de exploits). El módulo es adecuado tanto para protegerse contra exploits ya conocidos para el núcleo de Linux (por ejemplo, en situaciones donde es problemático actualizar el núcleo en el sistema), como para contrarrestar exploits para vulnerabilidades aún desconocidas. Código del proyecto bajo la licencia GPLv2.
Entre los cambios en la nueva versión:
- Se ha cambiado el posicionamiento del proyecto LKRG, que ahora no se divide en subsistemas separados para la verificación de integridad y la identificación de aplicación de exploits, sino que se presenta como un producto completo para detectar ataques y diversas violaciones de integridad;
- Se ha garantizado la compatibilidad con núcleos de Linux desde 5.3 hasta 5.7, así como con núcleos compilados con optimizaciones agresivas de GCC, sin las opciones CONFIG_USB y CONFIG_STACKTRACE o con la opción CONFIG_UNWINDER_ORC, así como con núcleos que no tienen funciones interceptadas de LKRG, cuando se puede prescindir de ellas;
- Al compilar, se ha asegurado la verificación de algunas configuraciones obligatorias del núcleo CONFIG_* para generar mensajes de error significativos en lugar de fallos poco claros;
- Se ha agregado soporte para los modos de espera (ACPI S3, suspend to RAM) y de suspensión (S4, suspend to disk);
- Se ha agregado soporte DKMS en el Makefile;
- Se ha implementado soporte experimental para plataformas ARM de 32 bits (probado en Raspberry Pi 3 Model B). El soporte previamente disponible para AArch64 (ARM64) se ha ampliado para garantizar la compatibilidad con la placa Raspberry Pi 4;
- Se han añadido nuevos ganchos (hook), incluido el gestor de llamadas capable() para una mejor identificación de exploits que manipulan ««, en lugar de identificadores de procesos ();
- Se ha propuesto una nueva lógica para detectar intentos de salir de las restricciones de espacios de nombres (por ejemplo, de contenedores Docker);
- En sistemas x86-64 se ha garantizado la verificación y aplicación del bit SMAP (Supervisor Mode Access Prevention), diseñado para bloquear el acceso a datos en el espacio de usuario desde código privilegiado que se ejecuta en el nivel del núcleo. La protección SMEP (Supervisor Mode Execution Prevention) se implementó anteriormente;
- Durante el proceso de trabajo, se ha asegurado el alojamiento de la configuración de LKRG en una página de memoria, generalmente accesible solo para lectura;
- La salida de los registros de información que puede ser más útil para los ataques (por ejemplo, información sobre direcciones en el núcleo) está limitada al modo de depuración (log_level=4 y superior), que está desactivado por defecto.
- Se ha mejorado la escalabilidad de la base de datos de seguimiento de procesos: en lugar de un solo árbol RB protegido por un solo spinlock, se ha implementado una tabla hash de 512 árboles RB, protegidos por 512 bloqueos de lectura-escritura respectivamente;
- Se ha implementado y habilitado por defecto un modo en el cual la verificación de la integridad de los identificadores de proceso se realiza con frecuencia solo para la tarea actual, así como opcionalmente para las tareas activadas (despertadas). Para otras tareas que están en estado de sueño o funcionan sin interacciones con el API controlado de LKRG en el núcleo, la verificación se realiza con menos frecuencia.
- Se han añadido nuevos sysctl y parámetros de módulo para la personalización de LKRG, así como dos sysctl para facilitar la configuración mediante la selección de conjuntos de configuraciones finas preparadas por los desarrolladores (perfiles);
- Se han cambiado las configuraciones por defecto para lograr un equilibrio más ponderado entre la rapidez de detección de infracciones y la efectividad de respuesta por un lado, y el impacto en el rendimiento y el riesgo de falsos positivos por el otro;
- El archivo unit de systemd ha sido rediseñado para cargar el módulo LKRG en una etapa temprana de arranque (se puede usar un parámetro de línea de comando del núcleo para desactivar el módulo);
Con respecto a las optimizaciones propuestas en la nueva versión, la disminución del rendimiento al aplicar LKRG 0.8 se estima en un 2.5% en modo por defecto (‘heavy’) y un 2% en modo ligero (‘light’).
En el reciente efectividad de los paquetes para detectar rootkits LKRG Los mejores resultados, sin falsas alarmas, identificaron 8 de 9 rootkits probados que operan a nivel de núcleo (se identificaron los rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit y Sutekh, pero se pasó por alto Keysniffer, que es un módulo de núcleo con keylogger, no un rootkit en el sentido estricto). En comparación, los paquetes AIDE, OSSEC y Rootkit Hunter detectaron 2 rootkits de 9, mientras que Chkrootkit no detectó ninguno. A su vez, LKRG no soporta la detección de rootkits alojados en el espacio de usuario, por lo que la mayor eficacia se logra utilizando la combinación de AIDE y LKRG, que permitió identificar 14 de 15 rootkits de todos los tipos.
Además, se puede destacar que el desarrollador de la distribución comenzó paquetes listos con DKMS para Debian, Whonix, Qubes y Kicksecure, y el paquete para ya se ha actualizado a la versión 0.8. Los paquetes de LKRG también están presentes en los y .
La verificación de integridad en LKRG se realiza mediante la comparación del código y los datos actuales del núcleo y los módulos, algunas estructuras de datos y configuraciones importantes de la CPU con los hashes guardados o copias de las áreas de memoria, estructuras de datos o registros correspondientes. Las verificaciones se activan tanto periódicamente por un temporizador como al ocurrir ciertos eventos.
La identificación de posibles explotaciones y la bloqueo de ataques se realiza en la etapa previa a que el núcleo proporcione acceso a los recursos (por ejemplo, antes de abrir un archivo), pero después de que el proceso haya obtenido privilegios no autorizados (por ejemplo, cambio de UID). Al detectarse un comportamiento no autorizado de los procesos, por defecto se llevan a cabo su finalización forzada, lo que es suficiente para bloquear muchas explotaciones.
Fuente: opennet.ru
