CVE-2022-1015 & CVE-2022-1026

Este README.md es una traducción del blog de David. David encontró los CVE's 1015 y 1016 en el kernel de Linux. Puedes visitar su página web para leer el documento original.

Aquí te dejo sus redes sociales:

• Twitter
• Github

Un análisis de las dos nuevas vulnerabilidades de Linux en nf_tables

Publicado el 2 de abril del 2022.

• CVE-2022-1015 permite realizar un acceso out-of-bounds (fuera del límites) causado por escasas validaciones de argumentos de entrada, puede derivar en la ejecución de código remoto y a una escalación de privilegios local.
• CVE-2022-1016 está relacionado a una pobre de inicialización de las variables alojadas en el stack, lo que puede ser usado para filtrar una larga variedad de datos del kernel al espacio del usuario (userspace).

Estos problemas deberían ser explotabes en las configuraciones por defecto de la versión más nueva de Ubuntu y de RHEL. Escribí mi prueba de concepto (PoC) del CVE-2022-1015 tomando como objetivo la versión del kernel 5.16-rc3 de Arch Linux.

Este documento está dirigido a las personas que tengan un conocimiento básico del kernel de Linux en términos de funcionalidad y seguridad. Traté de hacer que este documento sea amigable con las personas que carezcan de conocimientos con el stack de redes para hacerlo accesible a todo público.

Aquí está una guía de lectura:

• Si estás aquí simplemente para leer acerca de la vulnerabilidad, empiezan en la Sección 4
• Si también quieres un poco de contexto acerca del subsistema del kernel, empieza con la Sección 2
• Si estás interesado en un poco más de contexto adicional, lee todo el documento

1. Contexto

A mediados de febrero, el programa de seguridad de Google anunció que continuarían su programa de recompensas kCTF, ofreciendo recompensas que llegan desde los $31,337 hasta 91,337 dólares por un exploit en el kernel de Linux que pueda escalar privilegios al usuario root desde procesos sin privilegios en un sandbox de nsjail.

Siendo un pobre estudiante, obviamente esto captó mi atención. Esta era mi primera vez buscando buscando una vulnerabilidad del "mundo real", pero en mis aventuras jugando CTF con mi equipo, me he familiarizado con el kernel de Linux en términos de seguridad. Después de horas y horas con muy poco cercano a nada de progreso (pero con mayor conocimiento acerca de Linux) logré encontrar algunas vulnerabilidades en el módulo de nf_tables.

Tristemente, al final del día, me di cuenta de que este módulo no estaba presente en las reglas del kCTF de Google (por lo que no conseguí ninguna recompensa por estas dos vulnerabilidades). Pero obviamente, aún y así las reporté y escribí un exploit LPE (Escalado de Privilegios Local) para el CVE-2022-1015.

1.1 Identificando el objetivo y la estrategia de auditoría

Bien, así que has decidido que vas a encontrar algunas vulnerabilidades en Linux. ¿Ahora qué? Linux es un proyecto gigantezco, y es bastante fácil no poder ver el bosque por los árboles (te enfocas tanto en los detalles que pierdes visión de lo que es realmente importante, no tienes una vista general de la situación). Para empeorar las cosas, muchas partes no está documentadas y necesitas leer un montón de código para poder entender lo que está pasando.

Yo comencé intentando tener una perspectiva detallada del modelo de seguridad de Linux. Encontrar un bug es una cosa; pero encontrar un buen bug es otra muy distinta. Después de todo, no todos los bugs están creados igual:

• Si un bug requiere privilegios root, no existe un límite de seguridad significativo (a menos de que el kernel module signing esté activado)
  • Algunas cosas que se me vienen a la mente son muchos de los módulos de los sistemas de ficheros (virtuales). Solo el usuario root inicial puede montar estos sistemas de ficheros. La excepción recae en vfe que específica FS_USERNS_MOUNT, en cuyo caso puedes montarlos en el user namespace.
• Si un no se puede acceder a un bug a través de las llamadas al sistema, probablemente no podrá ser explotable.
  • Esto aplica a muchos de los drivers de hardware, ya que no tienes acceso físico a la máquina. Los drivers de red de bajo nivel todavía podrían ser un buen objetivo si es que puedes p. ej. enviar datos a través de bluetooth o 802.11.ac.
  • Obviamente esto depende del escenario en el que te encuentres.
• Muchos bugs requieren CAP_SYS_ADMIN o CAP_NET_ADMIN.
  • Los user namespaces (espacio de nombre) están activados por defecto así que esto no es un problema.
  • De lo contrario primero tendrás que hacer un escalado de privilegios al namespace (espacio de nombre) del usuario root dentro de un contenedor.
• No todos los módulos estarán presentes en tu objetivo.
  • Linux es un pedazo de software excepcional altamente configurable, por lo que todas las configuraciones pueden variar de una gran multitud de formas.
  • La configuración del kernel usualmente se puede acceder desde /proc/config.gz. Los módulos pueden ser cargados en (=m) o compilados por separado y cargados en tiempo de ejecución (=y).
  • Puedes usar /proc/modules y /proc/kallsyms, pero siempre son confiables, ya que los módulos pueden ser cargados dinámicamente en el kernel (p. ej. request_module).
  • Si no estás seguro, escribe un pequeño programa que intente interactuar con el módulo.

Estas restricciones nos ayudan a saber los límites de los sistemas de archivos en los cuáles podemos buscar vulnerabilidades. Creo que es una buena idea tomarte tu tiempo tratando de planear tu ataque al objetivo que desees.

Ya he aprendido mi lección acerca del punto anterior. Como mencioné, el módulo nf_tables no estaba cargado en la instancia que nos presentó kCTF. Pude haberme dado cuenta de esto desde un principio y ahorrarme la decepción :p. Por otra parte, probablemente no estarías leyendo este blog ahora mismo si me hubiese dado cuenta antes, supongo que las cosas salieron bien después de todo.

Una explicación por la cuál el COS, Google's container-optimazed Linux fork, no tuviera nf_tables puede ser encontrada aquí y aquí.

1.2 nf_tables: ¿por qué?

Después de evaluar los puntos anteriormente mencionados, decidí que mi mejor ruta para comenzar probablemente sería mirar el código fuente de la red. Muchas de las funcionalidades interesantes allí necesitan CAP_NET_ADMIN, pero como lo mencioné, esto en realidad no es un problema. Por el contrario, sospecho que los componentes que requieren capacidades especiales son por lo general menos seguros, ya que los desarrolladores del kernel pueden tener una falsa sensación de seguridad.