Reforzamiento adicional de las GPUs de Android

Publicado por Liz Prucka, Hamzeh Zawawy, Rishika Hooda, Equipo de Seguridad y Privacidad de Android. El año pasado, el equipo Red de Android de Google se asoció con Arm para realizar un análisis de seguridad en profundidad de la GPU Mali, un componente utilizado en miles de millones de dispositivos Android en todo el mundo. Esta colaboración fue un paso importante para identificar y solucionar de forma proactiva las vulnerabilidades en la pila de software y firmware de la GPU. Si bien encontrar y solucionar errores individuales es crucial, y el progreso continúa eliminándolos por completo, restringir la superficie de ataque es otra forma eficaz y a menudo más rápida de mejorar la seguridad. Esta publicación detalla nuestros esfuerzos en colaboración con Arm para endurecer aún más la GPU reduciendo la superficie de ataque del controlador. La amenaza creciente: ¿Por qué es importante la seguridad de la GPU. La Unidad de Procesamiento Gráfico (GPU) se ha convertido en un objetivo crítico y atractivo para los atacantes debido a su complejidad y acceso privilegiado al sistema. La escala de esta amenaza es significativa: desde 2021, la mayoría de las explotaciones basadas en controladores de kernel de Android se han dirigido a la GPU. Estas explotaciones se dirigen principalmente a la interfaz entre el Controlador de Modo de Usuario (UMD) y el Controlador de Modo de Kernel (KMD) altamente privilegiado, donde las fallas pueden ser explotadas mediante entradas maliciosas para provocar corrupción de la memoria. Asociación con Arm. Nuestro objetivo es elevar el listón en la seguridad de la GPU, asegurando que el controlador Mali y el firmware permanezcan altamente resistentes a posibles amenazas. Nos asociamos con Arm para analizar el controlador Mali, que se utiliza en aproximadamente el 45% de los dispositivos Android. Esta colaboración fue crucial para comprender la superficie de ataque del controlador e identificar áreas que plantean riesgos de seguridad, pero que no son necesarias para el uso de producción. La herramienta adecuada para el trabajo: endurecimiento con SELinux. Uno de los hallazgos clave de nuestra investigación fue la oportunidad de restringir el acceso a ciertas IOCTLs. Las IOCTLs actúan como la entrada y salida del controlador del kernel de GPU, así como la superficie de ataque. Este enfoque se basa en los esfuerzos anteriores de endurecimiento del kernel, como los descritos en la publicación de 2016, Protegiendo Android con más seguridad de Linux. Las IOCTLs de Mali se pueden categorizar ampliamente como: Privilegiadas: necesarias para el funcionamiento normal. Instrumentación: utilizadas por los desarrolladores para el perfilado y la depuración. Restringidas: no deben ser utilizadas por las aplicaciones en producción. Esto incluye las IOCTLs que están destinadas únicamente al desarrollo de GPU, así como las IOCTLs que han sido derogadas y ya no son utilizadas por la versión actual del Controlador de Modo de Usuario (UMD) del dispositivo. Nuestro objetivo es bloquear el acceso a las IOCTLs derogadas y de depuración en producción. IOCTLs de instrumentación: están destinadas al uso por herramientas de perfilado para supervisar el rendimiento de la GPU del sistema y no están destinadas a ser utilizadas directamente por las aplicaciones en producción. Como tal, el acceso está restringido a shells o aplicaciones marcadas como depurables. Las IOCTLs de producción siguen siendo accesibles para las aplicaciones regulares. Un despliegue por etapas. Este enfoque es iterativo y es un despliegue por etapas para los dispositivos que utilizan la GPU Mali. De esta manera, pudimos supervisar cuidadosamente el uso en el mundo real y recopilar datos para validar la política, minimizando el riesgo de romper aplicaciones legítimas antes de adoptar una adopción más amplia: Política opt-in: Comenzamos con una política de opt-in. Creamos un nuevo atributo SELinux, gpu_harden, que prohibía las IOCTLs de instrumentación. Luego, aplicamos selectivamente este atributo a ciertas aplicaciones del sistema para probar el impacto. Utilizamos la regla allowxperm para auditar, pero no para denegar, el acceso al recurso previsto, y supervisamos los registros de denegación para garantizar que no haya interrupciones. Política de exclusión: Una vez que estuvimos seguros de que nuestro enfoque era sólido, pasamos a una política de exclusión. Creamos un dominio gpu_debug que permitiría el acceso a las IOCTLs de instrumentación. Todas las aplicaciones se endurecieron por defecto, pero los desarrolladores podían optar por excluirlo al: Ejecutar en un dispositivo enraizado. Establecer el atributo android:debuggable=true en el manifiesto de su aplicación. Solicitar una excepción permanente en la política SELinux para su aplicación. Este enfoque nos permitió implementar ampliamente la nueva política de seguridad, minimizando el impacto en los desarrolladores. Instrucciones paso a paso sobre cómo agregar su Sepolicy. Para ayudar a nuestros socios y al ecosistema más amplio a adoptar medidas de endurecimiento similares, esta sección proporciona una guía práctica y paso a paso para implementar una política SELinux robusta para filtrar las IOCTLs de la GPU. Este ejemplo se basa en la política que implementamos para la GPU Mali en dispositivos Android. El principio fundamental es crear una macro de nivel de plataforma que permita a cada dispositivo definir sus propios conjuntos específicos de comandos de IOCTL que se van a restringir. Este enfoque separa la lógica de política general de la implementación específica del dispositivo. La documentación oficial que detalla la macro y la política de seguridad de GPU está disponible en: Macro de endurecimiento SELinux: Filtrado de llamadas de sistema de GPU: Cambios de seguridad de Android: Android 16. Paso 1: Utilizar la macro de nivel de plataforma. El primer paso es utilizar una macro genérica que construimos en el sistema/sepolicy de la plataforma que se puede utilizar para cualquier dispositivo. Esta macro establece el marco para filtrar diferentes categorías de IOCTLs. En el archivo/sepolicy/public/te_macros, se crea una nueva macro. Esta macro permite que las políticas específicas del dispositivo proporcionen sus propias listas de IOCTLs para filtrar. La macro está diseñada para: Permitir que todas las aplicaciones (appdomain) accedan a una lista definida de IOCTLs privilegiadas. Restringir el acceso a IOCTLs de instrumentación sensibles, permitiéndolos solo para herramientas de depuración como shells o runas_app cuando la aplicación es depurable. Bloquear el acceso a IOCTLs privilegiados en función de la versión del SDK objetivo de la aplicación, manteniendo la compatibilidad para aplicaciones más antiguas. Paso 2: Definir listas de IOCTL específicas del dispositivo. Con la macro de la plataforma en su lugar, puede ahora crear una implementación específica del dispositivo. Esto implica definir los comandos de IOCTL exactos que utiliza su controlador de GPU específico. Cree un archivo ioctl_macros en el directorio sepolicy de su dispositivo (p. ej., device/your_company/your_device/sepolicy/ioctl_macros). Defina las listas de IOCTL dentro de este archivo, categorizándolas según sea necesario. Basándonos en nuestro análisis, recomendamos al menos mali_production_ioctls, mali_instrumentation_ioctls, y mali_debug_ioctls. Estas listas contendrán los números de IOCTL hexadecimales específicos de su controlador. Por ejemplo, puede definir sus listas de IOCTL de la siguiente manera: define(unpriv_gpu_ioctls', 0x0000, 0x0001, 0x0002’) define(restricted_ioctls', 0x1110, 0x1111, 0x1112’) define(instrumentation_gpu_ioctls', 0x2220, 0x2221, 0x2222’) Arm ha proporcionado la categorización oficial de sus IOCTL en Documentation/ioctl-categories.rst de su versión r54p2. Esta lista continuará siendo mantenida en versiones futuras del controlador. Paso 3: Aplicar la política a la GPU Device. Ahora aplica la política al nodo de dispositivo de GPU utilizando la macro que creó. Cree un archivo gpu.te en el directorio sepolicy de su dispositivo. Llama a la macro de la plataforma desde dentro de este archivo, pasando la etiqueta del dispositivo y las listas de IOCTL que acaba de definir. Paso 4: Probar, refinar y hacer cumplir. Como con el desarrollo de cualquier política SELinux, el proceso debe ser iterativo. Este proceso iterativo es consistente con las mejores prácticas para el desarrollo de políticas SELinux, según la documentación del Android Open Source Project. Conclusión: la reducción de la superficie de ataque es un enfoque eficaz de endurecimiento, que hace que las vulnerabilidades sean inaccesibles. Esta técnica es particularmente eficaz porque proporciona una fuerte protección contra vulnerabilidades existentes, así como aquellas que aún no existen y que podrían introducirse en el futuro. Este esfuerzo abarca Android y los fabricantes de Android OEMs, y requiere una estrecha colaboración con Arm. El equipo de seguridad de Android está comprometido a colaborar con los socios del ecosistema para promover la adopción más amplia de este enfoque para endurecer la GPU. Reconocimientos. Gracias a Jeffrey Vander Stoep por sus valiosos comentarios y sugerencias en esta publicación.