Ou plus spécifiquement, ne déréférencez en aucun cas un pointeur après un free ! Facile ? L'utilisation de pointeurs après leur libération (Use After Free) fait toujours aujourd'hui partie du top 5 des vulnérabilités listées par MITRE (https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html). Avec des conséquences qui peuvent aller du crash de l'application à l'exploitation de la vulnérabilité induite par un attaquant, et, au final, avoir un impact sur votre réputation ou vous coûter beaucoup d'argent ! Dans cet article, nous verrons quelques cas dont il faut se méfier, comment les Use After Free constituent des vulnérabilités qui peuvent être exploitées par des attaquants, et surtout les mesures à mettre en place pour les éviter autant que possible.
1. Un Use After Free ? Moi ? Jamais !
Dans la pratique, même en faisant vraiment attention (nous en reparlerons ultérieurement), on se laisse parfois surprendre. Il est impossible de lister ici tous les cas de figure qui sont susceptibles de se produire. Nous allons donc nous concentrer sur trois cas de figure : le retour d'un pointeur vers la pile ; la libération dans une fonction appelée ; et l'utilisation des ressources internes d'un objet.
1.1 Retour d'un pointeur vers la pile
Un pointeur ne pointe pas nécessairement vers de la mémoire allouée dynamiquement. Il peut aussi pointer vers la pile, qui n’est pas explicitement désallouée avec un free, mais peut être « réaffectée » lors de l’exécution d’une nouvelle fonction. D’où le danger lorsqu’un pointeur vers la pile survit au dépilage de la fonction. Le cas de figure le plus simple est facilement évitable :
Le compilateur retourne un...
- Accédez à tous les contenus de Connect en illimité
- Découvrez des listes de lecture et des contenus Premium
- Consultez les nouveaux articles en avant-première
