El día de ayer se dio a conocer información sobre una vulnerabilidad en el kernel de Linux y la cual ya está catalogada como CVE-2021-3609. Esta vulnerabilidad permite a un usuario local elevar sus privilegios en el sistema debido a una condición de carrera en la implementación del protocolo CAN BCM y se manifiesta en las versiones 2.6.25 a 5.13-rc6 del kernel de Linux.

El fallo se aprovecha debido a que el protocolo CAN BCM permite registrar su propio gestor de mensajes de la red de área del controlador (CAN) y conectarlo a una toma de red específica. Cuando llega un mensaje entrante, se llama a la función bcm_rx_handler() un atacante puede aprovechar una condición de carrera y forzar el cierre del socket de red al mismo tiempo que ejecuta bcm_rx_handler().

El problema viene cuando se cierra el socket y se llama a la función bcm_release(), en la que se libera la memoria asignada para las estructuras bcm_op y bcm_sock, que continúan usándose en el manejador bcm_rx_handler() que aún se está ejecutando, de esta manera surge una situación que conduce al acceso a un bloque de memoria ya liberado (use-after-free).

Este es un anuncio del error recientemente informado (CVE-2021-3609) en el protocolo de red CAN BCM en el kernel de Linux que van desde versión 2.6.25 a mainline 5.13-rc6.
La vulnerabilidad es una condición de carrera en net/can/bcm.c que permite escalada de privilegios a root. El problema fue informado inicialmente por syzbot y Norbert Slusarek demostró ser explotable.

El ataque se reduce a abrir dos sockets CAN BCM y vincularlos a la interfaz vcan. En el primer conector, se llama a sendmsg() con el indicador RX_SETUP para configurar el controlador para los mensajes CAN entrantes y en el segundo conector, se llama a sendmsg() para enviar un mensaje al primer conector.

Después de que llega el mensaje, se activa la llamada bcm_rx_handler() y el atacante toma el momento adecuado y cierra el primer socket, lo que conduce al lanzamiento de bcm_release() y al lanzamiento de las estructuras bcm_op y bcm_sock, aunque el trabajo de bcm_rx_handler() aún no se ha completado.

Al manipular el contenido de bcm_sock, un atacante puede anular un puntero a la función sk-> sk_data_ready (sk), redirigir la ejecución y, utilizando técnicas de programación orientada al retorno (ROP), sobrescribir el parámetro modprobe_path y hacer que su código se ejecute como root.

Cuando se utiliza la técnica ROP, el atacante no intenta colocar su código en la memoria, sino que opera sobre las piezas de las instrucciones de la máquina que ya están disponibles en las bibliotecas cargadas, terminando con una instrucción de retorno de control (como regla, estos son el final de la biblioteca funciones).

Los permisos necesarios para llevar a cabo un ataque pueden ser adquiridos por un usuario sin privilegios en contenedores creados en sistemas con espacios de nombre de usuario habilitados. Por ejemplo, los espacios de nombres de usuario se incluyen de forma predeterminada en Ubuntu y Fedora, pero no se activan en Debian y RHEL.

Mi intento de explotación se concentra en kernels con versión> = 5.4-rc1 desde la confirmación bf74aa86e111. No investigué sobre la explotación de núcleos más antiguos que 5.4-rc1 que usaba tasklets, sin embargo la explotación en kernels más antiguos también parece factible. 

Se menciona que el investigador que identificó la vulnerabilidad pudo preparar un exploit para obtener derechos de root en sistemas con kernels desde la versión 5.4 y posteriores, incluida la posibilidad de un ataque exitoso en Ubuntu 20.04.02 LTS.

El trabajo del exploit se reduce a construir una cadena de llamadas a bloques similares («gadgets») para obtener la funcionalidad requerida. El ataque requiere acceso para crear sockets CAN y una interfaz de red vcan configurada.

Finalmente se menciona que el problema aún persiste en la mayoría de las distribuciones, pero es cuestión de dias para que los parches correspondientes estén siendo liberados.

Si estás interesado en poder conocer más al respecto, puedes consultar el siguiente enlace.