Memory Tagging Extension (MTE)

Reading time: 6 minutes

Informations de base

Memory Tagging Extension (MTE) est conçu pour améliorer la fiabilité et la sécurité des logiciels en détectant et en prévenant les erreurs liées à la mémoire, telles que les débordements de tampon et les vulnérabilités d'utilisation après libération. MTE, en tant que partie de l'architecture ARM, fournit un mécanisme pour attacher un petit tag à chaque allocation de mémoire et un tag correspondant à chaque pointeur référencant cette mémoire. Cette approche permet de détecter les accès mémoire illégaux à l'exécution, réduisant ainsi considérablement le risque d'exploiter de telles vulnérabilités pour exécuter du code arbitraire.

Comment fonctionne l'extension de balisage de mémoire

MTE fonctionne en divisant la mémoire en petits blocs de taille fixe, chaque bloc se voyant attribuer un tag, généralement de quelques bits.

Lorsqu'un pointeur est créé pour pointer vers cette mémoire, il reçoit le même tag. Ce tag est stocké dans les bits inutilisés d'un pointeur mémoire, liant efficacement le pointeur à son bloc de mémoire correspondant.

Lorsqu'un programme accède à la mémoire via un pointeur, le matériel MTE vérifie que le tag du pointeur correspond au tag du bloc de mémoire. Si les tags ne correspondent pas, cela indique un accès mémoire illégal.

Tags de pointeur MTE

Les tags à l'intérieur d'un pointeur sont stockés dans 4 bits à l'intérieur du premier octet :

Par conséquent, cela permet jusqu'à 16 valeurs de tag différentes.

Tags de mémoire MTE

Chaque 16B de mémoire physique a un tag de mémoire correspondant.

Les tags de mémoire sont stockés dans une région RAM dédiée (non accessible pour un usage normal). Avoir des tags de 4 bits pour chaque tag de mémoire de 16B jusqu'à 3 % de la RAM.

ARM introduit les instructions suivantes pour manipuler ces tags dans la mémoire RAM dédiée :

STG [<Xn/SP>], #<simm>    Store Allocation (memory) Tag
LDG <Xt>, [<Xn/SP>]       Load Allocatoin (memory) Tag
IRG <Xd/SP>, <Xn/SP>      Insert Random [pointer] Tag
...

Vérification des modes

Sync

Le CPU vérifie les tags pendant l'exécution de l'instruction, s'il y a un décalage, il lève une exception.
C'est le plus lent et le plus sécurisé.

Async

Le CPU vérifie les tags asynchrone, et lorsqu'un décalage est trouvé, il définit un bit d'exception dans l'un des registres système. C'est plus rapide que le précédent mais il est incapable de pointer l'instruction exacte qui a causé le décalage et il ne lève pas l'exception immédiatement, donnant un peu de temps à l'attaquant pour compléter son attaque.

Mixed

???

Exemples d'implémentation et de détection

Appelé KASAN basé sur des tags matériels, KASAN basé sur MTE ou MTE dans le noyau.
Les allocateurs du noyau (comme kmalloc) vont appeler ce module qui préparera le tag à utiliser (de manière aléatoire) pour l'attacher à l'espace noyau alloué et au pointeur retourné.

Notez qu'il marquera uniquement suffisamment de granules de mémoire (16B chacune) pour la taille demandée. Donc, si la taille demandée était de 35 et qu'une plaque de 60B était donnée, il marquera les premiers 16*3 = 48B avec ce tag et le reste sera marqué avec un soi-disant tag invalide (0xE).

Le tag 0xF est le pointeur qui correspond à tout. Une mémoire avec ce pointeur permet d'utiliser n'importe quel tag pour accéder à sa mémoire (pas de décalages). Cela pourrait empêcher le MET de détecter une attaque si ce tag est utilisé dans la mémoire attaquée.

Par conséquent, il n'y a que 14 valeurs qui peuvent être utilisées pour générer des tags car 0xE et 0xF sont réservés, donnant une probabilité de réutilisation des tags de 1/17 -> environ 7%.

Si le noyau accède à la granule de tag invalide, le décalage sera détecté. S'il accède à un autre emplacement mémoire, si la mémoire a un tag différent (ou le tag invalide), le décalage sera détecté. Si l'attaquant a de la chance et que la mémoire utilise le même tag, cela ne sera pas détecté. Les chances sont d'environ 7%.

Un autre bug se produit dans la dernière granule de la mémoire allouée. Si l'application a demandé 35B, elle a reçu la granule de 32 à 48. Par conséquent, les octets de 36 à 47 utilisent le même tag mais n'ont pas été demandés. Si l'attaquant accède à ces octets supplémentaires, cela n'est pas détecté.

Lorsque kfree() est exécuté, la mémoire est retagged avec le tag de mémoire invalide, donc dans un use-after-free, lorsque la mémoire est à nouveau accédée, le décalage est détecté.

Cependant, dans un use-after-free, si le même chunk est réalloué à nouveau avec le MÊME tag qu'auparavant, un attaquant pourra utiliser cet accès et cela ne sera pas détecté (environ 7% de chance).

De plus, seuls slab et page_alloc utilisent de la mémoire taguée mais à l'avenir, cela sera également utilisé dans vmalloc, stack et globals (au moment de la vidéo, ceux-ci peuvent encore être abusés).

Lorsqu'un décalage est détecté, le noyau va panic pour prévenir toute exploitation supplémentaire et les tentatives de l'exploit (MTE n'a pas de faux positifs).

Références

• https://www.youtube.com/watch?v=UwMt0e_dC_Q