Bon, voila
 
J'ai un cours d'unif qui est un séminaire d'intrusion, le but c'est d'exploiter un bug d'un serveur pour gagner des privilèges. ( Au cas ou vous ne me croiriez pas http://www.info.ucl.ac.be/notes_de_cours/Ingi2591/ ).
 
Je doit exploiter un double free. J'ai plus ou moins compris comment ca marche ( quoique pas de bol apres la glib 2.2.5, il ont changé l'implementation de malloc ... ). Mais bon j'arrive a ecrire 4 bytes de mon choix a l'addresse de mon choix. A partir de la comment je peut executer mon shell code, ca je comprend pas ???

heu...  
 
 
les exploits, heu.. comment dire...  
 
 
 
je les laisse ?

ca a l'air interessant

minusplus> Ouai je sais c douteux. C pour ca que j'ai mis le lien vers la page de mon cours pour prouver que c'était bien pour les cours. Et je ne compte pas donner ici le moyen detaillé pour ecraser les 4 bytes en question.
 
En passant, j'ai trouver comment faire. Il suffit que j'écrase l'adresse de retour sur la pile ( se trouve tjs +- 0xbffff??? ) avec l'addresse de bon buffer dans la heap. Quand le prog appele return, il ne retourne pas d'ou il vient mais saute vers mon shellcode.
 
Mais mon shell code se trouve dans la heap ( donc dans le segment .data ) et ne devrait pas être executable ... Pourtant, ca passe. Je suppose que il ne verifie pas pour des raison de performance ?
 

C'est parce que sur i386 le processeur ne sépare pas correctement les zones mémoire qui sont exécutables et celles qui ne le sont pas. Sur d'autres architectures, ça aurait peu de chances de marcher, il faudrait d'abord écraser une zone de code.

Sur les autres architectures, les pages peuvent souvent etre exécutables _ou_ accessibles en écriture, pas les deux.
Si on a moyen d'écrire suffisemment dans la pile, on peut toujours exécuter les appels système que l'on veut en placant des arguments juste avant l'adresse de retour, et en mettant l'adresse d'une fonction de la libc comme adresse de retour. C'est ce que l'on fait habituellement sous Tru64.
 
Quand se contenter d'un exec*() ne suffit pas (ex: chroot), il faut s'y prendre à plusieurs fois. Avec un peu de chances, si on a un descripteur sur un fichier mappé, on peut utiliser mprotect() dans un premier temps pour faire sauter la protection, puis le remplir dans un second temps, puis y sauter. Ca marche bien sur OpenBSD par exemple. Il se peut que ce soit aussi jouable avec des segments de mémoire partagée (mais là, je ne vois pas trop comment s'y attacher, conserver l'attachement, puis s'en servir. Peut-etre sur des softs multithreadés uniquement) .
 
Mais le fait que le heap soit forcément exécutable (si lisible) sur x86 est vraiment pourri... Meme quand tu as une pile non exécutable, tu peux souvent te demerder pour recopier ton shellcode dans le tas.
 
Alors que sur les autres architectures, on peut meme placer la GOT en lecture seule (->exploitation des pointeurs en variables globales beaucoup plus chiante).

C quoi ce GOT, je comprend pas bien.
 
Parce que dans l'exploit original ( que je ne parvenait pas a faire marcher ), il mettait l'addresse du shell code dans le "GOT de strcpy" d'après ce que j'ai compris. Parce que le prochain appel qu'il fait apres que j'ai ecrasé tel ou tel addresse, c un strcpy.
 
Moi je ne fait pas comme ca, j'ecrase l'addresse de retour sur la pile. Mais je sais pas ou elle se trouve exactement donc je doit chercher. Y a un moyen plus fiable ?

ne devrait-ce pas aller dans prog... je m'interroge...

ou chez les dingues  

Oaui mais les gens ici on l'air plus interessé ( ou competent ... ) que dans prog. Dans les OS libre, on a l'habitude de trifouiller dans le code, etc ...

Dans ton code, les zones ou sont stockées les données (!= code) peuvent etre :
 
- Indépendantes de l'endroit où se trouve le code en mémoire (PIC). C'est par exemple tout ce qui se trouve sur la pile, et, dans certains cas, la zone .rodata
 
- Référencées par une adresse absolue. C'est typiquement le cas pour les variables statiques/globales ainsi que les adresses des fonctions contenues dans les bibliothèques dynamiques.
 
On peut faire du code 100% indépendant de l'adresse où il se trouve (option -fpic de GCC), et éviter ainsi de calculer toutes les relocations. C'est le "prelink" qui permet par exemple d'accélérer le démarrage de KDE. Par contre, dès l'instant où l'on évite la relocation, on risque de faire face à de gros problèmes dès que l'on met à jour l'une des bibliothèques utilisées par exemple (-> les offsets ne sont plus bons) .
 
Quand tu compiles normalement un programme, le linker (par le linker dynamique -ldd-, mais celui utilisé à la fin des compilations -ld-) va générer une table d'offsets pour chaque symbole global. C'est la GOT. Le format ELF a une section pour cette table. Ensuite, quand tu lances le programme, l'adresse de base est ajoutée à ces offsets chaque fois qu'ils sont référencés : c'est l'étape de relocation (qui peut etre longue si la table est vraiment grosse) . Une fois que toutes les adresses sont calculées, le programme peut démarrer.

Exemple simple d'exploitation d'un pointeur global :
 
http://online.securityfocus.com/ar [...] 02-08-02/0
 

Bonne doc en francais sur les trucs classiques :
 
http://www.cgsecurity.org/Articles [...] ections-1/

 
C'est un très mauvais exemple, car strcpy() n'est pas forcément appellée (du moins en tant que fonction, dont l'adresse est obtenue via la GOT) suivant les optimisations demandées à GCC.
 
Pour ce genre de fonctions, gcc dispose de "stubs" et remplace les appels par du code en ligne.

 
Le shellcode utilisé dans leurs exemples est nul par contre.
 
pushl c'est bien plus simple et pratique pour foutre des constantes sur la pile que de referencer une chaine a la fin et de galerer avec jmp/call pour en chopper l'adresse.
 
Exemple :
 

Cool, merci pour toutes ces précisions. Je lirait tout ca demain, il se fait tard.
 
En fait, la vu que j'ai un shell sur la machine ( c tricher un peu mais bon ), je peut facilement trouver ou ecrire, suffit que j'affiche la table de relocation dynamique avec objdump et il ne me reste plus qu'a trouver l'addresse ou est mon shellcode ( il se trouve dans une zone allouée par malloc ). En l'occurence, je le fait enorme ( genre 16k ) avec plein de nop au debut comme ca, je peut y allez a grand pas pour trouver l'addresse.
 
De plus comme a la demo finale, je n'aurait pas l'addresse exacte du GOT de strcpy ( ou de n'importe quel func qui sera appele un jour ou l'autre ... ), je doit aussi le chercher. Et si je trouve pas dans les environ de 080?????, je cherche alors dans les environ de 0xbfffff00 ( pour choper la pile ). Et ca devrait passer.
 
En fait que je prenne strcpy ou n'importe quel autre, y a une chance non nulle pour que je l'appelle ...
 
PS: Oaui concernant la relocation, je me rappele avoir vu ca dans un de mes cours précédent et je me rappellait plus de la denomination GOT ( et GOT sur google, ca donne pas vraiment ca ... ).