Heuh tu l'as chope ou ton exemple la ?
Parce que oui, c'est normal que ca marche, c'est la norme POSIX qui veut ca ...
Si je comprend bien, dans exploit.c, tu ferme le canal 2 (stderr), puis tu fais un exec avec comme parametre {compromised, "this text ... root_owned_file"}.
Dans compromised, tu ouvres un fichier. Puisque il n'y a plus de canal 2, le fichier s'ouvre donc sur le canal 2. Du coup, ecrire dans le canal 2 revient a ecrire dans le fichier juste ouvert ...
Rien de neuf sous le soleil.
La le bug qu'on a trouve, c'est que ca marchait aussi dans le cas ou le programme que tu executais (ici, compromised) etait suid.
Je ne vois aucune trace dans ton makefile de :
1 - execution de exploit en user non root
2 - droits suid sur compromised
Avec ces deux cas la reunis, tu pourrais conclure ... Mais pour l'instant ...
[^] # Re: j'ai teste pour vous sous linux
Posté par Epsos . En réponse à la dépêche Faille dans certains noyaux : détournement de stdio/stderr. Évalué à 10.
Parce que oui, c'est normal que ca marche, c'est la norme POSIX qui veut ca ...
Si je comprend bien, dans exploit.c, tu ferme le canal 2 (stderr), puis tu fais un exec avec comme parametre {compromised, "this text ... root_owned_file"}.
Dans compromised, tu ouvres un fichier. Puisque il n'y a plus de canal 2, le fichier s'ouvre donc sur le canal 2. Du coup, ecrire dans le canal 2 revient a ecrire dans le fichier juste ouvert ...
Rien de neuf sous le soleil.
La le bug qu'on a trouve, c'est que ca marchait aussi dans le cas ou le programme que tu executais (ici, compromised) etait suid.
Je ne vois aucune trace dans ton makefile de :
1 - execution de exploit en user non root
2 - droits suid sur compromised
Avec ces deux cas la reunis, tu pourrais conclure ... Mais pour l'instant ...
A+