Hace algunos dias investigadores de Checkpoint dieron a conocer la noticia de que han identificado tres vulnerabilidades (CVE-2021-0661, CVE-2021-0662, CVE-2021-0663) en el firmware de los chips DSP de MediaTek, así como una vulnerabilidad en la capa de procesamiento de audio de MediaTek Audio HAL (CVE- 2021-0673). En caso de una explotación exitosa de las vulnerabilidades, un atacante puede organizar la escucha clandestina del usuario desde una aplicación sin privilegios para la plataforma Android.
En 2021, MediaTek representa aproximadamente el 37% de los envíos de chips especializados para teléfonos inteligentes y SoC (según otros datos, en el segundo trimestre de 2021, la participación de MediaTek entre los fabricantes de chips DSP para teléfonos inteligentes fue del 43%).
Entre otras cosas, los chips MediaTek DSP se utilizan en los teléfonos inteligentes insignia de Xiaomi, Oppo, Realme y Vivo. Los chips MediaTek, basados en el microprocesador Tensilica Xtensa, se utilizan en teléfonos inteligentes para realizar operaciones como procesamiento de sonido, imágenes y video, en computación para sistemas de realidad aumentada, visión por computadora y aprendizaje automático, así como para implementar carga rápida.
La ingeniería inversa del firmware para los chips DSP de MediaTek basados en la plataforma FreeRTOS reveló varias formas de ejecutar código en el lado del firmware y obtener control sobre las operaciones DSP mediante el envío de solicitudes especialmente diseñadas desde aplicaciones sin privilegios para la plataforma Android.
Se demostraron ejemplos prácticos de ataques en un Xiaomi Redmi Note 9 5G equipado con MediaTek MT6853 SoC (Dimensity 800U). Se observa que los OEM ya han recibido correcciones de vulnerabilidades en la actualización de firmware de octubre de MediaTek.
El objetivo de nuestra investigación es encontrar una forma de atacar el DSP de audio de Android. Primero, debemos comprender cómo se comunica Android que se ejecuta en el procesador de aplicaciones (AP) con el procesador de audio. Obviamente, debe haber un controlador que espere las solicitudes del espacio de usuario de Android y luego, utilizando algún tipo de comunicación entre procesadores (IPC), reenvíe estas solicitudes al DSP para su procesamiento.
Usamos un teléfono inteligente Xiaomi Redmi Note 9 5G rooteado basado en el chipset MT6853 (Dimensity 800U) como dispositivo de prueba. El sistema operativo es MIUI Global 12.5.2.0 (Android 11 RP1A.200720.011).
Como solo hay unos pocos controladores relacionados con los medios presentados en el dispositivo, no fue difícil encontrar el controlador responsable de la comunicación entre el AP y el DSP.
Entre los ataques que se pueden llevar a cabo ejecutando su código a nivel del firmware del chip DSP:
- Escalada de privilegios y omisión del sistema de control de acceso: captura invisible de datos como fotos, videos, grabaciones de llamadas, datos de un micrófono, GPS, etc.
- Denegación de servicio y acciones maliciosas: bloquear el acceso a la información, deshabilitar la protección contra sobrecalentamiento durante la carga rápida.
- Ocultar actividad maliciosa: crear componentes maliciosos completamente invisibles e indelebles que se ejecutan a nivel de firmware.
- Adjuntar etiquetas para espiar a un usuario, como agregar etiquetas sutiles a una imagen o video para luego vincular los datos publicados al usuario.
Los detalles de la vulnerabilidad en MediaTek Audio HAL aún no se han revelado, pero las otras tres vulnerabilidades en el firmware DSP son causadas por una verificación de borde incorrecta al procesar mensajes IPI (Inter-Processor Interrupt) enviados por el controlador de audio audio_ipi al DSP.
Estos problemas permiten provocar un desbordamiento de búfer controlado en los manejadores proporcionados por el firmware, en los que la información sobre el tamaño de los datos transmitidos se tomó de un campo dentro del paquete IPI, sin verificar el tamaño real asignado en la memoria compartida.
Para acceder al controlador durante los experimentos, usamos llamadas ioctls directas o la biblioteca /vendor/lib/hw/audio.primary.mt6853.so, que son inaccesibles para las aplicaciones regulares de Android. Sin embargo, los investigadores encontraron una solución para enviar comandos basados en el uso de opciones de depuración disponibles para aplicaciones de terceros.
Los parámetros especificados se pueden cambiar llamando al servicio de Android AudioManager para atacar las bibliotecas HAL de MediaTek Aurisys (libfvaudio.so), que proporcionan llamadas para interactuar con el DSP. Para bloquear esta solución, MediaTek eliminó la capacidad de usar el comando PARAM_FILE a través de AudioManager.
Finalmente si estás interesado en conocer más al respecto, puedes consultar los detalles en el siguiente enlace.