Point de contrôle (un fournisseur mondial de solutions de sécurité informatique) a publié il y a plusieurs jours l'introduction du mécanisme de sécurité "Safe-Linking", Quoi rend difficile la création d'exploits qui manipulent la définition ou la modification des pointeurs vers les tampons alloués lors d'un appel malloc.
Le nouveau mécanisme «Safe-Linking» ne bloque pas complètement la possibilité d'exploiter les vulnérabilités, mais avec des frais généraux minimes complique la création de certaines catégories d'exploitsComme en plus du débordement de tampon exploité, il est nécessaire de trouver une autre vulnérabilité qui provoque des informations sur l'emplacement du tas en mémoire.
Des correctifs d'implémentation Safe-Linking ont été préparés pour Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) et Google TCMalloc, ainsi qu'une proposition de modernisation de la protection dans Chromium (depuis 2012 Chromium a déjà été intégré avec des solutions au même problème) Technique de protection MaskPtr, mais la solution de Checkpoint montre de meilleures performances).
Les correctifs proposés ont déjà été approuvés pour livraison dans la version d'août de Glibc 3.32 et Safe-Linking sera activé par défaut. Dans uClibc-NG, la prise en charge des liens sécurisés était incluse dans la version 1.0.33 et est activée par défaut. Dans gperftools (ancien tcmalloc), les modifications sont acceptées, mais seront proposées en option dans une prochaine version.
Les développeurs de TCMalloc ont refusé d'accepter le changement, cavec de solides performances et la nécessité d'ajouter des tests avancés pour vérifier régulièrement que tout fonctionne correctement.
Tests réalisés par Les ingénieurs de Check Point ont montré que la méthode Safe-Linking n'entraînait pas de consommation de mémoire supplémentaire et les performances lors de l'exécution d'opérations de tas en moyenne ne diminuent que de 0.02%, et dans le pire des cas de 1.5%
L'activation de Safe-Linking conduit à l'exécution de 2-3 instructions assembleur supplémentaires à chaque appel à free () et 3-4 instructions lors de l'appel de malloc (). Le démarrage de l'initialisation et la génération de valeurs aléatoires ne sont pas nécessaires.
Safe-Linking peut être utilisé non seulement pour augmenter la sécurité de diverses implémentations de tas, sino également pour ajouter des contrôles d'intégrité à toute structure de données qui utilise une liste de pointeurs liés individuellement situés à côté des tampons.
La méthode il est très simple à mettre en œuvre et ne nécessite que l'ajout d'une macro et appliquez-le aux pointeurs vers le bloc suivant du code (par exemple, pour Glibc, seules quelques lignes sont modifiées dans le code).
L'essence de la méthode est d'appliquer des données aléatoires du mécanisme de randomisation d'adresse ASLR (mmap_base) pour protéger individuellement les listes liées telles que Fast-Bins et TCache. Avant d'appliquer la valeur du pointeur à l'élément suivant dans la liste, la conversion du masque et la vérification de l'alignement sont effectuées le long du bord de la page mémoire. 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 en mémoire où ce pointeur est stocké.
Lorsqu'ils sont utilisés dans le système ASLR (Address Space Layout Randomization), certains des L bits avec l'adresse de base du tas contiennent des valeurs aléatoires qui sont utilisées comme clé pour coder P (elles sont extraites par une opération de décalage de 12 bits pour les pages de 4096 octets).
Une telle manipulation réduit le risque de capturer un pointeur dans un exploit, étant donné que le pointeur n'est pas stocké dans sa forme d'origine et que pour le remplacer, vous devez connaître les informations sur l'emplacement du tas.
La méthode est efficace pour se protéger contre les attaques qui utilisent la redéfinition partielle du pointeur (décalage d'octet bas), réécriture complète des pointeurs (redirection vers le code de l'attaquant) et repositionnement de la liste dans une direction non alignée.
A titre d'exemple, il est montré que l'utilisation de Safe-Linking dans malloc bloquerait l'exploitation de la vulnérabilité CVE-2020-6007 récemment découverte par les mêmes chercheurs dans le rétroéclairage intelligent du pont Philips Hue causé par le buffer overflow et permettant de contrôler l'appareil.
source: https://research.checkpoint.com