Chercheurs en sécurité Cisco détails () dans l'implémentation de la fonction memcpy() fournie par la Glibc pour la plateforme ARMv32 7 bits. Le problème est dû à une gestion incorrecte des valeurs négatives du paramètre qui détermine la taille de la zone copiée, en raison de l'utilisation d'optimisations d'assemblage qui manipulent des entiers signés de 32 bits. L'appel de memcpy() sur les systèmes ARMv7 avec une taille négative entraîne une comparaison incorrecte des valeurs et écrit dans une zone en dehors des limites du tampon spécifié.
La vulnérabilité peut être exploitée pour exécuter du code dans une situation où l'attaquant peut organiser la formation d'une valeur négative de la variable à travers laquelle la taille des données copiées est transmise (par exemple, elle deviendra négative lors du transfert de plus de 2 Go de données, mais lors de l'attaque, pour dépasser les limites du tampon, il faut transférer au moins 4 Go). La fonction memcpy() est largement utilisée dans les applications, et les processeurs ARMv7 sont courants dans les systèmes automobiles, mobiles, industriels, grand public, de communication et embarqués, qui sont potentiellement sujets à des attaques utilisant Bluetooth, HD Radio/DAB, USB, bus CAN, Wi-Fi Fi et autres sources de données externes (par exemple, les services et applications accessibles sur le réseau qui acceptent les données d'entrée sans restrictions de taille peuvent être attaqués).
Un exemple est la création d'un exploit fonctionnel pour attaquer un serveur HTTP intégré aux systèmes d'information automobile, accessible via le réseau Wi-Fi automobile. Un attaquant extérieur pourrait exploiter une vulnérabilité memcpy sur ce serveur en envoyant une très grande requête GET et obtenir un accès root au système.
Sur les systèmes x32 86 bits, le problème n'apparaît pas, puisque l'implémentation memcpy pour cette architecture interprète correctement la variable size comme une valeur entière non signée de type size_t (en langage assembleur pour ARMv7, il est traité comme un entier signé au lieu de size_t). Le correctif est actuellement disponible sous , qui sera inclus dans la mise à jour d'août de la Glibc 2.32.
Le correctif se résume à remplacer l'utilisation d'instructions d'assemblage qui opèrent sur des opérandes signés (bge et blt) par des homologues non signés (blo et bhs).
Le problème n'est pas encore résolu (non visible dans Debian 8), , , OpenEmbedded, Tizen (utilisé par la glibc). и Le problème n'est pas affecté car ils ne prennent pas en charge les systèmes ARMv32 7 bits. Android n'est pas affecté par la vulnérabilité car il utilise sa propre implémentation libc (Bionic). DANS Par défaut, la plupart des builds utilisent Musl, mais la glibc est également disponible dans le référentiel.
Source: opennet.ru