2 de agosto de 2015

ANDROID. Detalles técnicos del fallo crítico anunciado el lunes

Joshua J. Drake (@jduck), investigador reputado, speaker y ctflaguero reincidente en conferencias de seguridad de prestigio., 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 este fallo de seguridad
El fallo apodado Stagefright (podría traducirse como miedo escénico) no está escogido al azar. En realidad la librería vulnerable se llama así.
Recursos afectados
  • Son vulnerables las versiones de Android desde la 2.2 hasta la 5.1.1.
Detalle del fallo de seguridad
  • En el esquema del mismo proyecto Android, de pie de post, podemos observar 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".
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. Y otros quizás no lleguen nunca.
Más información:
Fuente: Hispasec