Stack Canaries

Reading time: 6 minutes

StackGuard et StackShield

StackGuard insère une valeur spéciale connue sous le nom de canary avant le EIP (Extended Instruction Pointer), spécifiquement 0x000aff0d (représentant null, newline, EOF, carriage return) pour se protéger contre les débordements de tampon. Cependant, des fonctions comme recv(), memcpy(), read(), et bcopy() restent vulnérables, et cela ne protège pas le EBP (Base Pointer).

StackShield adopte une approche plus sophistiquée que StackGuard en maintenant une Global Return Stack, qui stocke toutes les adresses de retour (EIPs). Cette configuration garantit qu'un débordement ne cause pas de dommages, car elle permet une comparaison entre les adresses de retour stockées et réelles pour détecter les occurrences de débordement. De plus, StackShield peut vérifier l'adresse de retour par rapport à une valeur limite pour détecter si le EIP pointe en dehors de l'espace de données attendu. Cependant, cette protection peut être contournée par des techniques comme Return-to-libc, ROP (Return-Oriented Programming), ou ret2ret, indiquant que StackShield ne protège également pas les variables locales.

Stack Smash Protector (ProPolice) -fstack-protector:

Ce mécanisme place un canary avant le EBP, et réorganise les variables locales pour positionner les tampons à des adresses mémoire plus élevées, les empêchant d'écraser d'autres variables. Il copie également en toute sécurité les arguments passés sur la pile au-dessus des variables locales et utilise ces copies comme arguments. Cependant, il ne protège pas les tableaux de moins de 8 éléments ou les tampons dans une structure utilisateur.

Le canary est un nombre aléatoire dérivé de /dev/urandom ou d'une valeur par défaut de 0xff0a0000. Il est stocké dans TLS (Thread Local Storage), permettant aux espaces mémoire partagés entre les threads d'avoir des variables globales ou statiques spécifiques au thread. Ces variables sont initialement copiées à partir du processus parent, et les processus enfants peuvent modifier leurs données sans affecter le parent ou les frères et sœurs. Néanmoins, si un fork() est utilisé sans créer un nouveau canary, tous les processus (parent et enfants) partagent le même canary, le rendant vulnérable. Sur l'architecture i386, le canary est stocké à gs:0x14, et sur x86_64, à fs:0x28.

Cette protection locale identifie les fonctions avec des tampons vulnérables aux attaques et injecte du code au début de ces fonctions pour placer le canary, et à la fin pour vérifier son intégrité.

Lorsqu'un serveur web utilise fork(), il permet une attaque par force brute pour deviner le canary octet par octet. Cependant, l'utilisation de execve() après fork() écrase l'espace mémoire, annulant l'attaque. vfork() permet au processus enfant d'exécuter sans duplication jusqu'à ce qu'il tente d'écrire, moment auquel un duplicata est créé, offrant une approche différente pour la création de processus et la gestion de la mémoire.

Longueurs

Dans les binaires x64, le cookie canary est un 0x8 byte qword. Les sept premiers octets sont aléatoires et le dernier octet est un octet nul.

Dans les binaires x86, le cookie canary est un 0x4 byte dword. Les trois premiers octets sont aléatoires et le dernier octet est un octet nul.

Contournements

Fuite du canary puis écriture de sa propre valeur (par exemple, débordement de tampon).

• Si le canary est forké dans des processus enfants, il pourrait être possible de brute-forcer un octet à la fois :

BF Forked & Threaded Stack Canaries

• S'il y a une fuite intéressante ou une vulnérabilité de lecture arbitraire dans le binaire, il pourrait être possible de le fuir :

Print Stack Canary

• Écrasement des pointeurs stockés dans la pile

La pile vulnérable à un débordement de pile pourrait contenir des adresses de chaînes ou de fonctions qui peuvent être écrasées afin d'exploiter la vulnérabilité sans avoir besoin d'atteindre le canary de la pile. Vérifiez :

Pointer Redirecting

• Modification du canary maître et du canary de thread

Un débordement de tampon dans une fonction threadée protégée par canary peut être utilisé pour modifier le canary maître du thread. En conséquence, l'atténuation est inutile car la vérification est effectuée avec deux canaries qui sont les mêmes (bien que modifiés).

De plus, un débordement de tampon dans une fonction threadée protégée par canary pourrait être utilisé pour modifier le canary maître stocké dans le TLS. Cela est dû au fait qu'il pourrait être possible d'atteindre la position mémoire où le TLS est stocké (et donc, le canary) via un bof dans la pile d'un thread.
En conséquence, l'atténuation est inutile car la vérification est effectuée avec deux canaries qui sont les mêmes (bien que modifiés).
Cette attaque est réalisée dans le writeup : http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads

Vérifiez également la présentation de https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015 qui mentionne que généralement le TLS est stocké par mmap et lorsqu'une pile de thread est créée, elle est également générée par mmap selon cela, ce qui pourrait permettre le débordement comme montré dans le writeup précédent.

• Modifier l'entrée GOT de __stack_chk_fail

Si le binaire a un Partial RELRO, alors vous pouvez utiliser une écriture arbitraire pour modifier l'entrée GOT de __stack_chk_fail pour être une fonction factice qui ne bloque pas le programme si le canary est modifié.

Cette attaque est réalisée dans le writeup : https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/

Références

• https://guyinatuxedo.github.io/7.1-mitigation_canary/index.html
• http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads
• https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/