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:
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
