Comment une application (suid ou pas d'ailleur) peut elle se premunir contre cela ?
A priori quand elle ouvre un fichier il obtient le plus petit descripteur disponible (posix), donc eventuellement stderr ou stdout si c'est libre.
du coup tout "printf" est fait dans le fichier, c'est le probleme d'aujourd'hui.
pour s'en premunir, elle pourrait tester que lors de l'ouverture elle obtient bien un id>2 ...
ou ne rien ecrire/lire dans les descripteur par defaut si elle ne fait pas le test.
le plus simple c'est quand meme pour une fois de tester dans le noyau. C'est pas pareil que "la pile non executable" ou le patch ne garanti pas que les exploits n'auront pas lieu.
Ici la correction noyau est efficace, par contre le test dans le kernel devrait peut etre (en plus) sortir un gros warning dans les logs de manière a attirer l'attention des developpeurs ...
[^] # Re: Aucun rapport avec le noyau
Posté par PLuG . En réponse à la dépêche Faille dans certains noyaux : détournement de stdio/stderr. Évalué à 1.
Comment une application (suid ou pas d'ailleur) peut elle se premunir contre cela ?
A priori quand elle ouvre un fichier il obtient le plus petit descripteur disponible (posix), donc eventuellement stderr ou stdout si c'est libre.
du coup tout "printf" est fait dans le fichier, c'est le probleme d'aujourd'hui.
pour s'en premunir, elle pourrait tester que lors de l'ouverture elle obtient bien un id>2 ...
ou ne rien ecrire/lire dans les descripteur par defaut si elle ne fait pas le test.
le plus simple c'est quand meme pour une fois de tester dans le noyau. C'est pas pareil que "la pile non executable" ou le patch ne garanti pas que les exploits n'auront pas lieu.
Ici la correction noyau est efficace, par contre le test dans le kernel devrait peut etre (en plus) sortir un gros warning dans les logs de manière a attirer l'attention des developpeurs ...