Checkpoint a proposé une technique de protection Safe-Linking, rendant plus difficile l'exploitation des vulnérabilités

Société de point de contrôle présenté Mécanisme de protection Safe-Linking, qui rend difficile la création d'exploits manipulant la définition ou la modification des pointeurs vers les tampons alloués lors de l'exécution d'un appel malloc. Safe-Linking ne bloque pas complètement la possibilité d'exploiter les vulnérabilités, mais avec une surcharge minimale, il complique considérablement la création de certaines catégories d'exploits, car en plus du débordement de tampon exploitable, il est nécessaire de trouver une autre vulnérabilité qui provoque une fuite d'informations sur le placement du tas en mémoire.

Des correctifs implémentant Safe-Linking ont été préparés pour Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) et Google TCMalloc, et sont également proposés pour mettre à niveau la protection dans Chromium (en
Depuis 2012, Chromium a déjà intégré la technique de protection MaskPtr visant à résoudre le même problème, mais la solution de Checkpoint démontre des performances supérieures.
Les correctifs suggérés ont déjà été approuvés pour livraison dans la version d'août Glibc 3.32 et Safe-Linking sera activé par défaut. uClibc-NG prend en charge la liaison sécurisée entré inclus dans la version 1.0.33 et est activé par défaut. Modifications dans gperftools (ancien tcmalloc) accepté, mais sera proposé en option dans une prochaine version.

Développeurs TCMalloc (nouveau tcmalloc) a refusé d'accepter changer, citant une grave dégradation des performances et la nécessité d'ajouter des tests approfondis pour vérifier régulièrement que tout fonctionne comme prévu. Les tests effectués par les ingénieurs de Checkpoint ont montré que la méthode Safe-Linking n'entraîne pas de consommation de mémoire supplémentaire et que les performances lors de l'exécution d'opérations sur le tas sont réduites en moyenne de seulement 0.02 %, et dans le pire des cas de 1.5 % (à titre de comparaison, les frais généraux dans la méthode utilisée dans Chromium sont estimés à « moins de 2 % »). Inclusion
Safe-Linking entraîne l'exécution de 2 à 3 instructions d'assemblage supplémentaires à chaque fois que free() est appelé, et de 3 à 4 instructions à chaque fois que malloc() est appelé. L’exécution des étapes d’initialisation et de génération de valeurs aléatoires n’est pas requise.

Checkpoint a proposé une technique de protection Safe-Linking, rendant plus difficile l'exploitation des vulnérabilités

Safe-Linking peut être utilisé non seulement pour améliorer la sécurité de diverses implémentations de tas, mais également pour ajouter des contrôles d'intégrité à toutes les structures de données qui utilisent des listes de pointeurs à liaison unique placées à côté des tampons eux-mêmes. La méthode est très simple à mettre en œuvre et nécessite uniquement l'ajout d'une macro et son application aux pointeurs vers le bloc suivant dans le code (par exemple, pour Glibc est en train de changer juste quelques lignes de code). La méthode se résume aux changements suivants :

+#définir PROTECT_PTR(pos, ptr) \
+ ((__typeof (ptr)) ((((size_t) pos) >> 12) ^ ((size_t) ptr)))

+#définir REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)

- nextp = p->fd;
+ nextp = REVEAL_PTR (p->fd);
...

L'essence de la méthode est d'utiliser des données aléatoires du mécanisme de randomisation d'adresse ASLR (mmap_base) pour protéger les listes à chaînage unique telles que Fast-Bins et TCache. Avant que la valeur ne soit appliquée à un pointeur vers l'élément suivant de la liste, il effectue une conversion de masque et vérifie l'alignement de la page. Le pointeur est remplacé par le résultat de l'opération "(L >> PAGE_SHIFT) XOR (P)", où P est la valeur du pointeur et L est l'emplacement mémoire où le pointeur est stocké.

Checkpoint a proposé une technique de protection Safe-Linking, rendant plus difficile l'exploitation des vulnérabilités

Lorsqu'il est utilisé dans le système ASLR (Address Space Layout Randomization) une partie des bits L avec l'adresse de base du tas contient des valeurs aléatoires qui sont utilisées comme clé pour coder P (extraites par une opération de décalage de 12 bits pour des pages de 4096 octets). Cette manipulation réduit le risque de détournement de pointeur dans un exploit, puisque le pointeur n'est pas stocké sous sa forme originale et que son remplacement nécessite la connaissance de l'allocation du tas. De plus, le code du correctif contient également une vérification supplémentaire de l'alignement des blocs, qui ne permet pas à un attaquant de remplacer un pointeur par une valeur non alignée et nécessite de connaître le nombre de bits alignés, ce qui sur les systèmes 64 bits permet en outre le blocage. 15 tentatives d'attaque sur 16 qui ne tiennent pas compte de l'alignement.

La méthode est efficace pour se protéger contre les attaques utilisant la réécriture partielle du pointeur (modification des octets faibles), la réécriture complète du pointeur (redirection vers le code de l'attaquant) et la modification de la position de la liste à une adresse non alignée. A titre d'exemple, il est montré que l'utilisation du Safe-Linking dans malloc permettrait de bloquer l'exploitation récente identifié par les mêmes chercheurs en vulnérabilité CVE-2020-6007 dans la lumière intelligente Philips Hue Bridge, provoquée par un débordement de tampon et vous permettant de prendre le contrôle de l'appareil.

Source: opennet.ru

Ajouter un commentaire