Los desarrolladores del proyecto Grsecurity dieron a conocer información sobre problemas de seguridad que fueron encontrados en un parche propuesto para mejorar la seguridad del Kernel de Linux por parte de un empleado de Huawei, la presencia de una vulnerabilidad explotada trivialmente en el conjunto de parches HKSP (Huawei Kernel Self Protection).

Estos parches “HKSP” fueron publicados por un empleado de Huawei hace 5 días e incluyen la mención de Huawei en el perfil de GitHub y usan la palabra Huawei en la decodificación del nombre del proyecto (HKSP – Huawei Kernel Self Protection), aun que el emplado menciona que el proyecto no tiene nada que ver con la compañía y es de autoría propia.

Este proyecto ha realizado mi investigación en el tiempo libre, el nombre de hksp fue dado por mí mismo, no está relacionado con la compañía Huawei, no hay ningún producto Huawei que use este código.

Este código de parche fue creado por mí, ya que una persona no tiene suficiente energía para cubrir todo. Por lo tanto, existe una falta de garantía de calidad como la revisión y prueba.

Sobre HKSP

HKSP incluye cambios tales como aleatorización de compensaciones en la estructura, protección contra ataques en el espacio de nombres de ID de usuario (espacio de nombres pid), separación de la pila de procesos del área mmap, detección de doble llamada a la función kfree, bloqueo de fugas a través del pseudo-FS/proc (/proc/{módulos, claves, usuarios clave}, /proc/sys/kernel/* y /proc/sys/vm/mmap_min_addr,/proc/kallsyms), aleatorización mejorada de direcciones en el espacio del usuario, protección adicional de Ptrace, protección mejorada de smap y smep, la capacidad de prohibir el envío de datos a través de sockets sin procesar, bloqueando direcciones no válidas en sockets UDP y cheques y la integridad de los procesos en ejecución.

La estructura también incluye el módulo del núcleo Ksguard, destinado a identificar intentos de introducir rootkits típicos.

Los parches despertaron interés en Greg Kroah-Hartman, responsable de mantener una rama estable del kernel de Linux, quien le pidió al autor que dividiera el parche monolítico en partes para simplificar la revisión y promoción a la composición central.

Kees Cook (Kees Cook), jefe del proyecto para promover la tecnología de protección activa en el kernel de Linux, también habló positivamente sobre los parches y los problemas llamaron la atención sobre la arquitectura x86 y la naturaleza de notificación de muchos modos que solo registran información sobre el problema, pero no Intenta bloquearlo.

Un estudio del parche realizado por los desarrolladores de Grsecurity reveló muchos errores y debilidades en el código y también mostró la ausencia de un modelo de amenaza que permita una evaluación adecuada de las capacidades del proyecto.

Para ilustrar que el código se escribió sin utilizar métodos de programación seguros, se proporciona un ejemplo de vulnerabilidad trivial en el controlador de archivos /proc/ksguard/state, que se crea con permisos 0777, lo que significa que todos tienen acceso de escritura.

La función ksg_state_write utilizada para analizar los comandos escritos en /proc/ksguard/state crea un búfer tmp [32], en el que los datos se escriben en función del tamaño del operando transferido, sin considerar el tamaño del búfer de destino y sin verificar el parámetro con el tamaño de la cadena. Es decir para sobrescribir parte de la pila del kernel, el atacante solo necesita escribir una línea especialmente diseñada en /proc/ksguard/state.

Al recibir respuesta, el desarrollador comento en la página de GitHub del proyecto “HKSP” retroactivamente después del descubrimiento de vulnerabilidad también agregó una nota de que el proyecto está progresando en su tiempo libre para la investigación.

Gracias al equipo de seguridad por encontrar muchos errores en este parche.
El ksg_guard es un poc de muestra para detectar rootkits a nivel de kernel, la comunicación del usuario y del núcleo es lanzar la interfaz proc, mi propósito de origen es verificar la idea rápidamente, por lo que no agrego suficientes controles de seguridad.

En realidad, verificar el rootkit en el nivel del kernel aún debe discutir con la comunidad, si es necesario diseñar una herramienta ARK (anti rootkit) para el sistema Linux …