Rédacteur : Heurs
Date de création : 11/07/2006
Section : Sécurité > Failles applicatives
Imprimer cet article : en noir et blanc ou en couleurs
Le Ret Onto Ret est une faille que l'on exploite de manière assez originale. Ayant apprécié son exploitation, qui donne des possibilités redoutables, j'ai décidé de vous en faire part. Bien que l'exemple que nous donnerons soit peu crédible en terme de réalisme, il reste possible de retrouver ce genre d'exploitation dans certaines routines. Elle n'est donc pas à négliger.
Dans notre exemple c'est la fonction strcpy que nous allons recoder, fonction reconnue pour ses failles. Ca nous donne donc :
Testons donc le programme :
Exellent, nous avons un segmentation fault ! Nous allons donc débugger le prog pour avoir des infos suplémentaires :
On trouve quelque chose d'interessent ici, j'ai placé un breakpoint juste avant le ret, donc le programme aurait du stopper son execution ici avant de planter. Mais ce n'est pas ce qui c'est passé, il a planté avant.
Pour résoudre ce problème nous allons déja déterminer de combien d'espace nous disposons avant la copie.
Pour cela nous allons placer un breakpoint juste avant la copie du 1er octet,
c'est a dire 0x080483ef
Si nous faisons le calcul : ebp - edx = 0xbffffab8 - 0xbffffa70 = 72
Nous avons donc un buffer de 72 octets :) et si nous voulons savoir quand eip sera écrasé il suffit de rajouter les 4 octets de la sauvegarde d'ebp, ainsi nous savons maintenant qu'il faudra écraser 76 octets avant d'écraser eip. Testons tout de meme cela pour ne pas rester que sur la théorie :
Nous obtenons exactement le résultat souhaité. Soyons un peu plus "bourrin" et tentons d'écraser les deux valeurs suivantes, c'est a dire l'adresse de retour et le pointeur vers le 1er argument (argv[1]) :
Chose qui pourrait paraitre étonnante au premier coup d'oeil, les 8 octets que nous voullions écraser ne le sont pas complettement. La raison est simple :
Quand nous avons écrasé l'octet du pointeur 0xbffffbf5 par 0xbffffb61 cela à changé l'endroit ou nous allions chercher nos données a copier pour le remplacer par un pointeur sur un byte null. Voyant le byte null notre fonction de copie s'arrète croyant que c'est la fin de la chaine. Ainsi les octets suivants du buffer ne seront pas copiés.
Comme vous avez du le remarquer nous pouvons écraser l'adresse de retour et la remplacer par l'adresse d'un shellcode que nous aurons codé. Mais une meilleur solution existe, comme l'adresse empilée juste aprés eip est l'adresse d'argv[1], nous pourrions faire un deuxième ret dessus et cela nous ferait directement sauter sur notre shellcode. Comme shellcode j'ai pris l'éternel "Hello World !", désolé, rien d'innovant :)
L'objectif est maintenant de trouver une adresse ou sauter pour executer notre ret... Je trouve que l'adresse ou nous avons placé notre dernier breakpoint convient trés bien. Alors allons y pour cette adresse (qui de plus est statique, donc fiable) :
Notres shellcode fait 37 octet, donc 37 + 39 = 76, le compte est bon.
Comme vous avez pu le voir, l'exploitation est relativement simple, mais cette simplicité cache une grande puissance, cette faille est exploitable a l'identique si vous travaillez avec un noyeau 2.6 récent (qui randomize donc les adresses de la pile et celles de libc). Il n'est donc pas négligable de connaitre la portée de cette faille afin de vous protéger au mieux d'éventuelles erreurs de programmation.
