Jueves, Octubre 22, 2020

Los desarrolladores de Aurora OS incluyeron una corrección

vulnerabilidad

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.

 

Fuente: somoslibres

 

Protege-3-

¿Quién está en línea?

Hay 278 invitados y ningún miembro en línea

Contador de Visitas

11009140
Hoy Hoy 726
Ayer Ayer 3256
Esta semana Esta semana 10666
Este mes Este mes 64419
Total de Visitas Total de Visitas 11009140

Día con más
visitantes

10-20-2020 : 3356

Gracias por su visita