Discussion :

[momoski]

Bonjour à tous,

J'ai un programme en C que j'arrive pas à debugger depuis plusieurs jours. J'ai une erreur de segmentation à la ligne 6 avec gdb (fonction fgets).

Je m'explique:

c'est un TP que je dois réaliser. Le code a été écris par quelqu'un d'autre et moi j'ai qu'un droit de lecture sur le fichier source (le fichier étant déjà compilé) et je peux aussi le debugger.

Le but pour moi c'est de pouvoir retrouver le contenu du "buffer" sachant que je ne peux pas lire le fichier ".passwd"

Or nul été le fait que j'ai une erreur de segmentation à la ligne 6, j'aurai pu faire un break avec gdb sur la ligne 7 et faire un "print buffer" pour voir le contenu du buffer.

Or là j'ai un problème de segmentation sur la ligne et je ne peux modifier le fichier.

Si quelqu'un a une idée, merci

Merci pour votre aide et voici le code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#include <stdio.h>
#include <unistd.h>
int main(int argc, char *argv[]){
        FILE *secret = fopen("/challenge/binary/binary5/.passwd", "rt");
        char buffer[32];
        fgets(buffer, sizeof(buffer), secret);
        printf(argv[1]);
        fclose(secret);
        return 0;
}

[jblecanard]

Salut

C'est du C, ce n'est pas le bon forum.

Sinon, tu devrais commencer par tester le pointeur secret avant de lire dedans, car l'ouverture de ton fichier peut avoir échoué.

[momoski]

Salut

C'est du C, ce n'est pas le bon forum.

Sinon, tu devrais commencer par tester le pointeur secret avant de lire dedans, car l'ouverture de ton fichier peut avoir échoué.

Salut jblecanard
et merci de répondre

Quand, je fais un print avec gdb sur le pointeur secret, il me ramène une adresse en hexadécimale.

Ps: comment ramener l'article dans la rubrique C

Merci

[momoski]

Autre chose: en faite, j'ai pas de droit de modification sur le fichier source, que droit de lecture sur le fichier et je peux juste le debugger avec gdb

[Ehonn]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

printf(argv[1]);}

Tu passes bien un argument au programme ?

[momoski]

Je m'explique:

c'est un TP que je dois réaliser. Le code a été écris par quelqu'un d'autre et moi j'ai qu'un droit de lecture sur le fichier source (le fichier étant déjà compilé) et je peux aussi le debugger.

Le but pour moi c'est de pouvoir retrouver le contenu du "buffer" sachant que je ne peux lire le fichier ".passwd"

Or nul été le fait que j'ai une erreur de segmentation à la ligne 6, j'aurai pu faire un break avec gdb sur la ligne 7 et faire un "print buffer" pour voir le contenu du buffer.

Or là j'ai un problème de segmentation sur la ligne et je ne peux modifier le fichier.

Si quelqu'un a une idée, merci

[koala01]

Salut,

Si tu as le code source, rien ne t'empêche de le modifier toi même avant de le recompiler!

Et comme gdb te permet de lire le fichier source, c'est que tu as ce fichier quelque part, et donc que tu peux le modifier

Fais attention au fait que la chaine de caractères "/challenge/binary/binary5/.passwd" est un chemin (absolu et non relatif) vers un fichier se trouvant sur un système linux.

Cela signifie :

1. que le fichier .pasword doit se trouver dans un dossier /challenge/binary/binary5 et non dans un éventuel dossier /home/momoski/(xxx)/challenge/binary/binary5
2. que, si tu es sous windows, il n'y a strictement aucune chance pour que le système arrive à retrouver le fichier en question, les éparateurs de dossiers étant le back slash (\)

Tout cela fait qu'il est plus que probable que le programme ne trouve effectivement pas le fichier .password, et que secret a donc effectivement de fortes chances d'être nul.

Pour au minimum corriger ce problème, il faut, comme jblecanard l'a fait remarquer, tester la valeur de secret sous la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <stdio.h>
#include <unistd.h>
int main(int argc, char *argv[]){
        FILE *secret = fopen("/challenge/binary/binary5/.passwd", "rt");
        if(secret == NULL) {// d'autre formes sont possibles ;)
            printf("cannot open .secret file")
            return 1;
        }
        char buffer[32];
        fgets(buffer, sizeof(buffer), secret);
        printf(argv[1]);
        fclose(secret);
        return 0;
}

Ps: comment ramener l'article dans la rubrique C

Je m'en suis occupé

[Médinoc]

Note: "t" n'est pas un spécificateur de format reconnu par la norme C, et même sur les plate-formes où il est reconnu, il est le plus souvent redondant: L'absence de "b" suffit.

[momoski]

Salut,

Si tu as le code source, rien ne t'empêche de le modifier toi même avant de le recompiler!

Et comme gdb te permet de lire le fichier source, c'est que tu as ce fichier quelque part, et donc que tu peux le modifier

Fais attention au fait que la chaine de caractères "/challenge/binary/binary5/.passwd" est un chemin (absolu et non relatif) vers un fichier se trouvant sur un système linux.

Cela signifie :
que le fichier .pasword doit se trouver dans un dossier /challenge/binary/binary5 et non dans un éventuel dossier /home/momoski/(xxx)/challenge/binary/binary5
que, si tu es sous windows, il n'y a strictement aucune chance pour que le système arrive à retrouver le fichier en question, les éparateurs de dossiers étant le back slash (\)
Tout cela fait qu'il est plus que probable que le programme ne trouve effectivement pas le fichier .password, et que secret a donc effectivement de fortes chances d'être nul.

Pour au minimum corriger ce problème, il faut, comme jblecanard l'a fait remarquer, tester la valeur de secret sous la forme de

J'ai accès au code source en lecture seule (r). le fichier se trouve sur un serveur linux auquel j'accède à distance par ssh. le code source a été compilé par l'admin du serveur avec gcc avec l'option -g. Le fichier ".passwd" existe bien et bien sur le serveur sauf que je ne peux pas l'ouvrir avec vi ou autre (permission denied).

Le but est de m'obliger à passer par un désembuage pour connaitre le contenu du ".passwd"

[Sve@r]

...que, si tu es sous windows, il n'y a strictement aucune chance pour que le système arrive à retrouver le fichier en question, les séparateurs de dossiers étant le back slash (\)

Salut
Généralement les outils de prog sous zindow convertissent les slashes en backslashes...

J'ai accès au code source en lecture seule (r).

Si tu peux lire le code source, tu peux alors le copier chez-toi pour ensuite travailler sur la copie...

Le fichier ".passwd" existe bien et bien sur le serveur sauf que je ne peux pas l'ouvrir avec vi ou autre (permission denied).

Si tu ne peux pas l'ouvrir avec "vi", alors tu ne pourras pas l'ouvrir avec aucun autre programme y compris ceux que tu compiles toi-même (pensais-tu vraiment que la sécurité sous Linux soit aussi faible ???).
Accessoirement si tu modifies ton code ainsi

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
#include <stdio.h>
#include <unistd.h>
#include <errno.h>
int main(int argc, char *argv[]){
        FILE *secret = fopen("/challenge/binary/binary5/.passwd", "rt");
        if(secret == NULL) {// d'autre formes sont possibles ;)
            perror("cannot open .secret file");
            return 1;
        }
         ...
}

Tu auras un message de type "cannot open .secret file - permission denied" qui seras exactement le même que celui que te donne "vi" (normal, il fait appel au même protocole d'affichage des messages systèmes)...

[momoski]

Tu auras un message de type "cannot open .secret file - permission denied" qui seras exactement le même que celui que te donne "vi" (normal, il fait appel au même protocole d'affichage des messages systèmes)...

Salut Sve@r,

Effectivement, je m'en suis rendu compte. je ne pourrai pas ouvrir le fichier avec le programme. Raison pour laquelle à la ligne 6 du code j'ai une erreur de segmentation car on tente de copier dans le "buffer" le fichier pointé par "secret" or celui-ci pointe vers NULL car n'ayant pas pu ouvrir le ".passwd" (droit de lecture).

Faut maintenant que je trouve un moyen de contourner ce droit de lecture avec le désembuage en utilisant gdb;

Tu as une astuce à me refiler pour ca?

[koala01]

Salut
Généralement les outils de prog sous zindow convertissent les slashes en backslashes...

Si tu utilises une bibliothèque tierce, comme boost en C++, oui...

Mais, si tu essayes d'introduire directement le chemin d'acces vers le fichier "en dur" dans une chaine de caractères, tu es obligé de jouer avec les back slash sous windows (et donc de les échapper ).

A moins que cela n'ait changé ces quelques dernières années

[momoski]

Si tu utilises une bibliothèque tierce, comme boost en C++, oui...

Mais, si tu essayes d'introduire directement le chemin d'acces vers le fichier "en dur" dans une chaine de caractères, tu es obligé de jouer avec les back slash sous windows (et donc de les échapper ).

A moins que cela n'ait changé ces quelques dernières années

Je travaille sur un environnement linux en ssh et non sur windows. Je dois trouver un moyen de contourner le droit de lecture que je n'ai pas sur le fichier ".passwd" avec un outil de désembuage.

Si vous avez une idée, je suis preneur

[Sve@r]

Je travaille sur un environnement linux en ssh et non sur windows. Je dois trouver un moyen de contourner le droit de lecture que je n'ai pas sur le fichier ".passwd" avec un outil de désembuage.

Si vous avez une idée, je suis preneur

Sur un Unix/Linux non traffiqué, les seuls moyens de contourner un droit d'accès sont

1. booter sur un CD/DVD/clef USB annexe puis monter le filesystem contenant le fichier (cela présuppose un accès physique à la machine + un boot non verrouillé + un filesystem non crypté)
2. utiliser un programme ayant un accès root via suid (cela présuppose que root t'aura laissé un accès sur la machine suffisamment longtemps pour que tu positionnes un setuid sur un programme comme /bin/sh par exemple)

En dehors de cela, il n'y a aucun aucun aucun moyen de contourner un droit d'accès. Ce n'est pas pour rien si les américains (créateurs de zindow) ont choisi Linux pour gérer le système de combat de leur nouvelle frégate DDG 1000. Ils sont pas cons. Ils implantent leur zindow pourri de failles en tous sens (la plupart probablement via la NSA elle-même) dans nos administrations étatiques via des offres promotionnelles de folie (gratuit pour les écoles etc) mais ils utilisent un vrai OS sécurisé pour leurs propres systèmes d'armes...

Ceci dit, je reste étonné qu'on te fasse bosser un TP sur un fichier verrouillé. J'ai été prof et généralement quand j'avais besoin de faire travailler mes élèves sur un fichier d'exemple je prenais /etc/passwd+/etc/group qui restent toujours lisible (obligé pour que les outils comme ls par exemple puissent associer les uid/gid aux logins/groupes correspondants) et très complet pour les besoins généraux (possibilité par exemple de lier le gid de /etc/passwd au gid de /etc/group pour monter des erzatz de bdd).
J'ai l'impression que tu cherches à nous bananer pour qu'on t'aide à hacker un système. Ben t'es tranquille, même avec la meilleure volonté du monde on ne hacke pas un Unix/Linux aussi facilement que certains s'en vantent et même quand on arrive à attaquer certains services comme httpd ou postgres ben une fois rentré on se retrouve enfermé dans le service hacké lequel n'a pas plus de droit sur le système qu'un user comme un autre.

[Metalman]

Bravo Sve@r pour le troll... mais intéresse toi un peu aux droits sur les Windows XP SP2 et +, et tu verras que c'est "au moins" autant bloqué voire beaucoup plus que les chmod... et seules les ACL Unix sont comparables à ça...

[momoski]

J'ai l'impression que tu cherches à nous bananer pour qu'on t'aide à hacker un système. Ben t'es tranquille, même avec la meilleure volonté du monde on ne hacke pas un Unix/Linux aussi facilement que certains s'en vantent et même quand on arrive à attaquer certains services comme httpd ou postgres ben une fois rentré on se retrouve enfermé dans le service hacké lequel n'a pas plus de droit sur le système qu'un user comme un autre.

Je ne tente de berner personne encore moins harcker un système. Dans le cadre de ma formation, il nous a été demandé de nous inscrire sur le site www.root-me.org et de réaliser certains challenges qui nous ont été spécifiquement assigné.Dans mon cas, je dois réaliser un challenge dénommé "binary5" dont je vous ai expliqué le sujet jusque là. C'est tout.

Pour plus d'infos, vous pouvez vous connecter sur le site en question.

[Sve@r]

Je ne tente de berner personne encore moins harcker un système. Dans le cadre de ma formation, il nous a été demandé de nous inscrire sur le site www.root-me.org et de réaliser certains challenges qui nous ont été spécifiquement assigné.Dans mon cas, je dois réaliser un challenge dénommé "binary5" dont je vous ai expliqué le sujet jusque là. C'est tout.

Pour plus d'infos, vous pouvez vous connecter sur le site en question.

Arf il à l'air chouette. Je vais en essayer certains.

Donc ce n'est pas pour hacker "pour de vrai" mais essayer quelques exos de hack. Donc il est probable que le système en question ait laissé quelques portes ouvertes. A toi de les trouver. C'est un travail assez long qui demande de la recherche. Et on en revient au point de départ: depuis un programme compilé(par toi) tu ne peux pas accéder à un fichier verrouillé par un autre. Peut-être que le système possède un service/outil permettant d'accéder à ce fichier.

Moi je commencerais par faire un find / -type f -uid 0 -perm -4000 -print 2>/dev/null pour répertorier tous les programmes root ayant un setuid voir s'il n'y en aurait pas un particulier.
Accessoirement avoir le propriétaire/groupe/droits de ce fameux .passwd serait utile au cas où ce proprio ne serait pas root et que ledit proprio ait laissé trainer (comme par hasard) un programme avec un setuid à lui (n'importe qui utilisant ledit programme aurait donc accès à ce fameux fichier)

Ceci dit, même si ce n'est pas du hack "pour de vrai" c'est quand-même un travail perso (voire de groupe) mais peut-être pas un boulot à faire faire par un forum...

[momoski]

Moi je commencerais par faire un find / -type f -uid 0 -perm -4000 -print 2>/dev/null pour répertorier tous les programmes root ayant un setuid voir s'il n'y en aurait pas un particulier.
Accessoirement avoir le propriétaire/groupe/droits de ce fameux .passwd serait utile au cas où ce proprio ne serait pas root et que ledit proprio ait laissé trainer (comme par hasard) un programme avec un setuid à lui (n'importe qui utilisant ledit programme aurait donc accès à ce fameux fichier)

Effectivement, je viens de voir que le code C compilé (binary5) est bien SETUID et que le propriétaire de ce code compilé est aussi propriétaire du fichier ".passwd"

Pourrais-tu me m'expliquer comment exécuter le fichier "binary5" pour qu'il puisse accéder au fichier ".passwd"?

Merci

[Médinoc]

Que signifie "désembuage" dans un contexte informatique?

[Sve@r]

Effectivement, je viens de voir que le code C compilé (binary5) est bien SETUID et que le propriétaire de ce code compilé est aussi propriétaire du fichier ".passwd"

Comme par hasard...

Pourrais-tu me m'expliquer comment exécuter le fichier "binary5" pour qu'il puisse accéder au fichier ".passwd"?

Ben normalement tu n'as qu'à l'appeler directement (en donnant son chemin complet). Grace au setuid, le code compilé s'exécutera avec les droits du propriétaire du code (et non avec les droits de l'appelant), accèdera tout seul au fichier .passwd (puisque c'est inscrit dans le code) et te donnera son contenu.

Toutefois ce code affiche aussi argv[1] (argument n° 1 qui semble inusité par ailleurs) donc il sera plus sage de l'appeler en donnant un argument bidon.
Bref moi je taperais directement chemin/binary5 toto et regarderait le résultat.

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