Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/binary-exploitation/common-binary-protections-and-bypasses/stack-canaries
History
Translator e3fb225ca0 Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/aw2
2024-05-05 22:09:31 +00:00
..
bf-forked-stack-canaries.md Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/aw2 2024-05-05 22:09:31 +00:00
print-stack-canary.md Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/aw2 2024-04-07 04:10:47 +00:00
README.md Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/aw2 2024-04-07 22:24:06 +00:00

README.md

Stack Canaries

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres façons de soutenir HackTricks :

StackGuard et StackShield

StackGuard insère une valeur spéciale appelée canary avant le 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 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 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 débordement de pile (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 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(), on é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, à 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.

{% hint style="danger" %} 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. {% endhint %}

Contournements

Fuite du canary puis écrasement de celui-ci (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 par la force brute un octet à la fois :

{% content-ref url="bf-forked-stack-canaries.md" %} bf-forked-stack-canaries.md {% endcontent-ref %}

  • 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 :

{% content-ref url="print-stack-canary.md" %} print-stack-canary.md {% endcontent-ref %}

  • É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 :

{% content-ref url="../../stack-overflow/pointer-redirecting.md" %} pointer-redirecting.md {% endcontent-ref %}

  • Modifier à la fois le canary maître et le canary du thread

Un débordement de tampon dans une fonction threadée protégée par un canary peut être utilisé pour modifier le canary maître du thread. Par conséquent, la mitigation est inutile car la vérification est effectuée avec deux canaries identiques (bien que modifiés).

De plus, un débordement de tampon dans une fonction threadée protégée par un canary pourrait être utilisé pour modifier le canary maître stocké dans le TLS. Cela est possible car il pourrait être possible d'atteindre la position mémoire où le TLS est stocké (et donc le canary) via un débordement de tampon dans la pile d'un thread.
Par conséquent, la mitigation est inutile car la vérification est effectuée avec deux canaries identiques (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

Consultez é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 indiqué dans le writeup précédent.

  • Modifier l'entrée GOT de __stack_chk_fail

Si le binaire a une RELRO partielle, 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

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres façons de soutenir HackTricks: