Ciberseguridad · Aviso

Google Android (componente Debuggerd), versiones 4.0 a 5.x · Divulgación de memoria por archivo ELF manipulado

Un archivo ELF manipulado podía hacer caer el depurador interno de Android (Debuggerd) y filtrar contenido de la memoria del dispositivo en versiones 4.0 a 5.x; Google lo calificó de gravedad baja y lo corrigió en 2015.

Publicado 7 noviembre 2026 Lectura 5 min Ref. Sin CVE CVSS —

Resumen

Investigadores de Trend Micro descubrieron en 2015 una vulnerabilidad en Debuggerd, el depurador integrado de Android, presente en las versiones 4.0 (Ice Cream Sandwich) a 5.x (Lollipop). Una aplicación maliciosa o reempaquetada que incluyera un archivo ELF especialmente diseñado podía provocar la caída del depurador y hacer que volcase fragmentos de memoria del dispositivo en archivos de diagnóstico. El impacto directo es limitado (una denegación de servicio del depurador), pero la memoria expuesta podía ayudar a preparar ataques más graves, como eludir la protección ASLR. Google lo clasificó como de gravedad baja, lo corrigió en el código abierto de Android en mayo de 2015 y lo dejó resuelto en Android 6.

Materias: Android, Seguridad móvil, Vulnerabilidades, Divulgación de información, Depuradores, ASLR

Cuando un programa en Android se bloquea, un componente del sistema llamado Debuggerd (el depurador integrado) recoge información sobre lo ocurrido para ayudar a diagnosticar el fallo. En 2015, investigadores de la empresa de seguridad Trend Micro descubrieron que ese mismo mecanismo de diagnóstico podía volverse en contra del usuario: un archivo manipulado era capaz de hacer caer al depurador y provocar que este dejara al descubierto fragmentos de la memoria del dispositivo. Se trata de un fallo antiguo, de gravedad baja y ya corregido, pero ilustra bien cómo una herramienta pensada para ayudar puede convertirse en una vía de fuga de información.

Descripción

Qué es y a qué afecta

La vulnerabilidad reside en Debuggerd, el depurador de bajo nivel que Android ejecuta cuando una aplicación se cuelga. Su trabajo es analizar el proceso que ha fallado y generar informes de diagnóstico: los llamados tombstones (literalmente «lápidas», ficheros que registran el estado del programa en el momento del fallo) y las entradas correspondientes en logd, el servicio de registro (log) del sistema.

El problema afecta a los dispositivos con Android 4.0 (Ice Cream Sandwich) hasta Android 5.x (Lollipop). En la práctica, cualquier terminal con una de esas versiones tenía el componente vulnerable.

Para entender el riesgo conviene aclarar dos conceptos:

Archivo ELF (Executable and Linkable Format): es el formato estándar de los programas y librerías ejecutables en Linux y Android. Las aplicaciones incluyen componentes en este formato.
ASLR (Address Space Layout Randomization): una defensa que coloca el código y los datos en posiciones de memoria aleatorias en cada ejecución, para dificultar que un atacante sepa «dónde apuntar». Si un atacante logra ver contenido de la memoria, puede deducir esas posiciones y, así, neutralizar esta protección.

El impacto por sí solo era modesto: lo que un atacante conseguía directamente era hacer caer el depurador (una denegación de servicio, es decir, dejar sin funcionar ese componente). La gravedad está en el efecto colateral: al caer, el depurador podía filtrar contenido de memoria que facilitaría otros ataques. Por eso Google lo calificó de gravedad baja.

Mecánica

Cómo funciona el fallo

Cuando Debuggerd analiza un proceso que ha fallado, intenta reconstruir qué estaba ejecutando. Para ello recorre la tabla de símbolos del archivo ELF, una estructura interna que da nombre a las funciones y variables del programa. Cada símbolo guarda, en un campo llamado st_name, un desplazamiento (offset): un número que indica en qué posición de otra tabla está almacenado el texto con el nombre de ese símbolo.

El error consistía en que Debuggerd usaba ese valor st_name como desplazamiento para copiar la cadena de texto sin comprobar que fuera válido. Como el contenido del archivo ELF lo controla quien lo crea, un atacante podía fijar un st_name arbitrariamente grande; al sumarlo para calcular la dirección del nombre, el cálculo se desbordaba y Debuggerd terminaba intentando leer una zona de memoria inaccesible. Esa lectura fuera de límites (en terminología de debilidades, CWE-125 «out-of-bounds read», provocada por un desbordamiento en el cálculo, CWE-190) hacía caer el depurador.

El detalle relevante es el vector de ataque: no es un fallo explotable desde la red. Para dispararlo hacía falta que en el dispositivo se instalara y ejecutara una aplicación maliciosa o reempaquetada que incluyera el archivo ELF manipulado. Al provocar el fallo, el estado del proceso —incluidos posibles fragmentos de memoria— quedaba registrado en los archivos tombstone y en logd, desde donde podían leerse. Esa información, de poco valor por sí misma, servía como pieza para montar ataques posteriores y sortear el ASLR.

Respuesta del creador

Respuesta del fabricante y de las autoridades

Según el relato de la divulgación, Trend Micro comunicó el problema a Google el 27 de abril de 2015. Google lo confirmó al día siguiente y lo clasificó como de gravedad baja. La corrección se incorporó al código abierto del sistema (Android Open Source Project, AOSP) el 15 de mayo de 2015, y Google confirmó que la siguiente versión del sistema, entonces conocida como «Android M» (Android 6, Marshmallow), ya no sería vulnerable.

Conviene situar este caso en su contexto: es anterior al programa de Boletines de Seguridad de Android mensuales, que Google no puso en marcha hasta agosto de 2015. Por eso el fallo no llegó a recibir un identificador CVE en la base NVD/MITRE ni una puntuación CVSS oficial. El único registro formal localizado es el chino CNVD-2015-04316, que lo cataloga con gravedad «media» y atribuye el hallazgo a Trend Micro. No consta que figure en el catálogo de vulnerabilidades explotadas conocidas de CISA (KEV) ni hay constancia de explotación real.

Parches y mitigaciones

Parches, versiones corregidas y qué hacer

La corrección está disponible desde hace años. El cambio en AOSP lo firmó el ingeniero de Google Christopher Ferris el 14-15 de mayo de 2015 en el componente external/libunwind (archivo src/elfxx.c), con el mensaje «Check for overflow when getting symbol name» y referencia al fallo interno bug 21162746. El parche añade una comprobación de desbordamiento al calcular la dirección del nombre del símbolo y descarta los símbolos que provocarían ese desbordamiento, de modo que un ELF malformado ya no puede forzar la lectura fuera de límites.

Versiones afectadas: Android 4.0 (Ice Cream Sandwich) a 5.x (Lollipop).
Versión corregida: la solución quedó integrada en AOSP en mayo de 2015 y el problema está resuelto en Android 6 (Marshmallow) y posteriores.

Qué hacer hoy: para la inmensa mayoría de usuarios no se requiere ninguna acción; cualquier dispositivo con Android 6 o superior no es vulnerable. El riesgo residual se limita a equipos muy antiguos que sigan con Android 5.x o anterior y que no hayan recibido actualizaciones. Para ellos, la recomendación general sigue vigente: mantener el sistema actualizado y, si el fabricante ya no ofrece parches, evitar instalar aplicaciones fuera de la tienda oficial, ya que el ataque exigía ejecutar en el dispositivo una app maliciosa o reempaquetada. No se publicaron mitigaciones provisionales específicas más allá de aplicar la actualización del sistema.