L'entreprise Checkpoint mécanisme de protection Safe-Linking, permettant de compliquer la création d'exploits manipulant la définition ou la modification des pointeurs vers les buffers alloués lors de l'appel de malloc. Safe-Linking ne bloque pas complètement la possibilité d'exploiter des vulnérabilités, mais compliquer de manière significative la création de certaines catégories d'exploits avec des frais minimes, car en plus du débordement de buffer exploité, il est nécessaire de trouver une autre vulnérabilité provoquant une fuite d'informations sur l'emplacement du tas en mémoire.
Des patches implémentant Safe-Linking ont été préparés pour Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) et Google TCMalloc, et aussi proposés pour la modernisation de la protection dans Chromium (dans
Chromium, une technique de protection orientée vers la même problématique, MaskPtr, a déjà été intégrée depuis 2012, mais la solution de Checkpoint démontre une performance supérieure).
Les patches proposés ont déjà été approuvés pour inclusion dans la version d'août et l'application de Safe-Linking sera incluse par défaut. Dans uClibc-NG, le support de Safe-Linking sera intégré dans la version 1.0.33 et inclus par défaut. Dans gperftools (ancien tcmalloc), des modifications seront proposées dans une des futures versions comme option.
Développeurs (nouveau tcmalloc) a refusé d'accepter , invoquant une forte baisse de performance et la nécessité d'ajouter des tests étendus pour vérifier régulièrement que tout fonctionne correctement. Les tests menés par des ingénieurs de Checkpoint ont montré que la méthode Safe-Linking n'entraîne pas de dépenses mémoire supplémentaires, alors que la performance lors des opérations sur le tas ne diminue en moyenne que de 0,02 %, et dans le pire des cas, de 1,5 % (à titre de comparaison, les frais encourus par la méthode utilisée dans Chromium sont estimés à « moins de 2 % »). L'activation
de Safe-Linking entraîne l'exécution de 2 à 3 instructions assembleur supplémentaires à chaque appel de free() et 3 à 4 instructions lors de l'appel de malloc(). Aucune phase d'initialisation ou de génération de valeurs aléatoires n'est requise.
Le Safe-Linking peut être appliqué non seulement pour améliorer la sécurité des différentes implémentations de tas, mais aussi pour ajouter des moyens de contrôle d'intégrité dans toutes les structures de données où des listes chaînées de pointeurs sont utilisées, placées à côté des buffers eux-mêmes. La méthode est très simple à mettre en œuvre et nécessite seulement l'ajout d'un macro et son application aux pointeurs vers le prochain bloc dans le code (par exemple, pour Glibc par seulement quelques lignes de code). La méthode se résume aux modifications suivantes :
+#define PROTECT_PTR(pos, ptr) \
+ ((__typeof (ptr)) ((((size_t) pos) >> 12) ^ ((size_t) ptr)))
+#define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)
— nextp = p->fd;
+ nextp = REVEAL_PTR (p->fd);
…
L'essence de la méthode réside dans l'utilisation de données aléatoires provenant du mécanisme de randomisation des adresses ASLR (mmap_base) pour protéger les listes chaînées, telles que Fast-Bins et TCache. Avant d'appliquer à la valeur du pointeur vers l'élément suivant dans la liste, une transformation par masque et un contrôle d'alignement à la limite de la page mémoire sont effectués. 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 dans la mémoire où ce pointeur est stocké.
Lors de l'utilisation dans un système (Randomisation de la Mise en Page de l'Espace d'Adresse) une partie des bits L avec l'adresse de base du tas contient des valeurs aléatoires, qui sont utilisées comme clé pour le codage de P (extraites par un décalage de 12 bits pour des pages de 4096 octets). Une telle manipulation réduit le risque de capture du pointeur dans un exploit, car le pointeur n'est pas stocké sous sa forme originale et son remplacement nécessite de connaître des informations sur la disposition du tas. De plus, le code du patch contient également une vérification supplémentaire de l'alignement du bloc, ce qui empêche un attaquant de remplacer le pointeur par une valeur non alignée et exige la connaissance du nombre de bits par lesquels l'alignement a été effectué, ce qui sur les systèmes 64 bits bloque en outre 15 des 16 tentatives d'attaques qui ne prennent pas en compte l'alignement.
La méthode est efficace pour se protéger contre les attaques utilisant la réécriture partielle de pointeurs (changement des octets de poids faible), la réécriture complète de pointeurs (redirection vers le code de l'attaquant) et le changement de position de la liste à une adresse non alignée. Par exemple, il a été démontré que l'application de Safe-Linking dans malloc permettrait de bloquer l'exploitation récemment par les mêmes chercheurs de vulnérabilités dans l'éclairage intelligent Philips Hue Bridge, causée par un débordement de tampon, permit de prendre le contrôle de l'appareil.
Source : opennet.ru
