Corrupción de memoria en Bluetooth descubierta por GrapheneOS con ARM MTE
(grapheneos.social)- El soporte de etiquetado de memoria por hardware del Pixel 8 y Pixel 8 Pro reveló un bug de corrupción de memoria introducido recientemente en Bluetooth LE en Android 14 QPR2
- Se confirmó que la causa era un bug upstream de use-after-free en Bluetooth LE, y GrapheneOS creó un parche de corrección que planea incluir en una nueva versión
- Un usuario que reprodujo el problema en el modo Bluetooth LE de los Samsung Galaxy Buds2 Pro confirmó que la corrección funciona, y stock Pixel OS también está afectado
- GrapheneOS considera que, dado que Bluetooth es una gran superficie de ataque, desactivar el etiquetado de memoria en ese proceso como solución alternativa no es adecuado ni siquiera a corto plazo
- Parte del código Bluetooth de Android se migró a Rust, pero aún hace falta migrar el código restante y realizar más pruebas en dispositivos reales con builds HWASan y MTE
Bug de Bluetooth LE en Android 14 QPR2 y su corrección
- GrapheneOS descubrió un bug de corrupción de memoria en Bluetooth LE de Android 14 QPR2 gracias al soporte de etiquetado de memoria por hardware del Pixel 8 y Pixel 8 Pro
- No ocurre con todos los dispositivos Bluetooth; solo se reproduce con ciertos dispositivos Bluetooth LE
- GrapheneOS está investigando cómo corregir o desactivar temporalmente la función recién introducida
- Se confirmó que la causa era un bug upstream de use-after-free en Bluetooth LE, y GrapheneOS desarrolló un parche
- La prioridad es distribuir rápidamente una versión de GrapheneOS que incluya esa corrección
- Se planea reportarlo como bug de seguridad de Android
- Esta corrección también parece resolver la regresión de audio BLE
- Un usuario que reproducía el problema usando los Samsung Galaxy Buds2 Pro en modo Bluetooth LE confirmó que la corrección funciona
- El mismo problema también afecta a stock Pixel OS
- GrapheneOS lo detectó gracias al soporte de etiquetado de memoria de hardened_malloc y agregó una notificación de crash de MTE con un reporte copiable
Forma de aplicar MTE y desafíos del código Bluetooth de Android
- GrapheneOS considera que desactivar el etiquetado de memoria en este proceso como solución alternativa no es adecuado ni siquiera a corto plazo
- Bluetooth es una gran superficie de ataque, independientemente de la posibilidad real de explotar este bug
- Android migró una parte importante del código Bluetooth a Rust, pero se necesitan más recursos para migrar el código restante
- En entornos reales, hacen falta más pruebas con builds HWASan y MTE usando diversos dispositivos Bluetooth
- Los dispositivos Pixel incorporan MTE, una gran función de seguridad de hardware, pero el sistema operativo predeterminado no la activa para ahorrar un 3.125% en uso de memoria y caché
- El cálculo se basa en una etiqueta de 4 bits por cada 16 bytes de memoria etiquetada
- heap MTE tiene una sobrecarga de rendimiento cercana al 0% en modo asíncrono (async mode), y en asymmetric mode tiene un costo menor que mitigaciones existentes como SSP
- GrapheneOS activa MTE de forma predeterminada para apps instaladas por el usuario que tienen compatibilidad conocida con el sistema operativo predeterminado
- Puede activarse como opt-in para todas las apps instaladas por el usuario desde Settings > Security
- Ofrece una notificación que permite copiar reportes de crash y un toggle por app
- La implementación MTE de hardened_malloc en GrapheneOS usa etiquetas aleatorias estándar y una etiqueta free dedicada, y excluye dinámicamente la etiqueta anterior y las etiquetas adyacentes actuales o anteriores
- La integración con Chromium fue corregida, y también planean mejorar PartitionAlloc
1 comentarios
Opiniones en Hacker News
Es raro que los Pixels tengan una gran función de seguridad de hardware llamada MTE y aun así el OS no la active para ahorrarse 3.125% de uso de memoria/caché.
De verdad quisiera ver cómo justifica el equipo de Pixel esta decisión, y me da curiosidad el razonamiento detrás de desactivar una función de seguridad tan importante por una mejora de rendimiento mínima.
Dicho eso, GrapheneOS es un proyecto genial, pero solo soporta alrededor de 11 dispositivos, mientras que los cambios en AOSP tienen que considerar un ecosistema OEM mucho más grande.
Siempre buscamos maneras de mejorar Android, pero criticar el lanzamiento de una función específica ignorando el ecosistema OEM más amplio parece una visión limitada.
Es muy poco probable que esta función no se haya activado por ese 3% de memoria/caché; seguramente hubo otras consideraciones.
Al decidir si activar o no la función, probablemente eso sea un factor más importante.
Si otros OS tampoco se están lanzando actualmente con MTE activado, la decisión de activarlo o no probablemente sea más matizada.
La gente de Google fue quien impulsó originalmente MTE por hardware, y surgió del equipo involucrado en ASAN, syzkaller, etc.
No era parte del equipo de Android, pero hubo ayuda y apoyo del lado de Android, y por supuesto colaboración con ARM y otros.
Yo lideraba esos equipos en ese momento, así que conozco bien los compromisos: no es solo un tema de memoria o caché.
Es cierto que MTE puede activarse y desactivarse dinámicamente y que fue diseñado para tener un costo de rendimiento casi cercano a 0, pero en ese momento el uso principal era encontrar bugs mediante muestreo.
Si se activa solo el 1% del tiempo en todo el parque de dispositivos, a una escala suficiente se pueden encontrar bugs muy rápido, y también se puede usar en pruebas internas.
Es decir, el objetivo era poder activar y desactivar funcionalidad comparable a ASAN cuando se quisiera.
Usarlo como mitigación de seguridad siempre activada era una posibilidad secundaria, y además del overhead de memoria tiene otros problemas.
Por ejemplo, de repente pueden aparecer muchos crashes visibles para el usuario, y puede haber inconsistencia porque un teléfono con MTE crashea y uno sin MTE no.
Desde la perspectiva de los desarrolladores, tampoco sería algo bien recibido tener que obligar a todos a probar en ese teléfono cuando prácticamente hay solo uno con MTE activado.
Puede impedir exploits de seguridad y hacer que, en lugar de explotación, haya un crash.
También puede detectar bugs inocuos.
Pero como dije antes, no asumiría que no se usa; más bien parece correcto pensar que no está siempre activado en producción.
Cualquiera con experiencia introduciendo funciones de hardware como esta diría que el simple hecho de que el sistema arranque, ejecute y solo crashee bajo MTE en ciertos comportamientos es una buena señal de que ya se está usando.
Si no se hubiera estado usando, probablemente habría crasheado un millón de veces.
Además, tampoco está claro que sea la mejor opción como mitigación en tiempo de ejecución.
El Pixel base quizá no lo trae activado por defecto para usuarios finales, pero cualquiera puede activar Memory Tagging Extensions en las opciones de desarrollador si quiere.
Se puede mantener activado hasta desactivarlo, o activarlo solo por una sesión para probar una app específica.
En el Pixel OS base, activar el soporte de etiquetado de memoria desde las opciones de desarrollador solo lo deja disponible, pero en realidad no se usa.
También hay que activar el etiquetado de memoria del heap con
setpropdesde un shell de Android Debug Bridge (ADB).Si no se etiquetan las asignaciones, que simplemente esté activado no tiene ningún valor.
En el OS base se puede activar por completo MTE del heap en espacio de usuario mediante Scudo, la implementación del asignador por defecto, pero actualmente no es una implementación especialmente reforzada.
KASan con backend MTE también puede usarse con
setprop, pero por ahora no está diseñado como endurecimiento, y no está claro si lo será en el futuro.Es probable que el kernel necesite una implementación separada de MTE que no sea parte de KASan, y como GrapheneOS tampoco lo ha hecho todavía, el endurecimiento con MTE actualmente es una función de espacio de usuario.
GrapheneOS usa su propia implementación de etiquetado de memoria por hardware para hardened_malloc, con propiedades de seguridad más fuertes.
Para activarlo por defecto en el OS base hubo que corregir o esquivar varios problemas, incluido este.
En lugar de usar MTE asíncrono en los núcleos principales, usa el modo asimétrico en todos los núcleos.
El modo asimétrico es asíncrono para escrituras y síncrono para lecturas, por lo que bloquea correctamente sin dejar una ventana de oportunidad para que el exploit tenga éxito.
Se verifica en llamadas al sistema, y io_uring, que podría ser otra vía de evasión, está restringido por SELinux en Android y solo se permite a dos procesos centrales del sistema.
fastbootd se usa solo durante la instalación, y snapuserd se usa en el OS central después de aplicar una actualización.
GrapheneOS siempre usa MTE del heap para apps cuya compatibilidad con el OS base fue confirmada.
Para apps instaladas por el usuario que no estén en la base de datos de compatibilidad y que no se marquen a sí mismas como compatibles, ofrece un interruptor de MTE por app.
El usuario también puede activar una opción para forzar MTE por defecto en apps instaladas por el usuario, y excluir solo las apps incompatibles.
Para que esto fuera realmente utilizable, se necesitaba un sistema de reportes de crash visible para el usuario, y se implementó para que sea fácil copiar y enviar a los desarrolladores reportes de crash útiles.
Al buscar Memory Tagging Extensions en Configuración aparece, pero pensé que estaba oculto en algún lugar, hasta que vi que era exclusivo de teléfonos Pixel 8: https://news.ycombinator.com/item?id=38125379
GrapheneOS está tan por delante de los demás en términos de seguridad que elegir algo que no sea hardware Pixel empieza a resultar cuestionable.
Pero de verdad quiero una batería reemplazable.
No sé por qué hoy en día todo es tan mediocre.
Los demás dispositivos Android ni se acercan.
El soporte de etiquetado de memoria por hardware es una de las varias grandes ventajas de seguridad de Pixel.
La lista oficial de requisitos de hardware está aquí: https://grapheneos.org/faq#future-devices
Estos requisitos se cumplen por completo en los Pixel de 8.ª generación.
A los Pixel de 6.ª/7.ª generación solo les faltan MTE, BTI y PAC, y MTE es la función más valiosa de la lista de requisitos de hardware.
Los parches de seguridad adecuados son más importantes, y fuera de Pixel no se entregan de la misma manera.
Android tiene lanzamientos mensuales, trimestrales y anuales.
Otros OEM de Android entregan todos los backports de seguridad mensuales de severidad Critical/High, pero en su mayoría no entregan las correcciones de severidad Moderate/Low, incluidas la mayoría de las correcciones de privacidad.
Usar un SO alternativo que entregue esos parches mitiga esto en parte, pero los SO alternativos para esos dispositivos suelen revertir la seguridad de varias maneras.
El firmware y gran parte del código de soporte del dispositivo en realidad vienen del OEM.
Es posible ejecutar Android 14 QPR2 sobre kernels/drivers de Android 12, pero se pierden mejoras de seguridad en grandes partes del SO.
Las baterías de Pixel no son sencillas de reemplazar sin dañar el dispositivo, pero cuentan con soporte oficial y también hay piezas oficiales: https://www.ifixit.com/Device/Google_Pixel
No podemos dar soporte a dispositivos inseguros que ni siquiera tienen lo básico.
Nuestra lista de requisitos de hardware incluye tanto cosas muy básicas que la mayoría de los OEM de Android no ofrecen, como funciones avanzadas como MTE, que ahora consideramos un requisito básico para una seguridad adecuada.
Nos gustaría dar soporte a otros dispositivos, pero esos dispositivos tienen que cumplir estos requisitos.
El etiquetado de memoria es una función básica soportada por los núcleos Cortex ARMv9 estándar.
Es una lástima que Qualcomm no la implemente y que los OEM que usan SoC que sí la soportan tampoco la configuren.
Es triste que una función exista en la arquitectura de CPU pero no se pueda usar por culpa del SoC o del OEM.
Aun así, por suerte el Pixel 8 tendrá 7 años de soporte.
Es difícil confiar en Apple o Samsung, y Google terminó siendo lo mejor disponible.
Sería bueno que alguien que use GrapheneOS pudiera responder
Sin embargo, cuando hace poco fui con mi esposa a Disney World y Universal Studios en Orlando, Florida, aunque las apps en general funcionaban con Google Play Services en sandbox, hubo problemas molestos
La app My Disney Experience tenía bastantes errores relacionados con la ubicación y, de forma intermitente, mostraba que para hacer tareas importantes había que estar en EE. UU. o Canadá, así que tuvimos que usar el teléfono de mi esposa como solución alternativa
En la app de Universal no pude iniciar sesión en la cuenta, pero en el Samsung Galaxy estándar de mi esposa sí funcionaba, así que parecía un problema de GrapheneOS
Además, si pagas con tarjeta de crédito mediante Google Wallet, no está soportado porque Google no certifica GrapheneOS
Las otras funciones de Wallet sí funcionan
Uber funciona sin problemas
Fuera de eso, no uso apps propietarias
Si piensas usar principalmente apps libres/de código abierto, no deberías tener problemas
La mayoría de las apps propietarias funcionan con Google Play Services en sandbox, pero si alguna de ellas es muy crítica para tu trabajo, podrías encontrarte con problemas molestos como los que tuve con Universal Studios y My Disney Experience
Usé un cable USB normal y adb en la línea de comandos de Linux, pero el método recomendado usa WebUSB de Chromium y debería ser más fácil para personas no técnicas
Eso sí, en mi caso no funcionó bien
Gracias a Google Play Services en sandbox, puedes instalar todo tipo de apps propietarias que hacen tolerable la vida moderna, pero al mismo tiempo Google Play no tiene acceso ilimitado a todo el teléfono; toma lo mejor de ambos lados
Si quieres aislarlo más, puedes crear un usuario separado y ejecutar allí lo relacionado con Google Play
Lo probé por un tiempo, pero personalmente me resultó molesto cambiar de usuario cada vez
El teléfono nunca se me ha crasheado, y las apps bancarias funcionan
El dispositivo es un Pixel 6a
También puedes comprar un dispositivo ya instalado, pero casi cualquiera puede usar el instalador web
En Android, ChromeOS y macOS es especialmente fácil, y en Windows es un poco más complicado porque requiere instalar drivers
En Linux de escritorio hay que instalar reglas udev, y algunas distribuciones con versiones de software congeladas tienen servicios con bugs que estorban
Una persona no técnica puede hacerlo; solo necesita un navegador compatible con WebUSB
No se necesita software especial
Para uso diario, si usas Google Play en sandbox, es casi igual que el Pixel OS base y la compatibilidad de apps también es muy similar
Es muy probable que no experimentes una cantidad significativamente mayor de crasheos
Tiene reportes de crasheos orientados al usuario que el OS base no incluye, así que podrías enterarte de crasheos que de otro modo no habrías notado
Las apps con muchos bugs que tienen corrupción de memoria pueden crashearse hasta que actives un modo de compatibilidad por app, y eso es más probable si decides forzar MTE para todas las apps instaladas por el usuario
Las apps bancarias funcionan si el banco permite sistemas operativos que no estén certificados por Google, y por ahora la mayoría todavía lo permite
Sin embargo, los bancos están empezando a bloquear cada vez más los OS no certificados por Google, así que esto debería tratarse esencialmente como un tema regulatorio anticompetitivo
Mientras tanto, estamos intentando convencer a los bancos de que usen https://grapheneos.org/articles/attestation-compatibility-guide
Las funciones extra de seguridad, la configuración de sandboxing y el hardened memory allocator lo hacen algo más lento, y es más engorroso que usar Android de fábrica y darle OK a todas las solicitudes de acceso a datos
También toma un poco de tiempo la configuración inicial y entender en qué se diferencia GrapheneOS y cómo usar sus funciones de seguridad
En 4 años de uso no tuve crasheos
Al menos no crasheos de todo el sistema, y por experiencia no aparecen crasheos que obliguen a depurar durante días porque el hardware Pixel y el software están bien ajustados entre sí
Las apps bancarias dependen de cada app
Algunas funcionan incluso sin Play Services, la mayoría funciona con Play Services en sandbox, y solo unas pocas no funcionan en absoluto
Si dices qué banco usas, otros usuarios pueden confirmar si funciona o no
Incluso el método difícil consiste básicamente en conectar el teléfono por USB, presionar un poco los botones de encendido/volumen y copiar y pegar dos o tres comandos en la terminal
El método fácil solo requiere conectar el teléfono a la computadora y presionar un botón de instalación de un clic que funciona en el navegador Chrome
Lo he usado casi continuamente como OS de uso diario desde poco después de que salió el Google Pixel 6, y nunca se me ha crasheado ni una sola vez
Tampoco he tenido bugs ni he necesitado depurar, arreglar o hacer mantenimiento
Todas las apps que probé simplemente funcionaron como en Android de fábrica y, honestamente, casi no noto la diferencia
A veces incluso olvido que no es el OS que venía originalmente en el teléfono
Personalmente, la app bancaria Discover me funciona, pero no estoy seguro sobre otras apps
Aun así, como tiene Google Play services y el bootloader queda bloqueado después de la instalación, probablemente la mayoría funcionen
Para 2024 necesitamos sistemas operativos formalmente verificados, aplicaciones y herramientas que sigan el espíritu de seL4, pero con un nivel aún más estricto
En estos tiempos, seguir pegando codebases sobrediseñadas y apenas probadas con lenguajes frágiles y peligrosos significa crear superficies de ataque para malware y hackeos, además de muchos bugs molestos, donde actores extranjeros podrían hackear sistemas y causar la muerte de usuarios
Encima de eso también hay que ofrecer una experiencia de usuario limpia e integrada y funciones útiles; si no, todo el esfuerzo de ingeniería termina siendo en vano
Basta ver Qubes OS
¿Hay alguna computadora de placa única decente que implemente Arm MTE? Algo como una Raspberry Pi reciente.
La RasPi 5 es una quad A76 y usa extensiones v8.2; MTE es v8.5.
¿Cómo se compara MTE con CHERI?
MTE está pensado para encontrar posibles bugs de seguridad, no es una protección verdadera.
Como las etiquetas son de solo 4 bits y la aplicación puede falsificarlas, si un atacante tiene que acertar la etiqueta correcta, aun eligiendo al azar tiene 1/16 de probabilidad de acertar.
La idea de aplicar MTE es que permite detectar accesos incorrectos que ocurren ocasionalmente incluso sin un atacante, y que en la práctica no producen un mal resultado.
Pensemos en un desbordamiento de búfer típico: las palabras justo después del final del búfer pueden no usarse para otra cosa, así que en la práctica podría funcionar.
MTE detecta esos accesos y permite investigarlos y parchearlos antes de que se conviertan en un exploit armado.
Sin embargo, mediante etiquetas reservadas puede ofrecer propiedades de seguridad deterministas fuertes.
Lo que no está etiquetado tiene etiqueta 0, y lo etiquetado por defecto tiene una etiqueta distinta de 0 debido a la exclusión predeterminada.
También se pueden excluir otras etiquetas de forma estática o dinámica con instrucciones, pero si se usa la etiqueta 0 para fines internos como memoria liberada, se puede aprovechar el hecho de que ningún puntero etiquetado puede acceder a ella.
En hardened_malloc se excluyen dinámicamente, para los slots de asignación, las etiquetas adyacentes y las usadas anteriormente.
Esto ofrece protección determinista contra desbordamientos lineales y desbordamientos pequeños.
En el caso de use-after-free, un puntero a una asignación liberada no puede acceder mientras está liberada ni justo después de ser reasignada; tiene que esperar hasta que se asigne nuevamente, y en ese momento la probabilidad de que tenga la etiqueta correcta es de 1/15.
Esto combina bien con otras propiedades de seguridad de hardened_malloc.
Para la asignación por slabs y la memoria virtual se usan zonas de cuarentena FIFO/aleatorias para retrasar aún más la reutilización y hacerla no determinista.
Hasta superar los 128k, nunca se reutilizan ubicaciones de memoria entre clases de tamaño de asignación distintas; cada clase está en una región diferente, y todos los metadatos están en otra región reservada.
En el caso general, MTE actualmente tiene solo 4 bits, así que la probabilidad de eludirlo es de alrededor de 1/15.
Se puede ampliar fácilmente para admitir el uso de 8 bits, y si no se usa PAC también hay otros bits libres.
En teoría, en un espacio de direcciones general de 39 bits, se podría admitir incluso MTE de hasta 16 bits para espacios de direcciones de 48 bits o más.
Actualmente está fijado en 4 bits; escuché que se eligió eso en lugar de 8 bits para permitir almacenar bits adicionales en memoria de paridad ECC.
Pero no las detecta con tanta confiabilidad como CHERI.
No hay protección para las etiquetas y el espacio de etiquetas también es pequeño (2^4).
Espero el día en que el hardware mainstream alcance a Solaris SPARC de 2015, o a las arquitecturas de etiquetado de memoria anteriores, y finalmente podamos controlar los problemas de corrupción de memoria.
Claro que esos problemas suelen descartarse como algo que solo producen desarrolladores incompetentes.
No es un problema de “desarrolladores incompetentes”; es un problema de todos.
La corrupción de memoria es prácticamente una característica del lenguaje en C/C++.
Mejor no difundir la creencia de que se debe a gente tonta.
Casi nadie se considera tonto, y he visto a programadores realmente brillantes crear bugs de memoria absurdos.
Simplemente forma parte del terreno de esos lenguajes, y no es cuestión de “si” pasa, sino de “cuándo”.
Me gusta que se haya colado discretamente una frase que muestra por qué Android movió una parte importante del código de Bluetooth a Rust y por qué debería dedicar más recursos a mover también el resto del código a Rust.
Usé C y C++ durante muchos años, pero no tengo experiencia con Rust, así que me da curiosidad cuánta refactorización hace falta al portar de C a Rust.
Dividiendo la pregunta: 1. ¿Qué tan directamente se traduce C a Rust? ¿Rust exige reorganizar la estructura o refactorizar?
2. Me pregunto cómo está abordando Google esto: si intenta “traducir” manteniéndose lo más cerca posible, o si lo ve como una oportunidad para una reescritura/refactorización a gran escala.
También me pregunto si algún día el stack Bluetooth de Android podrá usarse en sistemas de escritorio con distribuciones Linux estándar.
Tenía muchas referencias cíclicas, con una estructura en la que los módulos se comunicaban entre sí mediante un “bus de señales” con callbacks, y sentí que tenía que pelear contra Rust más que recibir ayuda.
Incluso en lugares donde en C++ podía almacenar los datos inline, necesité muchos
Box, que son punteros al heap.En conclusión, si es una herramienta simple de línea de comandos o una estructura de petición-respuesta, portar a Rust probablemente sea fácil.
Más en general, si la estructura del código encaja bien con asignación por arena, moverlo agregando etiquetas de vida útil a las referencias no es un gran problema.
Pero si escribiste código al estilo de un programador de C, con referencias cíclicas —un código, admitámoslo, feo—, Rust se siente como una cuesta arriba y no es un buen punto de partida.
Primero hay que cambiar la estructura del código C++ para mover la propiedad a un padre común.
Creo que con eso mejoraría.
Pienso seguir aprendiendo Rust de forma iterativa, pero seguiré trabajando en C++ hasta que el código se corresponda mejor con Rust.
Tendrás que re-arquitecturar una buena parte de lo que estés escribiendo.
Es inevitable por la forma en que Rust garantiza la seguridad de memoria.