Stack Canaries
StackGuard et StackShield
StackGuard insère une valeur spéciale appelée canary avant l'EIP (Extended Instruction Pointer), spécifiquement 0x000aff0d (représentant null, saut de ligne, EOF, retour chariot) pour se protéger contre les débordements de tampon. Cependant, des fonctions comme recv(), memcpy(), read() et bcopy() restent vulnérables, et il ne protège pas l'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 (EIP). Cette configuration garantit qu'un débordement ne cause aucun dommage, 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 l'EIP pointe en dehors de l'espace de données attendu. Cependant, cette protection peut être contournée par des techniques telles que Return-to-libc, ROP (Return-Oriented Programming) ou ret2ret, indiquant que StackShield ne protège pas non plus les variables locales.
Protecteur de pile Smash (ProPolice) -fstack-protector:
-fstack-protector:Ce mécanisme place un canary avant l'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 de manière sécurisée 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 avec moins de 8 éléments ou les tampons à l'intérieur d'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 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 byte du canary octet par octet. Cependant, en utilisant execve() après fork(), l'espace mémoire est écrasé, annulant l'attaque. vfork() permet au processus enfant d'exécuter sans duplication jusqu'à ce qu'il tente d'écrire, à ce moment-là une duplication est créée, offrant une approche différente à la création de processus et à la gestion de la mémoire.
Longueurs
Dans les binaires x64, le cookie canary est un qword de 0x8 octets. Les sept premiers octets sont aléatoires et le dernier octet est un octet nul.
Dans les binaires x86, le cookie canary est un dword de 0x4 octets. Les trois premiers octets sont aléatoires et le dernier octet est un octet nul.
Le byte le moins significatif des deux canaries est un octet nul car il sera le premier dans la pile venant des adresses inférieures et donc les fonctions qui lisent des chaînes s'arrêteront avant de le lire.
Contournements
Fuite du canary puis écrasement (par exemple, débordement de tampon) avec sa propre valeur.
Si le canary est forké dans les processus enfants, il pourrait être possible de le forcer un octet à la fois :
S'il y a une fuite intéressante ou une vulnérabilité de lecture arbitraire dans le binaire, il pourrait être possible de laisser fuiter :
Écrasement des pointeurs stockés dans la pile
La pile vulnérable à un débordement de pile pourrait contenir des adresses vers des chaînes ou des fonctions qui peuvent être écrasées pour exploiter la vulnérabilité sans avoir besoin d'atteindre le canary de la pile. Vérifiez :
pagePointer RedirectingRéférences
Dernière mise à jour