Hoy traemos a la palestra una de esas noticias que asustan. Si pudiéramos apostarnos en la puerta de una redacción de noticias y echar un vistazo adentro veríamos a gente correr por los pasillos, timbres de teléfono sonando al unísono en una desesperante orquestación y el ruido furioso de una tormenta de teclas de plástico que estarán siendo golpeadas impunemente al son de unos tambores inexistentes. Casi podemos oler la mancha de café derramada sobre el borrador de un artículo sacrificado, en el que se describe con inusitado detalle, la cría y doma del escarabajo sumerio en tiempos de Uruk. Benditos los tiempos de Uruk murmura su autor mientras escribe en una nueva página en blanco: “Millones de teléfonos Android cuentan con desesperación los días antes de que llegue su Apocalipsis“.
Dejemos al pobre redactor y sus escarabajos para ver de cerca que es lo que está pasando en Android y qué tienen que temer sus poseedores.
Joshua J. Drake (@jduck) no necesita presentación. Es uno de los habituales. Investigador reputado, speaker y ctflaguero reincidente en conferencias de seguridad de prestigio. Drake se volcó hace ya tiempo en el mundillo Android, se subió al barco de la empresa Zimperium, especializada en seguridad para dispositivos móviles, y continuó allí su trabajo de investigación en este campo. A quienes seguían su trayectoria no les extraña que sea el descubridor de un fallo de categoría “agárrate que nos la vamos a pegar bien fuerte“.
El fallo se apoda Stagefright (podría traducirse como miedo escénico) y sí, si te asolaba la duda puedes descansar tranquilo: tiene un icono personalizado, aunque por razones obvias, no tiene una web asociada. El nombre no está escogido al azar. En realidad la librería vulnerable se llama así. Echemos un vistazo al esquema del mismo proyecto Android para ver donde se ubica:
 |
| fuente: http://source.android.com/devices/media.html |
Observamos que existe un componente nativo, escrito en C++, que es piedra angular del sistema de reproducción multimedia de Android. Estos componentes nativos tienen una razón de ser muy importante en el sistema. Android, en la capa de aplicación (API) presenta una implementación propia en el conocido lenguaje Java. Para ciertas tareas donde el consumo de memoria y los ciclos de CPU cotizan al alza el rendimiento de Java es prohibitivo. Para ello se emplean lenguajes que dominen el secreto y antiguo arte de los punteros y el manejo de memoria manual. Al final de la lista, siempre, o casi siempre, nos quedan dos candidatos: C o C++.
Hay tres cosas realmente complicadas para un ser humano con adiestramiento informático: Resolver P vs NP, justificar la barra de Ask en el instalador de Java y la gestión manual y segura de la memoria. Sobre éste último mito se han escrito canciones y contado miles de historias desde el albor de los tiempos de Epoch.
Drake atravesó las capas de Java y exploró las farragosas tierras de las librerías nativas encontrando al final un gran tesoro; del que solo nos falta ver el mapa.
Cuando Android recibe un archivo o flujo de datos con formato multimedia tiene que invocar la funcionalidad de procesamiento desde esta librería nativa ‘libstagefright‘. A partir de esa llamada la responsabilidad del proceso cae sobre un componente nativo, con todo su poder, con todos sus defectos.
¿Qué ocurre si la función encargada de reservar memoria de un búfer permite que cierto parámetro sea manipulado externamente? Desbordamiento de búfer. ¿Qué ocurriría si para calcular el final de un array me sobra un entero? Off-by-one. ¿Qué pasará sin esa variable es iniciada mediante una operación entre un entero con signo y un entero sin él? Comportamiento indefinido, consecuencias dependientes de la implementación.
Siete CVE se han apuntado a raíz de buscarle estos defectos a esta librería, queden aquí registrados:
CVE-2015-1538
CVE-2015-1539
CVE-2015-3824
CVE-2015-3826
CVE-2015-3827
CVE-2015-3828
CVE-2015-3829
Hay un detalle, el más impactante mediáticamente, en el que se puede ver como no es necesaria la intervención del usuario para que el terminal caiga en desgracia. Y sí, esto es tal como se ve. Cuando se recibe un mensaje multimedia (MMS) el sistema realiza una previsualización del archivo. Todo el mecanismo que se acciona para reproducir un simple vídeo, de forma similar se desencadena para crear esa previsualización. Es decir, la librería nativa en ambos casos ha de abrir el archivo o flujo, interpretar su cabecera, reservar memoria, acceder a los datos, descomprimirlos e interpretarlos para formar una imagen o una secuencia de estas (conocido también como, sorpresa, vídeo).
Debido a que las previsualizaciones se efectúan por obra y gracia del sistema, el veneno ya está en la sangre; antes de que puedas terminar la frase “me ca…” tu terminal se podría convertir en un estupendo ladrillo de diseño futurista o portador de lo que nuestros analistas de malware denominan cariñosamente: “un regalito“.
Son vulnerables las versiones de Android desde la 2.2 hasta la 5.1.1. Drake presentará los resultados de la investigación en la conferencia Black Hat USA del próximo 5 de agosto, así como en la DefCon 23 del 7 agosto. Hay un pequeño detalle. Al apuntar ellos mismos la librería donde están los fallos estamos seguros de que miles de IDAs están ahora mismo barriendo los bytes de este componente de arriba abajo en busca de los fallos antes de que las brechas se cierren; un filón.
El descubrimiento ha sido en modo responsable. Drake y compañía han coordinado esfuerzos para que el equipo de Google corrija los fallos y estos estén a disposición de los fabricantes. Algunos de ellos, una minoría, han propagado ya las actualizaciones pertinentes para sellar las grietas. Otros, como es de conocido sufrimiento, tardarán un poco más y otros no llegarán nunca.
¿Nunca? Efectivamente. ¿Os acordáis de esos sistemas Android que ya no verán actualizados sus vulnerables componentes WebView?
Más información:
Experts Found a Unicorn in the Heart of Android
David García
Twitter: @dgn1729
“el secreto y antiguo arte de los punteros y el manejo de memoria manual.” ja ja ja ja