Los desarrolladores del sistema operativo móvil AuroraOS (un fork del sistema operativo Sailfish, desarrollado por la compañía Open Mobile Platform) compartieron una solución para una vulnerabilidad que detectaron en memcpy. La eliminación de la vulnerabilidad crítica (CVE-2020-6096) en Glibc, que se manifiesta solo en la plataforma ARMv7.

La información sobre la vulnerabilidad se reveló en mayo, pero hasta los últimos días, las correcciones no estaban disponibles, a pesar de que a la vulnerabilidad se le asignó un alto nivel de peligro y hay un prototipo funcional del exploit que permite organizar la ejecución del código.

El exploit preparado actúa durante el procesamiento en las funciones memcpy() y memmove() por ciertos datos formateados.

La importancia de Glibc, es que esta biblioteca define las llamadas al sistema y otras funciones básicas además de que es utilizada por casi todos los programas.

Sobre el problema

La vulnerabilidad se manifestó en la implementación de memcpy() y memmove() en lenguaje ensamblador para ARMv7 y fue causada por el procesamiento incorrecto de los valores negativos del parámetro que determina el tamaño del área.

Los problemas con el desarrollo de parches comenzaron cuando SUSE y Red Hat anunciaron que sus plataformas no se vieron afectadas por el problema, ya que no formaron compilaciones para sistemas ARMv7 de 32 bits y no participaron en la creación del parche.

Los desarrolladores de muchas distribuciones incrustadas aparentemente confiaron en el equipo de Glibc, y tampoco tomaron parte activa en la preparación del parche.

Soluciones

Huawei ofreció una opción para un parche para bloquear el problema casi de inmediato, que trató de reemplazar las instrucciones del ensamblador que operan en operandos firmados (bge y blt) con análogos sin firmar (blo y bhs).

Los mantenedores de Glibc desarrollaron un conjunto de pruebas para probar diferentes condiciones para la ocurrencia de un error, después de lo cual resultó que el parche de Huawei no se ajusta y no procesa todas las combinaciones posibles de datos de entrada.

Dado que AuroraOS tiene una compilación de 32 bits para ARM, sus desarrolladores decidieron cerrar la vulnerabilidad por su cuenta y proponer una solución a la comunidad.

La dificultad era que, era necesario escribir una implementación efectiva de ensamblador de la función y tener en cuenta varias opciones para los argumentos de entrada.

La implementación ha sido reescrita usando instrucciones sin firmar. El parche resultó ser pequeño, pero el problema principal era mantener la velocidad de ejecución y eliminar la degradación del rendimiento de las funciones memcpy y memmove, manteniendo la compatibilidad con todas las combinaciones de valores de entrada.

A principios de junio, se prepararon dos soluciones, pasando el marco de prueba de mantenimiento de Glibc y el conjunto de pruebas internas de Aurora. El 3 de junio, una de las opciones fue seleccionada y enviada a la lista de correo de Glibc.

Una semana después, se propuso otro enfoque similar, que solucionó el problema en la implementación multiarch, que Huawei había tratado de solucionar previamente. Un mes tomó pruebas y legalización en vista de la importancia del parche.

El 8 de julio, se aceptaron correcciones en la rama principal del próximo lanzamiento de glibc 2.32. La aplicación incluye dos parches:

• La primera para una aplicación Multiarch de establecimiento de memoria para ARMv7
• El segundo para una implementación de ensamblador común de memcpy () y memmove () para ARM.

El problema afecta a millones de dispositivos Linux ARMv7 y sin una actualización adecuada, los propietarios se arriesgan a conectarlos a la red (los servicios y aplicaciones disponibles en la red que aceptan entradas sin restricciones de tamaño pueden ser atacados).

Por ejemplo, un exploit preparado por investigadores que descubrieron la vulnerabilidad muestra cómo atacar un servidor http integrado en el sistema de información del automóvil mediante la transmisión de una solicitud GET muy grande y obtener acceso de root al sistema.

Las soluciones de paquetes para Debian y Ubuntu aún no se ha publicado y la vulnerabilidad permanece sin corregir durante casi dos meses desde el momento de la divulgación pública y cinco meses desde el momento en que se notificó a los desarrolladores de Glibc.