Cadena de exploit 0-click para Pixel 10

• La cadena para Pixel 10 usa como primera etapa una vulnerabilidad Dolby 0-click presente en Android en general antes del parche, y añade una nueva ruta de escalación local de privilegios
• El driver BigWave de la cadena de Pixel 9 no estaba en Pixel 10, por lo que no podía portarse; en su lugar, /dev/vpu de Tensor G5 se convirtió en la superficie de ataque
• El driver de VPU exponía directamente a userspace una interfaz de registros MMIO, y con solo una auditoría de 2 horas se encontró un bug crítico en mmap
• remap_pfn_range hacía el mapeo basándose solo en el tamaño de la VMA, no en el tamaño de los registros, lo que permitía leer y escribir en .text y .data del kernel
• La vulnerabilidad se reportó el 24 de noviembre de 2025 y fue parchada 71 días después, lo que muestra que el refuerzo de seguridad de los drivers en Android sigue siendo necesario

---

Composición de la cadena 0-click de Pixel 10

• Basándose en la cadena de exploits que en Google Pixel 9 llegó hasta root de Android desde un contexto 0-click con dos exploits, se armó una cadena similar también para Pixel 10
• La vulnerabilidad Dolby 0-click existía en Android en general hasta el parche de enero de 2026, y también se usó como primera etapa en la cadena dirigida a Pixel 10
• El driver BigWave, que era la etapa de escalación local de privilegios en Pixel 9, no estaba incluido en Pixel 10, así que no podía portarse tal cual, y el driver /dev/vpu de Pixel 10 pasó a ser la nueva superficie de ataque

Actualización del exploit de Dolby

• Adaptar el exploit existente para CVE-2025-54957 a Pixel 10 fue, en su mayor parte, cuestión de actualizar offsets basados en bibliotecas de Pixel 9 a los offsets correspondientes en las bibliotecas de Pixel 10
• Pixel 10 usa RET PAC en lugar de -fstack-protector, así que no fue posible sobrescribir __stack_chk_fail
• Después de varios intentos, se usó un método que sobrescribía el código de inicialización dap_cpdp_init, que se llama una vez durante la inicialización del decodificador y no vuelve a invocarse
• El exploit actualizado de Dolby UDC se publicó aquí y solo funciona en dispositivos sin parchear con SPL de diciembre de 2025 o anterior

Eliminación de BigWave y adición de VPU

• Pixel 10 no incluye el driver BigWave, así que no fue posible portar la etapa de escalación local de privilegios de la cadena previa de Pixel 9
• Se identificó como nueva superficie de ataque el driver /dev/vpu, accesible desde el contexto SELinux de mediacodec, que se usa para interactuar con el silicio Chips&Media Wave677DV de aceleración de decodificación de video del chip Tensor G5
• Según comentarios en archivos C públicos, este driver parece estar desarrollado y mantenido por el mismo grupo que creó el driver BigWave
• Tras auditar el driver VPU durante 2 horas junto con Jann Horn, se encontró una vulnerabilidad muy inusual
• A diferencia del driver upstream de Linux para el chip anterior de Chips&Media, WAVE521C, el driver WAVE677DV de Pixel no está integrado con V4L2 (“Video for Linux API”)
• El driver de Pixel expone directamente a userspace la interfaz de hardware del chip y permite que userspace mapee la interfaz de registros MMIO del chip
• La función principal del driver es configurar el mapeo de memoria del dispositivo, administrar la energía y permitir que userspace espere interrupciones del chip

Vulnerabilidad central del kernel

• El bug en cuestión era una vulnerabilidad cuya explotación resultó ser muy sencilla
• El mmap handler problemático es código que mapea la región de registros MMIO del hardware VPU al espacio de direcciones virtual de userland
• La llamada a remap_pfn_range no estaba limitada por el tamaño de la región de registros, sino solo por el tamaño de la VMA
• Un atacante puede especificar en la llamada al sistema mmap un tamaño mayor que la región de registros y, así, mapear en userland tanta memoria física como quiera a partir de la dirección física de la región de registros de la VPU
• Como la imagen completa del kernel se encuentra en direcciones físicas más altas que la región de registros de la VPU, este bug permite acceder y modificar las secciones .text y .data del kernel
• En Pixel, el kernel siempre está ubicado en la misma dirección física, por lo que el offset entre la región de memoria de la VPU y el kernel siempre es conocido
• Si se especifica una VMA lo bastante grande, ni siquiera hace falta escanear el kernel en la memoria física mapeada: se puede conocer con precisión su ubicación a partir de la dirección devuelta por mmap
• Hicieron falta 5 líneas de código para lograr lectura y escritura arbitrarias en el kernel con esta vulnerabilidad, y redactar el exploit completo tomó menos de un día
• Es posible sobrescribir funciones arbitrarias del kernel para obtener ejecución de código en kernel o construir los primitivos deseados

Gestión del parche

• La vulnerabilidad fue reportada el 24 de noviembre de 2025, y Android VRP la evaluó con severidad High
• El bug de BigWave usado para la escalación de privilegios en Pixel 9 tenía el mismo impacto de seguridad, pero inicialmente fue evaluado como Moderate, por lo que esta vez puede considerarse una mejora en el tratamiento
• La vulnerabilidad fue parchada en el boletín de seguridad de Pixel de febrero, 71 días después del reporte inicial
• Se considera la primera vez que un bug de driver de Android fue parchado dentro de los 90 días posteriores al primer reporte al vendor
• Este proceso mostró que la respuesta de Android para clasificar y parchear bugs de tipo similar ha mejorado de forma significativa

Implicaciones de seguridad

• La respuesta a la vulnerabilidad de VPU muestra que el pipeline de clasificación de Android ha mejorado, y que la corrección inicial llegó en un plazo mucho más corto que en el problema anterior de BigWave
• Los esfuerzos de Android por parchear vulnerabilidades graves de forma eficiente ayudan a proteger muchos dispositivos Android
• Al mismo tiempo, los drivers de Android siguen necesitando código más exhaustivo y desarrollado con mayor conciencia de seguridad
• Tras el reporte del bug de BigWave, se esperaba que los desarrolladores relacionados revisaran problemas de seguridad evidentes en otros drivers, pero 5 meses después se encontró en el driver VPU una vulnerabilidad grave que quedó inmediatamente expuesta incluso con una auditoría superficial
• Para la seguridad del ecosistema Android, el fortalecimiento de la seguridad de los drivers sigue siendo una prioridad importante
• Los vendors deben mejorar de antemano sus prácticas de desarrollo de software para evitar que las vulnerabilidades lleguen a los usuarios finales y, en especial, los productos críticos para la seguridad deberían lanzarse en un estado razonablemente libre de vulnerabilidades desde el inicio
• Los equipos de software deben adoptar un enfoque proactivo en seguridad, auditoría de código y parcheo de vulnerabilidades

[GN⁺]

Opiniones de Hacker News

• Al seguir el enlace del bug/exploit de Pixel 9, vi que decía que, por las funciones de AI, hay que decodificar el contenido multimedia antes de que el usuario abra el mensaje, lo que amplía la superficie de ataque de 0 clics
  Siento que esta lección ya deberíamos haberla aprendido. Es decir: no leas SMS ni proceses nada que no pedí

  • No tengo claro cuál es exactamente la lección que se suponía que debíamos haber aprendido
    Los usuarios eligen teléfonos con funciones de mensajería enriquecidas. En el iPhone eso era iMessage y, más tarde, en Android fue RCS cuando por fin se puso al día; eso era un gran punto de venta
  • Ni siquiera eso basta. Si piensas en un cliente de correo que no analiza imágenes hasta que el usuario interactúa con el mensaje, en el momento en que haces clic y te das cuenta de que es sospechoso, la maquinaria compleja y llena de bugs ya se ejecutó
    Personalmente, de las cosas más absurdas que vi fue cuando marqué como spam un mensaje muy sospechoso con un archivo adjunto casi con certeza malicioso en cierto webmail de BigTech; como no era phishing, no había otra opción, y “amablemente” abrió en mi navegador local el enlace para darse de baja sin pedirme permiso. Cuesta imaginar el nivel de incompetencia y disfunción organizacional necesario para escribir, revisar, aprobar y desplegar una función así en un contexto sensible a la seguridad y la privacidad
  • Google es dueño de Android, pero a Google no le importan los usuarios. Sus clientes son los anunciantes
    Ni siquiera los 0-day importan mucho. En la práctica la única alternativa real es el iPhone, y Huawei solo es opción según la región, así que no tienen muchos motivos para preocuparse. Necesitamos urgentemente un nuevo sistema operativo para teléfonos y una nueva capa de hardware
  • Hace poco escuché una presentación sobre “AI Security” y básicamente el mensaje era: “vamos a tragarnos sin espíritu crítico todas las entradas y salidas de la AI, eso es un problema de seguridad, pero no hay nada que hacer salvo mitigarlo después”
    Incluso incluía la idea de que “un actor de amenazas puede influir en la AI si actualiza documentos internos”, pero si un actor de amenazas está actualizando documentos, entonces el sistema ya está comprometido. No estamos hablando de algo tipo “vandalismo en Wikipedia”
  • Lograr que el usuario abra un mensaje no es una barrera muy alta
    Desde el punto de vista del usuario, es difícil aceptar que tenga que ir con cuidado respecto a qué mensajes abrir. Ya intentamos trasladarles la responsabilidad con los adjuntos de correo, y sería justo decir que el resultado fue desastroso. Los adjuntos maliciosos probablemente sean una de las vías más importantes de distribución de malware

• La frase “esta es la primera vez que un bug de driver de Android se parchea dentro de los 90 días desde que el proveedor supo por primera vez de la vulnerabilidad, así que fue especialmente rápido” mejora mi impresión de Google, pero al mismo tiempo me asusta un poco el resto del ecosistema Android
  Me pregunto cómo será el tiempo de respuesta de Apple

  • Los proveedores de Android llevan mucho tiempo teniendo mala fama con las actualizaciones. Una de las razones, según se dice, es que las compañías de teléfonos hacen forks de la UI base de Android para diferenciarse entre sí, intentando ofrecer funciones de marca y visiones alucinadas de interfaz
    Pero entonces, cuando sale una actualización de Android puro, el trabajo de migración se vuelve enorme
  • Una vez reporté un bug de seguridad a Apple. Fue hace varios años, pero recuerdo que tardaron como 6 meses en sacar el parche
    Hubo varios intercambios para crear una prueba de concepto más estable, y después de enviar una que reproducía el problema al 100%, creo que fueron unos 2 meses
  • Si consideras que el 42% de los dispositivos Android siguen sin parchear [1], resulta interesante la decisión de publicar la investigación y dejar a todos vulnerables
    [1] https://gs.statcounter.com/android-version-market-share
    [2] https://www.cybersecurity-insiders.com/survey-reveals-over-1...
  • Si es un dispositivo Android de una marca conocida, puedes esperar actualizaciones de seguridad del OS, porque el proveedor principal puede compilar y distribuirlas directamente
    Pero las actualizaciones de seguridad de drivers y firmware son otra historia. Muchas veces dependen de proveedores de nivel superior, que pueden o no tener voluntad de corregir el problema. Las marcas pequeñas suelen vender Android baratos y directamente no actualizan nada

• Relacionado un poco con esto, me pregunto si de verdad aumentó la proporción de exploits públicos recientes, o si solo aparecen más en las noticias porque la AI se volvió un tema llamativo tanto para herramientas ofensivas como defensivas
  Siento que cada dos días sale algo nuevo en Linux, Windows, móviles o herramientas comunes que usa todo el mundo

  • Si lees entre líneas la parte 1, el código problemático se introdujo por una función de AI y el exploit lo encontró una persona
    https://projectzero.google/2026/01/pixel-0-click-part-1.html
    Así que usar AI aumenta los bugs, y luego los humanos tienen que ir a seleccionarlos
  • Yo mismo hice un análisis el fin de semana pasado y en 2024 había alrededor de 100 CVE publicados por día. En abril llegamos a unos 200 por día
    Si retrocedes antes de 2023, el ciclo de duplicación de CVE publicados era de unos 4 a 4.5 años; desde entonces es de alrededor de 2 años. Definitivamente hubo un aumento brusco
  • Según quienes gestionan bugs de seguridad en open source, los reportes aumentaron muchísimo. Al principio eran sobre todo reportes de baja calidad casi falsos, pero ahora también hay muchos más reportes realmente válidos
  • Es pura especulación y no soy investigador de seguridad, pero parece que la AI actúa como acelerador: aumenta la superficie de ataque explotable de baja calidad y, al mismo tiempo, acelera el trabajo de los investigadores de seguridad
    O sea, bien usada es excelente, pero mal usada es realmente mala
  • En las últimas semanas reporté varios problemas bastante serios a proveedores de herramientas de uso masivo, y me costó más de lo habitual que los reconocieran
    Escuché que los equipos de respuesta están saturados por una avalancha de reportes

• Ojalá alguien me confirmara si estoy pensando bien esto. Puse el siguiente prompt exacto en gpt 5.5 xhigh

  does this look right to you? don't do any searches or check memory, just think through first principles
  
  static int vpu_mmap(struct file fp, struct vm_area_struct vm) { unsigned long pfn; struct vpu_core core = container_of(fp->f_inode->i_cdev, struct vpu_core, cdev); vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM_DONTDUMP); / This is a CSRs mapping, use pgprot_device */ vm->vm_page_prot = pgprot_device(vm->vm_page_prot); pfn = core->paddr >> PAGE_SHIFT; return remap_pfn_range(vm, vm->vm_start, pfn, vm->vm_end-vm->vm_start, vm->vm_page_prot) ? -EAGAIN : 0; }  
  

  Sin buscar en la web, identificó correctamente el problema. Quiero probar algo más amplio, como meterle no solo una función concreta sino bloques enteros del codebase en el prompt. Parece que hay potencial real para detectar exploits de seguridad. Entonces me pregunto cómo fue que esto salió publicado así en primer lugar. Sé que es un ejemplo de juguete, pero quiero aprender más

  • Esa no es una prueba justa. Aunque el prompt no dice directamente que encuentre el bug, sí orienta bastante al modelo en esa dirección
    Básicamente es la misma objeción que salió en el hilo donde se decía que el modelo actual era tan bueno como mythos
  • Como anécdota, probé con fragnesia.c y luego con el parche que corregía el problema, y no descubrió una vulnerabilidad completamente nueva, pero sí pareció encontrar 2 formas nuevas de explotar el mismo bug de fondo
    Considerando que lo intentó un tonto como yo que solo tiene una suscripción a Claude, me pareció bastante impresionante
  • Solo con esto no se puede saber si realmente sirve para encontrar vulnerabilidades en la práctica. No sabemos cuántos falsos positivos saldrían al correrlo sobre código completo
    Dicho de otro modo, podría ser https://en.wikipedia.org/wiki/Base_rate_fallacy
  • Me pregunto cómo sabes que no hizo búsquedas en la web
  • Pegué el código en claude Opus 4.7 sin acceso a internet y le pedí que solo explicara qué hacía la función; mientras la explicaba, también señaló el bug. No le pedí que buscara bugs

    Observations & Potential Issues
    A few things worth flagging:

    1. No bounds checking on the mapping size. Userspace controls vm_end - vm_start and vm->vm_pgoff. Here vm_pgoff is ignored entirely and the size is trusted blindly. If the VPU's register block is, say, 64KB but userspace requests a 1MB mapping, the driver will happily map 1MB of physical address space starting at core->paddr — potentially exposing whatever hardware happens to live at adjacent physical addresses. A defensive check would be:
       Si llegamos a una era en la que bots puedan escanear los PR de todos los proyectos open source apenas aparezcan, un ciclo de lanzamiento de 70 días pronto dejará de ser suficiente para evitar el uso masivo de exploits

• Excelente reporte de bug. No soy para nada experto en kernel y solo leí un poco del tema hace más de 10 años, pero aun así pude seguirlo y entender qué estaba pasando
  El hecho de que este fuera un bug realmente serio y que no pareciera haber requerido tanto trabajo encontrarlo me da miedo sobre qué otros riesgos estarán escondidos por ahí. Además, como últimamente muchos problemas de seguridad se encuentran con AI, este reporte me deja pensando dos cosas. La experiencia sigue teniendo muchísimo valor, y cuanto más de nicho sea, más valor tiene. Y todavía quedan muchos nichos donde la AI no domina

• No sé qué pasó con el jailbreak del iPhone. Hace bastante tiempo que no veo nada y me pregunto qué está ocurriendo. No sé si me perdí algo o si de verdad ya no hay nada posible
  Sea como sea, lo de Apple es impresionante, pero me gustaría saber si, por la tendencia actual, es solo cuestión de tiempo o si hubo un cambio real

  • La postura de seguridad de Apple es bastante mejor que la de Android gracias a Lockdown Mode, el memory tagging y los asignadores seguros
    Aquí se puede leer algo al respecto: https://security.apple.com/blog/memory-integrity-enforcement...
  • Hoy en día es casi imposible tener exploits que sobrevivan a un reinicio. Y los exploits que permiten jailbreak ahora requieren una cadena completa de exploits, su valor es bastante alto y se parchean en cuanto se hacen públicos
    Por eso, escenas como las del viejo jailbreak del iPhone ya no son posibles
  • Siempre me molestó que el “jailbreak” no recibiera el mismo nivel de validación que las vulnerabilidades de software en otras plataformas

• ¿Habrá evidencia de qué impacto tuvo la AI en el negocio de empresas como NSO? Me pregunto si las vuelve inútiles o si más bien las superpotencia

  • No sé los detalles, pero parece que la AI está cambiando mucho el panorama y que probablemente bastante del “capital” que representaban los 0-day se haya evaporado
    Si es así, serían buenas noticias para todos excepto para NSO y compañías parecidas

• Me pasó algo parecido alguna vez. La solución parece razonable, pero soy escéptico respecto de la mejora de rendimiento que afirman

• Las mejoras de V4L2 para soportar decodificación de video por hardware estuvieron esperando integración durante mucho tiempo, y ahora parece que ya entraron al kernel mainline
  Supongo que la gente no quiso seguir esperando tanto

• Me sorprende que incluso Project Zero tenga que reportar bugs de Android por el canal formal y lidiar con la clasificación de severidad del Android VRP
  Siempre pensé que simplemente podían caminar hasta la oficina de Android y convencer a la gente cara a cara de la importancia del bug

  • Si el método “normal” les pareció demasiado doloroso, probablemente lo siguiente que intentaron fue hacer que ese mismo proceso se arreglara
  • Eso depende de asumir que Android realmente escucharía a Project Zero