Citation:
Oui, c'est clairement la base d'une attaque par chaîne de format.
Avec les sources et en exécutant une version modifiée du programme sur un fichier qu'on connait, il doit être possible de connaître l'adresse du buffer où est stockée la ligne de passwd (sans ASLR, c'est garanti s'il se trouve sur la pile; s'il est sûr le tas, c'est moins sûr mais il y a une chance que ce soit constant quand même).
Il y a un mec sur le root-me qui m'a suggérer une méthode un peu pareil. Mais comme il parle en anglais. Je ne sais pas si j'ai tout pigé :(
Citation:
You can try copying the application (so there is a non-setuid version) and change the text file it tries to open to a file it DOES have access to. That way you can see the same memory layout, including debugging in gdb without a crash. Once you have a working ’exploit’ that allows you to see into the read dummy file, apply this solution to the original binary.
Citation:
you have to simulate the application as closely as possible. The easiest way to do this is to copy the application exactly, then patch the program (you can do this in a hex editor) to change the string that points to the file name so that it points to a file you can actually read. Now debug this program using GDB and try to figure out how to get the application to print out the contents of the file using only the input argv.
Qu'en pensez-vous? C'est la même idée ou je me trompe?
