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 ā¦