Explotación de firmware de Android: firmware sin firmar en el SoC CVE-2020-10831 de Samsung

TL; DR  

Explicaremos cómo explotamos el firmware de Android utilizando una API de kernel no documentada que se encontró mediante ingeniería inversa de la aplicación "Configuración de fábrica oculta" de Samsung.
Esta API permite actualizar el firmware sin firmar del firmware de la pantalla táctil de Samsung.
El CVE afecta a todas las series Samsung S7-S10 que usan el chipset exynos.

Inspiración  

Después de leer el proyecto cero gran artículo sobre la explotación del firmware WiFi para obtener RCE, decidí que debería intentar hacer una exploración de firmware por mi cuenta. 

Descripción general del SoC  

Los teléfonos en estos días tienen mucho más que solo 1 CPU que ejecuta el sistema operativo Android, lo que los convierte en sistemas extremadamente complejos. 

La mayoría de los teléfonos Android tienen de 10 a 30 "computadoras" diferentes en su interior, cada una con su propia CPU, memoria y almacenamiento. 

Todas estas unidades se comunican a través de diferentes protocolos de comunicación de hardware como IPC, I2C, etc. 

Las principales unidades de procesamiento en los teléfonos Android son:

AP / Procesador de aplicaciones – Esta es la CPU principal que conoce de las especificaciones del teléfono que se comunica y administra todas las demás unidades de procesamiento y ejecuta el sistema operativo Android. 

BP / Procesador de banda base / Radio / Módem – El BP es responsable de convertir todos los datos celulares recibidos de las ondas de radio en información utilizable por software mediante la implementación de la pila LTE. 

GPU - La unidad de procesamiento de gráficos es responsable de manejar todas las tareas relacionadas con los gráficos.

Hay más unidades de procesamiento como wifi, criptografía, cámara, audio, etc. 

Todos estos componentes juntos llamados "System on Chip" - SoC

Encontrar un objetivo vulnerable 

La explotación del firmware de Android es difícil ya que tenemos muy poco conocimiento previo de la arquitectura del firmware y cómo se comunica el sistema operativo con él. 

Por lo tanto, usar una pista de información del fabricante puede hacer que la investigación sea tremendamente más fácil. 

Después de buscar en Google las pistas mencionadas, muchos foros mencionaron el problema de la pantalla táctil de Samsung y cómo solucionarlo. 
El método era relativamente simple:

"Primero vaya a la configuración oculta escribiendo *#2663# en la aplicación del teléfono y luego haga clic en actualizar FW".

Encontrar cómo comunicarse con el firmware

Como se mencionó anteriormente, usar el conocimiento del fabricante sería mucho más fácil que calcular todo por nosotros mismos. 

Al ejecutar strace en la aplicación de Android, que es responsable de la actualización del firmware, puede ver fácilmente que después de hacer clic en el botón de actualización, la aplicación escribe en la siguiente ruta

“/sys/clase/seg/tsp/cmd”

Esta ruta es parte del mecanismo sysfs del kernel. 

sysfs es un pseudo sistema de archivos proporcionado por el kernel de Linux que exporta información sobre los controladores de dispositivos asociados. 

Aquí podemos ver cómo comunicarse con el kernel desde el archivo cmd:

Escribir el nombre de la función, por ejemplo, "fw_update" y luego el parámetro "1", dará como resultado una actualización del firmware de la pantalla táctil como se usa en la aplicación de configuración oficial de fábrica. 
Pero para comprender completamente la funcionalidad de los mecanismos de actualización de firmware, debemos descargar el núcleo y mire el código del controlador del dispositivo. 
Después de examinar el código fuente del kernel que maneja el comando anterior, el siguiente comentario reveló una funcionalidad muy interesante. 

Aparentemente, al escribir:

“echo -n "firmware_update:0" > /sys/class/sec/tsp/cmd”

El parámetro 0 informa al núcleo desde qué lugar actualizar el firmware.

Como muestra el comentario del código del kernel, pasar 2 hará que el kernel actualice el firmware desde UMS (tarjeta SD). 
Una mirada más profunda en la fuente del kernel mostrará la ruta requerida:

Proceso de Explotación 

Para verificar si podemos actualizar el firmware sin firmar / mal formado, todo lo que tenemos que hacer es probar y ver qué sucede.

(En general, es mejor modificar solo las cadenas legibles por humanos, como un mensaje de registro, para no interrumpir el proceso de ejecución del programa, lamentablemente elegí la forma más tonta)

El comando

El resultado impreso en el registro del kernel (kmsg)

En esta parte de la investigación, no estaba 100 por ciento seguro de que funcionara, pero después de intentar hacer clic en mi dispositivo personal y ver toneladas de errores de E/S en el kmsg (en lugar de simplemente hacer clic), entendí que simplemente actualicé correctamente el firmware de la pantalla táctil con formato incorrecto. , vuala! 

Nota interesante sobre fuzzing 

Al encontrar la API del archivo cmd, mi primer pensamiento fue "¡Vamos a fusearlo y encontrar algunos desbordamientos!"

Pero el registro dice claramente que la entrada es demasiado larga y se eliminó para evitar desbordamientos. 

Este parche se debe a vulnerabilidad encontrado por el mismo investigador del artículo del proyecto cero que me inspiró a hacer la investigación.