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.
Fuente : linuxadictos
- Visto: 1318