Los desarrolladores del sistema operativo móvil Aurora (una bifurcación del sistema operativo Sailfish desarrollado por la empresa Open Mobile Platform) compartieron una historia reveladora sobre cómo eliminar () en Glibc, que aparece solo en la plataforma ARMv7. La información sobre la vulnerabilidad se reveló en mayo, pero hasta hace poco no había soluciones disponibles, a pesar de que las vulnerabilidades un alto nivel de peligro y existe un prototipo funcional de un exploit que permite organizar la ejecución del código al procesar datos formateados de cierta manera en las funciones memcpy() y memmove(). Correcciones de paquetes para и aún no se han publicado y la vulnerabilidad permanece sin solucionar 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.
La vulnerabilidad se manifestó en la implementación de memcpy() y memmove() en lenguaje ensamblador para ARMv7 y fue causada por un procesamiento incorrecto de los valores negativos del parámetro que determina el tamaño del área copiada. Los problemas con el desarrollo de parches comenzaron cuando las empresas и anunció que sus plataformas no se ven afectadas por el problema, ya que no construyen para sistemas ARMv32 de 7 bits y no participaron en la creación de una solución. Los desarrolladores de muchas distribuciones integradas parecen haber confiado en el equipo de Glibc y tampoco han participado activamente en la preparación de la solución.
Opción Para bloquear el problema, Huawei propuso casi de inmediato intentar reemplazar las instrucciones de ensamblaje que operan con operandos firmados (bge y blt) con análogos sin firmar (blo y bhs). Los mantenedores de Glibc desarrollaron una serie de pruebas para verificar varias condiciones de error, después de lo cual resultó que el parche de Huawei no era adecuado y no procesaba todas las combinaciones posibles de datos de entrada.
Dado que Aurora OS tiene una versión de 32 bits para ARM, sus desarrolladores decidieron cerrar la vulnerabilidad por su cuenta y ofrecer una solución a la comunidad. La dificultad era que era necesario escribir una implementación eficiente de la función en lenguaje ensamblador y tener en cuenta varias opciones para los argumentos de entrada. La implementación se ha reescrito utilizando instrucciones sin firmar. Resultó ser pequeño, pero el principal problema era mantener la velocidad de ejecución y evitar la degradación del rendimiento de las funciones memcpy y memmove, manteniendo al mismo tiempo la compatibilidad con todas las combinaciones de valores de entrada.
A principios de junio, se prepararon dos versiones de la solución, pasando el marco de prueba de los mantenedores de Glibc y el conjunto de pruebas interno de Aurora. El 3 de junio se eligió una de las opciones y a la lista de correo de Glibc. Una semana después
era otro parche de enfoque similar, que corrigió un problema en la implementación multiarca, que Huawei había intentado solucionar anteriormente. Las pruebas duraron un mes y debido a la importancia del parche.
Correcciones del 8 de julio a la rama principal de la próxima versión glibc 2.32. La implementación incluye dos parches: para la implementación multiarca de memcpy para ARMv7, y para la implementación general en lenguaje ensamblador de memcpy() y memmove() para ARM.
El problema afecta a millones de dispositivos ARMv7 que ejecutan Linux y, sin la actualización adecuada, los propietarios corren riesgo al conectarlos a la red (los servicios accesibles a la red y las aplicaciones que aceptan datos de entrada sin restricciones de tamaño pueden ser atacados). Por ejemplo, el exploit preparado por los investigadores que identificaron la vulnerabilidad muestra cómo atacar un servidor HTTP integrado en el sistema de información de un automóvil enviando una solicitud GET muy grande y obteniendo acceso raíz al sistema.
Fuente: opennet.ru