Adsense

viernes, 31 de julio de 2026

Crash persistente en Android STA

STA-015-DL: Un clic, un SystemUI colapsado, un reinicio forzado

STA-015-DL: Un clic, un SystemUI colapsado, un reinicio forzado

El vector más crítico de Structured Text Amplification (STA) explicado en detalle

¿Qué es STA-015-DL?

STA-015-DL es uno de los 32 vectores documentados en el whitepaper de Structured Text Amplification (STA). Es, con diferencia, el más severo de todos: CVSS 8.6 (Alto), y no porque sea un fallo de memoria ni una vulnerabilidad remota de ejecución de código, sino porque un solo clic puede dejar tu teléfono inútil hasta que lo reinicies a la fuerza.

El ataque no requiere privilegios especiales, ni instalar nada, ni interactuar con la víctima más allá de un clic en un enlace. El enlace, además, puede estar alojado perfectamente en Google Drive, en un correo electrónico, en un SMS o en un código QR. La víctima solo tiene que abrirlo.

El dato clave: El ataque funciona en Chrome, Edge, Firefox, Brave, Opera, DuckDuckGo… el patrón está en la capa del sistema, no en el navegador.
CVSS 3.1
8.6
Recuperación
Reinicio forzado + borrado de datos

La cadena de ataque, paso a paso

  1. El usuario abre un documento HTML alojado en Google Drive. El documento contiene un hipervínculo perfectamente normal, pero con una URL extraordinariamente larga y con caracteres especiales: #, /, %, … El tipo de URL que, en principio, no parece peligrosa.
  2. Al hacer clic, Google Drive genera un Intent ACTION_VIEW. Android lo trata como una acción legítima. La URL viaja a través de Binder, el mecanismo de comunicación entre procesos, y llega al navegador predeterminado.
  3. El navegador intenta procesar la URL. En ese momento, libminikin.so –el motor de renderizado de texto de Android– intenta calcular los saltos de línea de esa URL kilométrica. El algoritmo es O(n²) en el peor caso, y la CPU se bloquea durante 10–17 segundos. Se produce un ANR (Application Not Responding).
  4. Pero el daño no acaba ahí. Durante ese bloqueo, el sistema intenta guardar el estado de la tarea. La URL gigante se serializa y se escribe en el TaskPersister, el componente que guarda las tareas recientes en disco.
  5. SystemUI –la interfaz del sistema– lee ese estado corrupto. Al intentar restaurar la tarea, se encuentra con una BadParcelableException o una DeadObjectException. Y SystemUI se cae. La pantalla se queda en negro, desaparecen la barra de estado, la barra de navegación… el teléfono parece muerto.
  6. Android intenta recuperarse. Reinicia SystemUI automáticamente. Pero el estado corrupto sigue en el disco. El componente de HyperOS ShadeStatusBarTokenInteractor (un código específico de Xiaomi) vuelve a leer el mismo estado corrupto… y SystemUI vuelve a caer. Es un bucle.
  7. Tras varios intentos, Android se rinde y muestra la pantalla de bloqueo. El usuario introduce su PIN, su patrón o su huella. Android restaura la sesión… y el navegador vuelve a estar en primer plano. El estado corrupto sigue ahí. El ciclo se repite automáticamente. El usuario no necesita hacer nada más.
La única recuperación posible: reinicio forzado (mantener el botón de encendido 10 segundos) y borrar los datos del navegador y de SystemUI. Ni el modo seguro, ni un reinicio normal, ni una restauración de fábrica parcial funcionan si el estado corrupto persiste en taskpersister.xml.

Evidencia técnica (la parte que no se ve)

Este vector no es una teoría. Se ha reproducido en seis dispositivos de diferentes fabricantes (Pixel, Xiaomi, Samsung, OPPO, OnePlus) con Android 13, 14, 15 y 16. Los stack traces nativos capturados en dispositivos de producción son públicos en el whitepaper.

El flujo completo de 12 pasos está documentado en el whitepaper y basado en dos bugreports independientes de mayo y junio de 2026, recogidos en un dispositivo Xiaomi Redmi Note 14 5G con HyperOS 3.0.

android.os.BadParcelableException: Failure retrieving array; only received 1 of 4
  at android.content.pm.BaseParceledListSlice.<init>(BaseParceledListSlice.java:111)
  at android.window.ITaskOrganizerController$Stub$Proxy.registerTaskOrganizer(...)
  at android.window.TaskOrganizer.registerOrganizer(TaskOrganizer.java:76)
  at com.android.wm.shell.sysui.ShellInit.init(...) ← crash at bootstrap
Caused by: android.os.DeadObjectException: Transaction failed on small parcel

Esta traza demuestra que SystemUI se cae en su propia inicialización, antes de que el usuario haya visto siquiera la pantalla de inicio.

¿Por qué es tan grave?

  • No requiere ninguna habilidad técnica. El ataque se activa con un simple clic. Cualquier persona con acceso a un enlace puede ser víctima.
  • El alcance cambia. El navegador es solo el vehículo. El objetivo real es SystemUI, el componente más privilegiado de la interfaz de Android. El impacto no se limita a una aplicación: es el sistema entero.
  • La persistencia. El estado corrupto se guarda en disco y sobrevive a reinicios. Ni el modo seguro, ni las herramientas de recuperación básicas lo eliminan. Solo una limpieza a fondo de los datos del sistema.

¿Qué han hecho los fabricantes?

  • Google: Reconoció parte de la investigación con una recompensa de 250 dólares, pero el informe específico sobre libminikin/SystemUI (el que contiene STA-015-DL) fue cerrado como "Out of Scope". La apelación fue denegada como "Not Reproducible", a pesar de las pruebas de concepto y los bugreports.
  • Xiaomi: Reprodujo el vector específico que afecta a su capa HyperOS (STA-015b) y concedió una recompensa de 300 dólares. Están trabajando en un parche.
  • INCIBE: Derivó el caso a MITRE para la asignación de CVE. El proceso está en curso.
  • El boletín de seguridad de Android de julio de 2026: No incluyó ni un solo parche para STA-015-DL ni para ningún otro vector STA.

¿Qué puedes hacer tú?

Si eres usuario de Android:

  • No hagas clic en enlaces sospechosos que contengan URL inusualmente largas o con muchos caracteres especiales.
  • Si ves que SystemUI se cae y no se recupera, mantén pulsado el botón de encendido 10 segundos para reiniciar. Luego, desde el modo seguro o desde la configuración, borra los datos del navegador y de SystemUI.
  • Difunde esta información. Cuanto más se sepa, más presión habrá sobre Google para que publique el parche.

Si eres desarrollador de Android:

  • Valida y trunca cualquier texto estructurado que entre en tu aplicación (URLs, Intent extras, contenido de portapapeles, etc.) antes de pasarlo al framework.
  • No confíes en que el framework hará el trabajo por ti.

El vídeo (prueba de concepto)

🎬 Aquí deberías insertar el vídeo de la reproducción completa del ataque.
Puedes subirlo a YouTube/Vimeo y poner el iframe o el enlace.

El whitepaper completo

Todos los detalles técnicos, los stack traces, las tablas de vectores y las recomendaciones de parche están disponibles en el whitepaper completo:

📄 Leer el whitepaper

0 comentarios:

Publicar un comentario

Twitter Delicious Facebook Digg Stumbleupon Favoritos Mas