Investigadores de seguridad de Cisco detalles () en la implementación de la función memcpy() proporcionada en Glibc para plataformas ARMv7 de 32 bits. El problema se debe a un manejo incorrecto de valores negativos en el parámetro que define el tamaño del área copiada, debido al uso de optimizaciones en ensamblador que manipulan enteros de 32 bits con signo. Llamar a memcpy() en sistemas ARMv7 con un tamaño negativo provoca comparaciones de valores incorrectas y escrituras en áreas fuera de los límites del búfer especificado.
La vulnerabilidad puede ser explotada para ejecutar código en situaciones en las que un atacante puede manipular la generación de un valor negativo para la variable que transmite el tamaño de los datos copiados (por ejemplo, se producirá un valor negativo al transmitir más de 2 GB de datos, pero durante el ataque es necesario transmitir al menos 4 GB para desbordar el búfer). La función memcpy() se utiliza ampliamente en aplicaciones, y los procesadores ARMv7 están presentes en sistemas automotrices, dispositivos móviles, industriales, de consumo, de comunicación y embebidos, que potencialmente pueden ser objeto de ataques utilizando Bluetooth, HD Radio/DAB, USB, CAN bus, Wi-Fi y otras fuentes externas de datos (por ejemplo, servicios y aplicaciones accesibles en red que aceptan entradas sin restricciones de tamaño).
Como ejemplo, se presenta la creación de un exploit funcional para atacar al servidor http incorporado en los sistemas de infoentretenimiento del automóvil, accesible a través de la red Wi-Fi del vehículo. Un atacante externo puede explotar la vulnerabilidad en memcpy en este servidor al enviar una solicitud GET de tamaño muy grande y obtener acceso root al sistema.
En sistemas x86 de 32 bits, el problema no se manifiesta, ya que la implementación de memcpy para esta arquitectura interpreta correctamente la variable de tamaño como un valor entero sin signo del tipo size_t (en el ensamblador, para ARMv7 se maneja como un entero con signo). La corrección está disponible por ahora como , que formará parte de la actualización de agosto de Glibc 2.32.
La corrección consiste en reemplazar el uso de instrucciones de ensamblador que operan con operandos con signo (bge y blt) por análogos sin signo (blo y bhs).
El problema aún no se ha solucionado en (no se manifiesta en Debian 8). , , OpenEmbedded, Tizen (utiliza glibc). y el problema no afecta, ya que no soportan sistemas ARMv7 de 32 bits. Android no es vulnerable, ya que utiliza su propia implementación de libc (Bionic). En la mayoría de las compilaciones usa Musl por defecto, pero en el repositorio también se encuentra glibc.
Fuente: opennet.ru
