Investigadores de seguridad de Cisco detalles () en la implementación de la función memcpy() proporcionada por Glibc para la plataforma ARMv32 de 7 bits. El problema se debe al manejo incorrecto de los valores negativos del parámetro que determina el tamaño del área copiada, debido al uso de optimizaciones de ensamblaje que manipulan enteros de 32 bits con signo. Llamar a memcpy() en sistemas ARMv7 con un tamaño negativo da como resultado una comparación incorrecta de valores y escrituras en un área fuera de los límites del búfer especificado.
La vulnerabilidad se puede aprovechar para ejecutar código en una situación en la que el atacante puede organizar la formación de un valor negativo de la variable a través de la cual se transmite el tamaño de los datos copiados (por ejemplo, será negativo al transferir más de 2 GB de datos, pero durante el ataque, para ir más allá de los límites del búfer, es necesario transferir al menos 4 GB). La función memcpy() se usa ampliamente en aplicaciones, y los procesadores ARMv7 son comunes en sistemas automotrices, móviles, industriales, de consumo, de comunicaciones y dispositivos integrados, que están potencialmente sujetos a ataques mediante Bluetooth, HD Radio/DAB, USB, CAN bus, Wi-Fi Fi y otras fuentes de datos externas (por ejemplo, se pueden atacar servicios y aplicaciones accesibles a través de la red que aceptan datos de entrada sin restricciones de tamaño).
Un ejemplo es la creación de un exploit funcional para atacar un servidor HTTP integrado en los sistemas de información de los automóviles, al que se puede acceder a través de la red Wi-Fi del automóvil. Un atacante externo podría aprovechar una vulnerabilidad de memcpy en este servidor enviando una solicitud GET muy grande y obteniendo acceso raíz al sistema.
En sistemas x32 de 86 bits el problema no aparece, ya que la implementación de memcpy para esta arquitectura interpreta correctamente la variable tamaño como un valor entero sin signo de tipo size_t (en lenguaje ensamblador para ARMv7 se trata como un entero con signo en lugar de size_t). La solución está actualmente disponible como , que se incluirá en la actualización de agosto de Glibc 2.32.
La solución se reduce a reemplazar el uso de instrucciones de ensamblaje que operan en operandos firmados (bge y blt) con contrapartes sin firmar (blo y bhs).
El problema aún no se ha resuelto (no visible en Debian 8), , , OpenEmbedded, Tizen (utilizado por glibc). и El problema no se ve afectado porque no son compatibles con sistemas ARMv32 de 7 bits. Android no se ve afectado por la vulnerabilidad porque utiliza su propia implementación libc (Bionic). EN De forma predeterminada, la mayoría de las compilaciones usan Musl, pero glibc también está disponible en el repositorio.
Fuente: opennet.ru