Glibc inclut un correctif pour la vulnérabilité memcpy préparé par les développeurs d'Aurora OS

Les développeurs du système d'exploitation mobile Aurora (un fork du Sailfish OS développé par la société Open Mobile Platform) ont partagé une histoire révélatrice sur l'élimination vulnérabilité critique (CVE-2020-6096) dans Glibc, qui apparaît uniquement sur la plateforme ARMv7. Des informations sur la vulnérabilité ont été divulguées en mai, mais jusqu'à ces derniers jours, aucun correctif n'était disponible, malgré le fait que les vulnérabilités attribué un niveau de danger élevé et il existe un prototype fonctionnel d'un exploit qui vous permet d'organiser l'exécution de code lors du traitement de données formatées d'une certaine manière dans les fonctions memcpy() et memmove(). Correctifs de package pour Debian и Ubuntu n'ont pas encore été publiées et la vulnérabilité reste non corrigée pendant près de deux mois à partir du moment de la divulgation publique et cinq mois à partir du moment où les développeurs de Glibc en ont été informés.

La vulnérabilité s'est manifestée dans l'implémentation en langage assembleur de memcpy() et memmove() pour ARMv7 et a été causée par une gestion incorrecte des valeurs négatives du paramètre qui détermine la taille de la zone copiée. Les problèmes liés au développement de correctifs ont commencé lorsque les entreprises SUSE и Red Hat a annoncé que leurs plates-formes ne sont pas affectées par le problème, car elles ne sont pas conçues pour les systèmes ARMv32 7 bits et n'ont pas participé à la création d'un correctif. Les développeurs de nombreuses distributions embarquées semblent s'être appuyés sur l'équipe Glibc et n'ont pas non plus été activement impliqués dans la préparation du correctif.

Option correctif Pour résoudre le problème, Huawei a presque immédiatement proposé d'essayer de remplacer les instructions d'assemblage fonctionnant avec des opérandes signés (bge et blt) par des analogues non signés (blo et bhs). Les responsables de la Glibc ont développé un ensemble de tests pour vérifier diverses conditions d'erreur, après quoi il s'est avéré que le correctif Huawei n'était pas adapté et ne traitait pas toutes les combinaisons possibles de données d'entrée.

Étant donné qu'Aurora OS dispose d'une version 32 bits pour ARM, ses développeurs ont décidé de supprimer eux-mêmes la vulnérabilité et de proposer une solution à la communauté. La difficulté était qu'il était nécessaire d'écrire une implémentation efficace de la fonction en langage assembleur et de prendre en compte diverses options pour les arguments d'entrée. L'implémentation a été réécrite à l'aide d'instructions non signées. Patch Il s'est avéré petit, mais le principal problème était de maintenir la vitesse d'exécution et d'éviter la dégradation des performances des fonctions memcpy et memmove, tout en maintenant la compatibilité avec toutes les combinaisons de valeurs d'entrée.

Début juin, deux versions du correctif ont été préparées, passant avec succès le framework de tests des mainteneurs de la Glibc et la suite de tests interne d'Aurora. Le 3 juin, l'une des options a été choisie et expédié à la liste de diffusion Glibc. Une semaine plus tard
était suggéré un autre correctif d'approche similaire, qui corrigeait un problème dans l'implémentation multiarch, que Huawei avait précédemment tenté de résoudre. Les tests ont duré un mois et enregistrement légal en raison de l'importance du patch.
Corrections du 8 juillet ont été acceptés à la branche principale de la prochaine version de la glibc 2.32. L'implémentation comprend deux correctifs - premier pour l'implémentation multiarch de memcpy pour ARMv7, et deuxième pour l'implémentation en langage assembleur général de memcpy() et memmove() pour ARM.

Le problème affecte des millions d'appareils ARMv7 exécutant Linux, et sans la mise à jour appropriée, les propriétaires courent un risque lorsqu'ils les connectent au réseau (les services et applications accessibles au réseau qui acceptent les données d'entrée sans restrictions de taille peuvent être attaqués). Par exemple, l'exploit préparé par les chercheurs qui ont identifié la vulnérabilité montre comment attaquer un serveur HTTP intégré à un système d'information automobile en envoyant une très grande requête GET et en obtenant un accès root au système.

Source: opennet.ru

Ajouter un commentaire