Los ingenieros de Google dieron a conocer mediante una publicación que han identificado una vulnerabilidad grave (CVE-2020-12351) en la pila de Bluetooth «BlueZ» la cual es utilizada en las distribuciones de Linux y Chrome OS.

La vulnerabilidad, cuyo nombre en código es BleedingTooth, permite a un atacante no autorizado ejecutar su código en el nivel del kernel de Linux sin la intervención del usuario mediante el envío de paquetes Bluetooth especialmente diseñados.

El problema puede ser aprovechado por un atacante que se encuentre dentro del alcance de Bluetooth y además de que no se requiere que exista un emparejamiento previo entre el dispositivo atacante y la victima, la única condición es que el Bluetooth debe estar activo en la computadora.

Sobre la vulnerabilidad

Para un ataque, es suficiente conocer la dirección MAC del dispositivo de la víctima, que puede determinarse mediante el rastreo o, en algunos dispositivos, calcularse en función de la dirección MAC de Wi-Fi.

La vulnerabilidad está presente en componentes que procesan paquetes L2CAP (protocolo de adaptación y control de enlace lógico) a nivel del kernel de Linux.

Al enviar un paquete L2CAP especialmente diseñado con datos adicionales para el canal A2MP, un atacante puede sobrescribir un área fuera de la memoria asignada, que potencialmente se puede usar para crear un exploit para ejecutar código arbitrario a nivel del kernel.

Al especificar un CID que no sea L2CAP_CID_SIGNALING, L2CAP_CID_CONN_LESS y L2CAP_CID_LE_SIGNALING en el paquete, el controlador 2cap_data_channel () se llama en BlueZ, que para los canales en los modos L2CAP_MODE_ERTM y L2_CAP_CAP_ Si la suma de comprobación coincide, se llama al filtro de canal sk_filter (). Para paquetes con CID L2CAP_CID_A2MP, no hay canal, por lo que para crearlo se llama a la función a2mp_channel_create (), que usa el tipo «struct amp_mgr» al procesar el campo de datos chan->, pero el tipo para este campo debe ser «struct sock».

La vulnerabilidad ha surgido desde el kernel de Linux 4.8 y, a pesar de las afirmaciones de Intel, no se ha abordado en la versión 5.9 publicada recientemente.

Matthew Garrett, un conocido desarrollador del kernel de Linux que recibió un premio de la Free Software Foundation por su contribución al desarrollo de software libre, afirma que la información que contiene el informe de Intel es incorrecta y que el kernel 5.9 no incluye las correcciones adecuadas para corregir la vulnerabilidad  se incluyeron parches en la rama linux-next, no la rama 5.9).

También expresó su indignación por la política de Intel de revelar vulnerabilidades: los desarrolladores de distribuciones de Linux no fueron notificados del problema antes de la publicación del informe y no tuvieron la oportunidad de preexportar parches para sus paquetes con el kernel.

Además, se informa que se han identificado dos vulnerabilidades más en BlueZ:

• CVE-2020-24490 – Desbordamiento del búfer de código de análisis de HCI (hci_event.c). Un atacante remoto puede lograr desbordamientos de búfer y ejecución de código en el nivel del kernel de Linux enviando anuncios de difusión. El ataque solo es posible en dispositivos que admiten Bluetooth 5, cuando el modo de escaneo está activo en ellos.
• CVE-2020-12352 : pérdida de información de la pila durante el procesamiento de paquetes A2MP. El problema puede ser aprovechado por un atacante que conoce la dirección MAC de un dispositivo para recuperar datos de la pila del kernel, que potencialmente podrían contener información confidencial como claves de cifrado. La pila también puede contener punteros, por lo que el problema se puede utilizar para determinar el diseño de la memoria y omitir la protección KASLR (aleatorización de direcciones) en exploits para otras vulnerabilidades.

Finalmente se ha dado a conocer la publicacion de un prototipo de exploit para comprobar el problema.

En las distribuciones, el problema permanece sin parches (Debian, RHEL (vulnerabilidad confirmada en versiones de RHEL a partir de 7.4), SUSE, Ubuntu, Fedora).

La plataforma Android no se ve afectada por el problema, ya que utiliza su propia pila Bluetooth, basado en el código del proyecto BlueDroid de Broadcom.

Si quieres conocer mas al respecto sobre esta vulnerabilidad, puedes consultar los detalles en el siguiente enlace.