Développeurs du système d'exploitation mobile AuroraOS (un fork du système d'exploitation Sailfish, développé par la société Open Mobile Platform) a partagé un correctif pour une vulnérabilité qu'ils ont détecté dans memcpy. Élimination de la vulnérabilité critique (CVE-2020-6096) à Glibc, qui se manifeste uniquement sur la plate-forme ARMv7.
Des informations sur la vulnérabilité ont été révélées en mai, mais jusqu'aux derniers jours, les correctifs n'étaient pas disponibles, même si la vulnérabilité était associée à un niveau de il y a un prototype fonctionnel de l'exploit cela permet d'organiser l'exécution du code.
L'exploit préparé agit pendant le traitement dans les fonctions memcpy () et memmove () pour certaines données formatées.
L'importance de Glibc est que cette bibliothèque définit les appels système et d'autres fonctions de base en plus d'être utilisée par presque tous les programmes.
Au sujet du problème
La vulnérabilité manifestée dans l'implémentation de memcpy () et memmove () en langage d'assemblage pour ARMv7 et cela a été causé par un traitement incorrect des valeurs négatives du paramètre qui détermine la taille de la zone.
Problèmes de développement de correctifs commencés lorsque SUSE et Red Hat ont annoncé que leurs plates-formes n'étaient pas affectées à cause du problème, car ils n'ont pas compilé pour les systèmes ARMv7 32 bits et n'ont pas participé à la création du correctif.
Les développeurs de nombreuses distributions intégrées ont apparemment fait confiance à l'équipe Glibc et n'ont pas non plus pris une part active à la préparation du correctif.
Solutions
Huawei a offert une option pour un patch pour bloquer le problème presque immédiatement, qui a essayé de remplacer les instructions assembleur qui opèrent sur 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é une suite de tests pour tester différentes conditions d'occurrence d'une erreur, après qui s'est avéré que le patch de Huawei ne convient pas et il ne traite pas toutes les combinaisons possibles de données d'entrée.
Étant donné que AuroraOS a une version 32 bits pour ARM, Son les développeurs ont décidé de fermer eux-mêmes la vulnérabilité et proposer une solution à la communauté.
La difficulté était qu'il fallait rédiger une mise en œuvre efficace assembleur de la fonction et considérez plusieurs options pour les arguments d'entrée.
L'implémentation a été réécrite à l'aide d'instructions non signées. Le correctif s'est avéré être petit, mais le principal problème était de maintenir la vitesse d'exécution et d'éliminer 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 solutions ont été préparées, passer le cadre de test de maintenance de Glibc et la suite de tests internes d'Aurora Le 3 juin, l'une des options a été sélectionnée et soumise à la liste de diffusion Glibc.
Une semaine plus tard, une autre approche similaire a été proposée, qui a résolu le problème de la mise en œuvre multi-archivage, que Huawei avait précédemment tenté de résoudre. Un mois a pris des tests et une légalisation compte tenu de l'importance du patch.
Le 8 juillet, les correctifs ont été acceptés dans la branche principale de la prochaine version de la glibc 2.32. L'application comprend deux patchs:
- Le premier pour une application Multiarch à établissement de mémoire pour ARMv7
- Le second pour une implémentation d'assembleur commune de memcpy () et memmove () pour ARM.
Le problème affecte des millions de périphériques Linux ARMv7 et sans une mise à jour appropriée, les propriétaires risquent de les connecter au réseau (les services et applications disponibles sur le réseau qui acceptent les entrées sans restriction de taille peuvent être attaqués).
Par exemple, un exploit préparé par des chercheurs qui découvert la vulnérabilité montre comment attaquer un serveur http intégré dans le système d'information de la voiture en transmettant une très grande requête GET et en obtenant un accès root au système.
Les solutions de package pour Debian et Ubuntu n'ont pas encore été publiées y la vulnérabilité reste non corrigée pendant près de deux mois à compter de la divulgation publique et cinq mois à partir du moment où les développeurs Glibc ont été informés.