Discussion :

[momoski]

Bref moi je taperais directement chemin/binary5 toto et regarderait le résultat.

Ici que représente toto? le nom utilisateur propriétaire du code?

Afin de pouvoir profiter des sous commandes de gdb notamment "print" qui permet d'afficher le contenu d'une variable (dans mon cas "print buffer") en faisant breakpoint sur la ligne 11, je devrais lancer la commande de la sorte:

$ gdb /chemin/binary5 toto ?

car j'ai tenté cela et j'ai une erreur :

/chemin/binary5: Aucun fichier ou dossier de ce type.
/chemin/binary5/toto: Aucun fichier ou dossier de ce type

PS: Leur serveur de ce challenge tourne sur ubuntu Linaro 7.4
toto = nom utilisateur propriétaire du code

PS: je me suis inscrit et je vais aller y m'amuser...

Super vas y il y a plein de challenge qui mérite d'être traité!

[Sve@r]

Ici que représente toto? le nom utilisateur propriétaire du code?

Non, il s'agit d'un argument bidon juste pour qu'il y en ait un. A un moment, le code affiche argv[1]. Il faut donc qu'argv[1] existe pour pouvoir être affiché (quoique en fait, s'il n'y a pas d'argument n° 1 alors argv[1] vaut NULL et NULL est affichable par printf() donc on peut oublier)

car j'ai tenté cela et j'ai une erreur :

/chemin/binary5: Aucun fichier ou dossier de ce type.

Bien évidemment
Dans ton post précédent tu as dit que tu avais trouvé l'exécutable binary5 mais tu n'as pas dit où il était. J'ai donc écrit "/chemin" pour symboliser cet emplacement. Bien entendu, de ton coté tu dois adapter mon exemple et le remplacer par le vrai chemin contenant binary5.

Exemple: si binary5 se trouve dans /truc/chose/machin alors tu dois taper /truc/chose/machin/binary5... (attention, il s'agit d'un exemple !!!)

[momoski]

Bien évidemment
Dans ton post précédent tu as dit que tu avais trouvé l'exécutable binary5 mais tu n'as pas dit où il était. J'ai donc écrit "/chemin" pour symboliser cet emplacement. Bien entendu, de ton coté tu dois adapter mon exemple et le remplacer par le vrai chemin contenant binary5.

Exemple: si binary5 se trouve dans /truc/chose/machin alors tu dois taper /truc/chose/machin/binary5... (attention, il s'agit d'un exemple !!!)

Evidemment que j'ai adapté "chemin" au chemin d'accès au fichier. Seulement ça met l'erreur spécifié dans mon précédent post.

Et même comme je suis dans ce répertoire, j'ai tapé directement :

$gdb binary5 toto

Il charge bien le code mais me met cette erreur:

/challenge/binary/binary5/toto: Aucun fichier ou dossier de ce type.

Et le code chargé est toujours sous mon uid et non sous celui du propriétaire.

Ce que je veux savoir: Y a t-il une syntaxe pour lancer la commande "gdb" pour qu'elle prenne en compte l'uid de propriétaire du code et non le mien?

Je cherche sur google mais j'ai rien trouvé jusque là!

[Sve@r]

Evidemment que j'ai adapté "chemin" au chemin d'accès au fichier. Seulement ça met l'erreur spécifié dans mon précédent post.

Moi je me suis connecté. Etant donné que l'exécutable binary5 se trouve directement dans le home de connexion j'ai tapé ./binary5 et le programme s'est parfaitement exécuté.
Toutefois, et j'ai compris le soucis, c'est que le code ouvre le fichier, le charge dans une variable mais n'affiche pas la variable. Et donc le fichier reste inconnu...

Et même comme je suis dans ce répertoire, j'ai tapé directement :

$gdb binary5 toto

Pourquoi veux-tu absolument passer par gdb ???

Ce que je veux savoir: Y a t-il une syntaxe pour lancer la commande "gdb" pour qu'elle prenne en compte l'uid de propriétaire du code et non le mien?

Impossible. gdb étant un exécutable (/usr/bin/gdb pour être exact), cet exécutable doit posséder un setuid si tu veux qu'il s'exécute avec d'autres droits que les tiens (ce qui n'est évidemment pas le cas). Ou bien passer par un autre exécutable prévu pour ça qui, lui, possède ce setuid (tel que sudo présent sur certaines distribs mais hélas pas ici). Ce qui nous ramène au point de départ: trouver un tel exécutable.

Mais je sens que ce n'est pas la bonne piste. Etant donné que binary5 s'exécute parfaitement, et avec les bons droits, il faut creuser la dedans. Surtout avec cet argv[1] qui arrive comme un cheveu sur la soupe. Pour moi, il faut passer par là. Essayer d'utiliser cette variable pour provoquer un dépassement mémoire afin qu'elle aille taper dans la variable "buffer"...

Autre possibilité: étant donné que tout se passe dans /challenge/binary/binary5 et que tu es propriétaire de ce répertoire, tu changes ses droits en 755 puis tu tapes rm -f .passwd binary5*. Au-moins il n'y aura plus de challenge à trouver...

[edit]J'ai trouvé une piste: la ligne printf() est celle-ci: printf(argv[1]). Or, un printf s'écrit de cette façon: printf("chaine formatée", var, var, var, ...)!!!
Si on pouvait faire en sorte que argv[1] soit "%s", buffer, on gagne la partie.
Mais j'ai essayé ./binary5 "%s",buffer et j'ai eu en retour un memory fault. Idem avec d'autres syntaxes encapsulant les guillemets. Mais je sens que c'est l'idée...

[Médinoc]

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).

[momoski]

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é
je vous met ce qu'il a dit

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.

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?

[Sve@r]

Oui. grosso-modo, il te dit de faire une copie du code source, le modifier pour qu'il ouvre un fichier accessible.
Ou mieux, cloner le répertoire entier et créer un autre fichier ".passwd" mais accessible cette fois ; comme ça les chaines statiques du code source restent identiques à celles de l'original et tu as de grandes chances que la mémoire soit exactement la même
Ensuite regarder avec gdb à quel endroit se trouve la variable buffer.

Puis enfin mettre le bon paramètre au programme d'origine pour que argv[1] aille taper au bon endroit...

[momoski]

Puis enfin mettre le bon paramètre au programme d'origine pour que argv[1] aille taper au bon endroit...

Mais si on trouve le bon paramètre, comment fait pour modifier le argv[1] sachant qu'on a accès au code source original qu'en lecture seule. Donc pas moyen de le modifier.

[Sve@r]

Mais si on trouve le bon paramètre, comment fait pour modifier le argv[1]

Tu appelles le programme en mettant en paramètre n° 1 une chaine spécifique pour que le programme traduise ça par "afficher buffer"...

sachant qu'on a accès au code source original qu'en lecture seule. Donc pas moyen de le modifier.

Et même si tu pouvais le modifier (ce qui est d'ailleurs possible sur une copie), tu ne pourrais pas mettre le setuid à l'exécutable généré.

[momoski]

Salut Sve@r,

Tu appelles le programme en mettant en paramètre n° 1 une chaine spécifique pour que le programme traduise ça par "afficher buffer"

As-tu pu tester sa méthode?