GCC et une Stack ordonnée

Bonjour,

Je suis le livre "Hacking: The Art of Exploitation", 2nd Edition by Jon Erickson.

Où il nous présente 2 variantes d’un même code C:

• http://ep0ch.net/stash/buffer_overflows.html#auth_overflowc
• http://ep0ch.net/stash/buffer_overflows.html#auth_overflow2c

D’après lui, le premier est vulnérable, mais pas le seconde, car les variables locales ne sont pas ordonnés de la même manière dans la stack.

Sur l’iso livecd fournis avec le livre, cela semble collé, mais pas sur ma machine. Et je ne suis pas le seul apparemment:

• https://stackoverflow.com/questions/38891137/is-gcc-reordering-local-variables-at-compilation-time
• https://stackoverflow.com/questions/21178656/declared-variables-stack#answer-21215205

Ce qui me laisse très perplexe.

Questions: Je ne comprends pas pourquoi ma stack dans le programme du code auth_overflow2.c n’est pas ordonné de la même manière que lui? Et comment faire pour avoir le même comportement?

ISO du livre pour tester:

wget -c  https://resources.oreilly.com/examples/9781593271442/raw/master/hacking-live-1.0.iso
sudo gpasswd -a abracadabra kvm
qemu-img create -f raw qemu.raw 2G
qemu-system-x86_64 -k fr -m 4G -drive file=qemu.raw,format=raw -boot d -cdrom hacking-live-1.0.iso -net nic -net user -no-acpi -cpu host -machine type=pc,accel=kvm

CONFIG DE GCC ET KERNEL DE L’ISO:

• Linux Ubuntu 2.6.20–15-generic i686 https://framadrop.org/r/8OHoANoajc#zhxRRBQ2Slpvc4nSuUhw628Uukb/vGDik7Z4R/awvoQ=
• gcc (GCC) 3.3.6 (Ubuntu 1:3.3.6–15ubuntu1) https://framadrop.org/r/rq5EcuQUk5#9BqDFlclmgLAm/y0y897wIULYXJfdq54fnA8t5h0MPg=

CONFIG DE GCC ET KERNEL DU PC:

• Linux Archlinux 5.0.4-arch1–1-ARCH x86_64 https://framadrop.org/r/XVTSjQBmmE#3BnYhXReROPVka9Gl2LEhU2NdHgCzl+Li64FB0M5YNw=
• gcc (GCC) 8.2.1 20181127
• alias gcc=’gcc -z execstack -fno-stack-protector' https://framadrop.org/r/Sl8uBJvN-V#H7/5pEJ67wGHA1KrZKsM6fV3khsrb7hWRFJ3iXNGQBU=

Édit:

Je me suis fait un conteneur avec l’iso. Que j’ai chrooté. J’obtiens aussi le comportement du livre, donc je suppose que la configuration kernel n’entre pas en jeu. Mais je ne sais toujours pas comment configurer mon GCC actuel pour avoir le même comportement du GCC de l’ISO.

Comme dit sur SO dans les commentaires, l’auteur part d’un présupposé faux : que l’ordre dans la stack dépend de l’ordre dans le code. Mais la norme (a priori, je n’ai pas vérifié) ne précise pas cela, donc les compilateurs font comme ils veulent.

Il y a un peu le mythe du "en C, le code est exactement identique à l’assembleur généré", mais c’est pas toujours vrai. Et souvent pas vrai sur le long termes, sur différents compilateurs, différents systèmes, etc.

C’est un Undefined Behavior (UB, comportement indéfini), c’est a dire qu’on ne doit pas attendre un comportement standardisé. (Il peut etre reproductible, mais aucune garantie)

Salut,

Je confirme pour la norme, rien n’est précisé là-dessus (il n’est même pas question de la pile, d’ailleurs). Rien ne dit d’ailleurs que les variables ne seront pas stockées dans des registres (bon, c’est moins probable pour le tableau, quoi qu’à voir vu la taille de certains registres, mais bref).

Je confirme ! C’est de moins en moins le cas. Plus les compilateurs sont optimisés et moins c’est le cas. Du coup, à l’époque où l’auteur à écrit cela, c’était certainement la norme (l’expression, ça n’a jamais été dans le standard du C) désormais, les compilateurs optimisent et c’est tant mieux !

Cependant, tu peux essayer d’initialiser le tableau à "". Ce n’est qu’une supposition, mais je pense que gcc déplace les définitions mais pas les initialisations. Tu peux également essayer de compiler avec clang ou tcc pour voir le comportement d’autres compilateurs.

Souvent, les « exploits » se basent uniquement sur des UB. Ce qui complique leur reproduction.

Pour compléter ce qui est dit, les deux environnement testés sont vraiment très différents, il y a un i686 et un x86_64, qui ont des ABI très différentes (normes pour définir comment sont appelées les fonctions, comment les arguments sont transmis, comment la valeur de retour est récupérée, et quels registres peuvent être modifiés par qui). Beaucoup de variables ne se retrouvent jamais en RAM sur un système x86_64 (c’était déjà le cas avec i686, mais x86_64 a plus de registres).

De fait, l’Art de l’Exploitation ne consiste pas à chercher à retrouver le même comportement partout, mais à exploiter celui qu’on observe là où on souhaite intervenir.