Discussion :

[Falquiero]

Bonsoir,

J'essaie de résoudre un problème sur root-me.

Si on regarde le code on peut dessiner la mémoire comme ça (non !?) - mémoire allant de gauche à droite :



Mais pourquoi quand je change le code et que j'initialise int check = 0xdeadbeef, le printf du pointeur de "check" me renvoie 'deadbeef' ? C'est ce qui m'embête à vrai dire.
Je croyais qu'il fallait remplir le buffer de 40 caractères random, remplir "check" avec l'adresse de "var" et remplir "var" avec '0xDeadbeef' (encore fallait-il trouver l'@ de var, mais bon ça pourrait se faire à tatons j'imagine)

Bon après coup j'ai triché pour avoir la solution mais je trouve pas d'explications à mes soucis. J'imagine bien que mes questions sont confuses mais ça reflète bien l'état dans lequel je suis à l'heure actuelle.

Merci beaucoup ...

[pascaldm]

Sans le code source il est difficile d'apporter une réponse à la question, je n'ai pas de compte sur root-me.org et je ne compte pas en créer un.

S'agit-il d'écraser l'adresse de retour dans la bile (au-dela du saved EBP) ou bien de contrôler la valeur de l'une des variables 'check' ou 'var' dans la pile ?
Apparemment l'agencement de la stack est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
buf     [ 40]
check   [  4]
var     [  4]

Etant donné que les variables sont sur 4 octets, je fais l'hypothèse qu'il s'agit d'un exploit en environnement 32-bit (x86).

En remplissant le buffer au-delà de 40 octets, les variables stockées sur la pile après 'buf' vont être écrasées. Ainsi, si l'ont souhaite écraser la valeur de 'check' (le nom de la variable me fait penser que c'est elle qui est visée) avec une valeur contrôlée (ex: 0xdeadbeef), alors il faut provoquer un dépassement du tampon 'buf' dans la pile pour écraser les octets de la variable locale 'check' immédiatement située après.

Attention, la plateforme matérielle x86 est en little endian, il faut donc inverser l'ordre des octets. Voici un exemple de remplissage du buffer pour écraser 'check', la valeur binaire 0xdeadbeef en little endian (donc ordre d'octets inversé) est concaténée aux 40 octets de padding pour remplir le buffer ("A" vaut 0x41) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
$ perl -e 'print "A" x 40 . "\xef\xbe\xad\xde"' | hexdump -v -e '/4 "%08X\n"'
41414141
41414141
41414141
41414141
41414141
41414141
41414141
41414141
41414141
41414141
DEADBEEF

Ici la variable 'check' (ligne 12) contient la valeur binaire 0xdeadbeef. C'est notre adresse mémoire ou bien la valeur que l'on souhaite forcer dans la variable 'check'. Pour smasher 'var' il faut ajouter 4 octets de padding. Pour écraser l'adresse de retour, il faut tâtonner avec le nombre d'octets en alignant sur un multiple de 4 octets (tout dépend des variables locales et des options de builds qui peuvent ajouter des éléments sur la pile). Le recours au débogueur gdb permet de visualiser le contenu de la pile. La valeur de l'adresse de retour sera affichée lorsque celle-ci est écrasée avec une adresse invalide permettant d'identifier le padding nécessaire pour écraser la pile. Sinon, en mode pas à pas, il suffit d'afficher la valeur du pointeur d'instruction EIP juste avant de retourner à la fonction appelante.

Attention, avec GDB, le contexte change par rapport à une exécution non tracée et cela a un impact sur la pile. D'autre part, si ASLR est activé, alors les adresses de chargement changeront à chaque invocation du binaire (cela peut être un problème selon le besoin de l'exploit. Si les mitigations de protection de la pile sont activées (canari, pile non exécutable, etc.) alors l'exploit sera avorté. Il faut utiliser les options de compilation de GCC -fno-stack-protector et --execstack et désactiver ASLR dans /proc/sys/kernel/randomize_va_space.

Bonne continuation

[BufferBob]

salut,

Sans le code source il est difficile d'apporter une réponse

en substance c'est ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
int main() {  /* gcc -m32 -o ch13 ch13.c -fno-stack-protector */
  int check = 0x04030201;
  char buf[40];
  fgets(buf,45,stdin);
  if (check == 0xdeadbeef) system("/bin/dash");

Mais pourquoi quand je change le code et que j'initialise int check = 0xdeadbeef, le printf du pointeur de "check" me renvoie 'deadbeef' ?

le "printf du pointeur" ?? lapin compris.
faut comprendre un peu le langage C pour se lancer dans ces challenges, et comme dit plus haut on est pas devins non plus, si tu montres précisément ce qui se passe (en copiant/collant, en faisant une capture d'écran, ou en prenant des exemples etc.) on comprendra forcément mieux

en l'occurrence c'est par la variable buf qu'on déborde via la fonction fgets() qui lit sur l'entrée standard, ça veut dire que pour exploiter la bête on va pouvoir faire un truc du genre payloadcracra | ./ch13.

donc simple, buf est déclaré comme pouvant contenir 40 octets, fgets() en lit 45, les 5octets qui dépassent écrasent les variables déclarées avant dans le code, ici check qui tient sur 4 octets

une subtilité risque d'intervenir néanmoins lors de l'exploitation, il conviendra donc de faire un truc genre (cracra; cat) | ./ch13, le cat servant ici à maintenir les descripteurs ouverts et éviter que le shell ne se ferme

j'ai triché pour avoir la solution

aucun intérêt.