Investigadores de Seguridade de Cisco os detalles () na implementación da función memcpy() proporcionada por Glibc para a plataforma ARMv32 de 7 bits. O problema é causado polo manexo incorrecto dos valores negativos do parámetro que determina o tamaño da área copiada, debido ao uso de optimizacións de conxunto que manipulan números enteiros de 32 bits con signo. A chamada a memcpy() en sistemas ARMv7 cun tamaño negativo produce unha comparación incorrecta de valores e escribe nunha área fóra dos límites do búfer especificado.
A vulnerabilidade pódese explotar para executar código nunha situación na que o atacante poida organizar a formación dun valor negativo da variable a través do cal se transmite o tamaño dos datos copiados (por exemplo, será negativo ao transferir máis de 2 GB de datos copiados). datos, pero durante o ataque, para ir máis alá dos límites do búfer, cómpre transferir polo menos 4 GB). A función memcpy() utilízase amplamente en aplicacións, e os procesadores ARMv7 son comúns en sistemas de automóbiles, dispositivos móbiles, industriais, de consumo, comunicacións e dispositivos integrados, que están potencialmente suxeitos a ataques mediante Bluetooth, HD Radio/DAB, USB, bus CAN, Wi-Fi e outras fontes de datos externas (por exemplo, pódense atacar servizos e aplicacións accesibles a través da rede que aceptan datos de entrada sen restricións de tamaño).
Un exemplo é a creación dun exploit de traballo para atacar un servidor HTTP integrado nos sistemas de información do automóbil, accesible a través da rede Wi-Fi do automóbil. Un atacante externo podería explotar unha vulnerabilidade memcpy neste servidor enviando unha solicitude GET moi grande e obter acceso root ao sistema.
Nos sistemas x32 de 86 bits, o problema non aparece, xa que a implementación de memcpy para esta arquitectura interpreta correctamente a variable de tamaño como un valor enteiro sen signo de tipo size_t (en linguaxe ensamblador para ARMv7 trátase como un enteiro con signo en lugar de size_t). A corrección está dispoñible actualmente como , que se incluirá na actualización de agosto Glibc 2.32.
A corrección redúcese a substituír o uso de instrucións de montaxe que operan en operandos asinados (bge e blt) por contrapartes sen asinar (blo e bhs).
O problema aínda non foi resolto (non visible en Debian 8), , , OpenEmbedded, Tizen (usado por glibc). и O problema non se ve afectado porque non admiten sistemas ARMv32 de 7 bits. Android non se ve afectado pola vulnerabilidade porque usa a súa propia implementación libc (Bionic). EN Por defecto, a maioría das compilacións usan Musl, pero a glibc tamén está dispoñible no repositorio.
Fonte: opennet.ru