Des chercheurs en sécurité de Cisco détails () dans l’implémentation de la fonction memcpy() fournie dans Glibc pour la plateforme ARMv7 32 bits. Le problème est causé par un traitement incorrect des valeurs négatives du paramètre définissant la taille de la zone copiée, dû à l'utilisation d'optimisations en assembleur manipulant des entiers signés de 32 bits. L'appel de memcpy() sur des systèmes ARMv7 avec une taille négative entraîne une comparaison incorrecte des valeurs et une écriture en dehors des limites du tampon spécifié.
La vulnérabilité peut être exploitée pour exécuter du code dans des situations où un attaquant peut provoquer la formation d'une valeur négative pour la variable qui transmet la taille des données copiées (par exemple, la valeur devient négative lors de la transmission de plus de 2 Go de données, mais pour que l'attaque sorte des limites du tampon, il faut transmettre au moins 4 Go). La fonction memcpy() est largement utilisée dans des applications, et les processeurs ARMv7 sont courants dans les systèmes automobiles, mobiles, industriels, grand public, de communication et dans les dispositifs intégrés, qui peuvent potentiellement être la cible d'attaques utilisant Bluetooth, HD Radio/DAB, USB, CAN bus, Wi-Fi et d'autres sources de données externes (par exemple, des services et applications accessibles via le réseau pouvant être attaqués en acceptant des entrées sans limite de taille).
À titre d'exemple, on citera la création d'un exploit fonctionnel pour cibler le serveur HTTP intégré dans les systèmes d'information automobiles, accessible via le réseau Wi-Fi du véhicule. Un attaquant externe peut exploiter la vulnérabilité dans memcpy sur ce serveur en envoyant une requête GET de taille très importante et obtenir un accès root au système.
Sur les systèmes 32 bits x86, le problème ne se manifeste pas, car l'implémentation de memcpy pour cette architecture interprète correctement la variable de taille comme une valeur entière non signée de type size_t (dans l’implémentation en assembleur pour ARMv7, au lieu de size_t, elle est traitée comme un entier signé). Le correctif est actuellement disponible sous la forme , qui fera partie de la mise à jour d'août de Glibc 2.32.
Le correctif consiste à remplacer l'usage des instructions assembleur manipulant des opérandes signés (bge et blt) par leurs analogues non signés (blo et bhs).
Le problème n'est pas encore résolu dans (ne se manifeste pas dans Debian 8), , , OpenEmbedded, Tizen (utilise glibc). et le problème n'affecte pas, car ils ne prennent pas en charge les systèmes ARMv7 32 bits. Android n'est pas vulnérable, car utilise sa propre implémentation de libc (Bionic). Dans la plupart des distributions utilise Musl par défaut, mais glibc est également disponible dans le dépôt.
Source : opennet.ru
