Google recomienda reducir la superficie de ataque de las unidades de procesamiento gráfico en Android restringiendo los comandos IOCTL que las aplicaciones no necesitan en el entorno de producción, en lugar de depender únicamente de la detección y corrección de vulnerabilidades individuales. Esta práctica es resultado de la colaboración entre el equipo Android Red Team y Arm para analizar la unidad Mali GPU y su controlador, con especial atención a impedir el acceso a funciones innecesarias mediante SELinux.
Este paso adquiere importancia desde el punto de vista de la seguridad porque la unidad de procesamiento gráfico se ha convertido en un objetivo atractivo para los atacantes debido a su complejidad y a que posee permisos elevados dentro del sistema. Según el artículo, la mayoría de las explotaciones basadas en controladores del kernel de Android desde 2021 tuvieron como objetivo la unidad de procesamiento gráfico, y los ataques se centraron principalmente en la interfaz entre el controlador en espacio de usuario, conocido como UMD, y el controlador con permisos elevados en espacio del kernel, o KMD.
¿Por qué es prioritario reducir la superficie de ataque?
Las entradas maliciosas que atraviesan esta interfaz pueden aprovechar fallos que provocan corrupción de memoria. Google considera que hacer inaccesibles las rutas innecesarias ofrece un medio eficaz y, a menudo, más rápido de elevar el nivel de protección, en paralelo con la continuidad de la detección y corrección de errores de software.
El análisis conjunto con Arm incluyó el controlador Mali utilizado en aproximadamente el 45 % de los dispositivos Android y ayudó a identificar partes de la superficie de ataque que representan riesgos de seguridad, pero que no son necesarias para ejecutar los dispositivos en producción. Por ello, la política se centró en los comandos IOCTL, que representan las entradas y salidas del controlador de la unidad de procesamiento gráfico y, por tanto, una parte importante de la superficie de ataque.
El enfoque propuesto divide los comandos Mali en tres categorías:
- Comandos sin restricciones: son necesarios para el funcionamiento normal y permanecen disponibles para las aplicaciones.
- Comandos de medición y herramientas: los utilizan las herramientas de análisis del rendimiento y depuración para supervisar el rendimiento de la unidad de procesamiento gráfico.
- Comandos restringidos: no deben ser utilizados por las aplicaciones de producción e incluyen comandos destinados al desarrollo de la unidad de procesamiento gráfico, además de comandos antiguos que ya no se utilizan en la versión actual del UMD del dispositivo.
La política pretende bloquear los comandos antiguos y de depuración en el entorno de producción, limitando los comandos de medición al shell o a las aplicaciones que llevan la marca de depuración. En cambio, los comandos de producción permanecen disponibles para las aplicaciones normales.
Despliegue gradual de una política de SELinux
Google adoptó un enfoque gradual para reducir la probabilidad de interrumpir aplicaciones legítimas. El proceso comenzó con una política opcional y creó un nuevo atributo de SELinux llamado gpu_harden, que bloquea los comandos de medición, para después aplicarlo a un conjunto específico de aplicaciones del sistema con el fin de probar su impacto. Durante esta fase, se utilizó la regla allowxperm para registrar los intentos de acceso en lugar de bloquearlos directamente; posteriormente, se supervisaron los registros de denegación para verificar que no se produjeran fallos.
Tras confirmar la seguridad del enfoque, la política pasó a un modelo predeterminado más estricto, con la creación de un dominio llamado gpu_debug que permite el acceso a los comandos de medición. De este modo, las aplicaciones quedan protegidas de forma predeterminada, con excepciones disponibles para los desarrolladores en casos concretos:
- Ejecutar la aplicación en un dispositivo con permisos root.
- Establecer la propiedad android:debuggable="true" en el archivo de manifiesto de la aplicación.
- Solicitar una excepción permanente en la política de SELinux de la aplicación.
Pasos para aplicar la política en los dispositivos
Google ofrece estas directrices para ayudar a los socios y al ecosistema más amplio a adoptar un mecanismo similar, separando la lógica de la política general de los detalles de cada dispositivo o controlador. El proceso comienza utilizando un módulo de macros general a nivel de la plataforma Android dentro de system/sepolicy. Este módulo se encuentra en el archivo /sepolicy/public/te_macros y permite a las políticas de los dispositivos pasar listas de comandos IOCTL que deben filtrarse.
El módulo está diseñado para permitir que todas las aplicaciones, o appdomain, accedan a la lista de comandos sin restricciones, y para limitar los comandos de medición sensibles a herramientas de depuración como shell o runas_app cuando la aplicación puede depurarse. También bloquea los comandos con permisos elevados según la versión del SDK de destino de la aplicación, manteniendo la compatibilidad con las aplicaciones más antiguas.
A continuación, el desarrollador del dispositivo crea el archivo ioctl_macros dentro de la carpeta de la política de SELinux específica del dispositivo, por ejemplo, device/your_company/your_device/sepolicy/ioctl_macros, y después define las listas de comandos del controlador de la unidad de procesamiento gráfico. Google recomienda contar como mínimo con listas separadas para los comandos de producción, los comandos de medición y los comandos de depuración, que deben incluir los números IOCTL hexadecimales específicos del controlador.
Arm proporcionó una clasificación oficial de sus comandos IOCTL en el archivo Documentation/ioctl-categories.rst dentro de la versión r54p2, indicando que la lista continuará actualizándose con las futuras versiones de los controladores.
Pruebas antes de la aplicación obligatoria
En el siguiente paso, la política se aplica al nodo del dispositivo de la unidad de procesamiento gráfico mediante la creación de un archivo gpu.te en la carpeta de políticas del dispositivo y, posteriormente, la invocación del módulo de macros general pasando la etiqueta del dispositivo y las listas de IOCTL previamente definidas.
Google subraya que el desarrollo de una política de SELinux debe seguir siendo un proceso iterativo que incluya pruebas, depuración y, finalmente, aplicación obligatoria. Este método permite recopilar datos de uso real, detectar los casos que podrían requerir excepciones y ampliar gradualmente el alcance de la política, en lugar de imponer restricciones amplias desde el principio.
Google considera que reducir la superficie de ataque no solo protege frente a vulnerabilidades conocidas, sino que también puede hacer inaccesibles, a través de las rutas restringidas, las vulnerabilidades aún no descubiertas o las que puedan aparecer en el futuro. Ampliar este enfoque requiere la colaboración entre Android, los fabricantes de dispositivos y los socios del ecosistema, mientras que los equipos de seguridad de Android afirmaron estar comprometidos con apoyar la adopción de estas medidas a mayor escala.