Écrire une attaque de retour à la bibliothèque, mais la bibliothèque est chargée à 0x00 en mémoire

J’écris une attaque de retour à la libc pour la classe de sécurité de mon système. Tout d’abord, le code vulnérable:

//vuln.c #include  #include  int loadconfig(void){ char buf[1024]; sprintf(buf, "%s/.config", getenv("HOME")); return 0; } int main(int argc, char **argv){ loadconfig(); return 0; } 

Je veux utiliser un retour à l’attaque de la libc. Comstackr et déboguer le programme:

 $ gcc -g -fno-stack-protector -o vuln vuln.c $ gdb vuln (gdb) break loadconfig (gdb) run Reached breakpoint blah blah blah. (gdb) p $ebp $1 = (void *) 0xbfffefb0 (gdb) p system $2 = {} 0x0016db20  (gdb) p exit $3 = {} 0x001639e0  (gdb) x/2000s $esp ... 0xbffff5af: "SHELL=/bin/bash" 

Pour exécuter l’attaque, je veux déborder du tampon dans l’adresse de retour de loadconfig (alias $esp+4 ), en le remplaçant par l’adresse de retour pour system , puis l’adresse de retour pour la exit (car le system s’attend à une adresse de retour réelle), puis le nom de la commande (l’adresse de SHELL=/bin/bash plus 6, pour couper le SHELL= partie). Cela devrait être possible en construisant une variable d’environnement $HOME de 1024 caractères de merde, puis l’adresse little-endian de system , exit et /bin/bash .

Cependant, avec tous les ordinateurs que j’ai essayés, le system est chargé à une adresse commençant par 0x00, ce qui met fin à la chaîne nulle que sprintf lit et arrête l’attaque à mort. Existe-t-il un moyen de forcer libc à se charger ailleurs dans la mémoire, ou est-ce que j’interprète mal l’attaque?

Pour référence, j’utilise une machine virtuelle Ubuntu Server 11.10 dans VirtualBox (hôte Windows), avec la version 4.6.1 de gcc et la version 7.3-2011.08 de gdb . edit: ASLR est désactivé et j’ai compilé avec -fno-stack-protector pour supprimer le canari. Puisque je n’exécute rien de la stack, je n’ai pas besoin de l’ execstack .

Le fait de mapper une fonction importante de la libc avec des adresses contenant un octet NULL est appelé armure ASCII. Cette protection fait partie de RedHat Exec-shield qui est actuellement activé sur le lien de dissortingbutions ubuntu récent . Pour la désactiver, vous devez exécuter le compte root:

sysctl -w kernel.exec-shield = 0

comme expliqué ici

En passant, vous pouvez trouver des informations intéressantes sur la manière de contourner le blindage ASCII ici sur exploit-db

Je suis à peu près certain que cela est impossible le 11.10, du moins de la manière que vous mentionnez. Regarde:

https://wiki.ubuntu.com/Security/Features

En détail, et en sélectionnant quelques problèmes avec vos idées:

(1) à cause des valeurs canaries et pour d’autres raisons, un débordement de tampon dans esp + 4 déclenchera une exception d’erreur de segmentation

(2) vous voulez probablement extraire l’adresse de la variable environnementale, qui aurait traditionnellement été à ESP (main) + un certain nombre d’octets. Cependant, comme même les adresses de mémoire logiques de nos jours sont brouillées / randomisées après la compilation, vous obtiendrez une adresse de mémoire différente pour votre variable $ HOME pour chaque exécution, probablement quelque part de l’autre côté de la stack principale.

(3) à ma connaissance, il existe d’autres moyens de contrecarrer les attaques des bibliothèques. Je les connais moins bien. Cela devrait être la raison pour laquelle vous voyez x00 pour l’adresse

Il est difficile de pirater ces temps-ci sur un système Ubunti. Si vous avez juste besoin de faire cela pour une classe qui n’insiste pas sur les dissortingbutions actuelles, installez plutôt la première dissortingbution Ubunti dans virtualbox. Comme par magie, tout ce que vous essayez fonctionnera. Vous ne faites plus référence à une «attaque par débordement standard» – même si vous contournez intelligemment les valeurs canaries, etc., le réglage du bit nx rend cela impossible. Et de même, bien que je sois moins parfaitement sûr de la façon dont le retour des attaques par la libc est traité, ne vous fiez pas à croire que cela sera possible avec une dissortingbution courante. Bonne chance!