Pour éviter de se faire pièger par un PATH qui aurait été modifié pour
détourner l'exécution de commandes systèmes par des version « modifiées »
[...], j'ai pris l'habitude de préciser le chemin des commandes exécutées
dans mes scripts bash. Toutefois, je me rends compte que j'omets souvent
de le faire pour des commandes telles que rm, echo, cd... Est-ce grave,
docteur ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Erwan David
(Olivier Le Cam) écrivait :
Bonjour,
Pour éviter de se faire pièger par un PATH qui aurait été modifié pour détourner l'exécution de commandes systèmes par des version « modifiées » [...], j'ai pris l'habitude de préciser le chemin des commandes exécutées dans mes scripts bash. Toutefois, je me rends compte que j'omets souvent de le faire pour des commandes telles que rm, echo, cd... Est-ce grave, docteur ?
D'avance, merci
Certaines sont des builtin du shell (cd toujours, echo souvent). Pour les autres ça dépend du degré de parano, mais en toute rigueur il faudrait.
Il faut aussi commencer le script par la définition de son PATH uniquement sur des répertoires système.
-- Erwan
olc@neottia.net (Olivier Le Cam) écrivait :
Bonjour,
Pour éviter de se faire pièger par un PATH qui aurait été modifié pour
détourner l'exécution de commandes systèmes par des version « modifiées »
[...], j'ai pris l'habitude de préciser le chemin des commandes exécutées
dans mes scripts bash. Toutefois, je me rends compte que j'omets souvent
de le faire pour des commandes telles que rm, echo, cd... Est-ce grave,
docteur ?
D'avance, merci
Certaines sont des builtin du shell (cd toujours, echo souvent).
Pour les autres ça dépend du degré de parano, mais en toute rigueur il
faudrait.
Il faut aussi commencer le script par la définition de son PATH
uniquement sur des répertoires système.
Pour éviter de se faire pièger par un PATH qui aurait été modifié pour détourner l'exécution de commandes systèmes par des version « modifiées » [...], j'ai pris l'habitude de préciser le chemin des commandes exécutées dans mes scripts bash. Toutefois, je me rends compte que j'omets souvent de le faire pour des commandes telles que rm, echo, cd... Est-ce grave, docteur ?
D'avance, merci
Certaines sont des builtin du shell (cd toujours, echo souvent). Pour les autres ça dépend du degré de parano, mais en toute rigueur il faudrait.
Il faut aussi commencer le script par la définition de son PATH uniquement sur des répertoires système.
-- Erwan
Sebastien Monbrun aka TiChou
Dans le message <news:45c9d4b9$, *Olivier Le Cam* tapota sur f.c.securite :
Pour éviter de se faire pièger par un PATH qui aurait été modifié pour détourner l'exécution de commandes systèmes par des version « modifiées » [...], j'ai pris l'habitude de préciser le chemin des commandes exécutées dans mes scripts bash.
Il suffit de définir la variable PATH convenablement en début de script.
Mais il n'y a pas que la variable d'environnement PATH qui pourrait présenter un danger. Je pense par exemple à la variable LD_PRELOAD qui pourrait modifier insidieusement l'exécution de certaines commandes.
Bref, pour exécuter un script shell avec un environnement sain, je conseillerai l'utilisation de la commande env et de son option '-i'.
Toutefois, je me rends compte que j'omets souvent de le faire pour des commandes telles que rm, echo, cd...
echo et cd sont des commandes internes au shell bash, donc il n'y a pas de chemin à préciser pour ces commandes là.
-- Sébastien Monbrun aka TiChou
Dans le message <news:45c9d4b9$1@ac-versailles.fr>,
*Olivier Le Cam* tapota sur f.c.securite :
Pour éviter de se faire pièger par un PATH qui aurait été modifié pour
détourner l'exécution de commandes systèmes par des version « modifiées »
[...], j'ai pris l'habitude de préciser le chemin des commandes exécutées
dans mes scripts bash.
Il suffit de définir la variable PATH convenablement en début de script.
Mais il n'y a pas que la variable d'environnement PATH qui pourrait
présenter un danger. Je pense par exemple à la variable LD_PRELOAD qui
pourrait modifier insidieusement l'exécution de certaines commandes.
Bref, pour exécuter un script shell avec un environnement sain, je
conseillerai l'utilisation de la commande env et de son option '-i'.
Toutefois, je me rends compte que j'omets souvent de le faire pour des
commandes telles que rm, echo, cd...
echo et cd sont des commandes internes au shell bash, donc il n'y a pas de
chemin à préciser pour ces commandes là.
Dans le message <news:45c9d4b9$, *Olivier Le Cam* tapota sur f.c.securite :
Pour éviter de se faire pièger par un PATH qui aurait été modifié pour détourner l'exécution de commandes systèmes par des version « modifiées » [...], j'ai pris l'habitude de préciser le chemin des commandes exécutées dans mes scripts bash.
Il suffit de définir la variable PATH convenablement en début de script.
Mais il n'y a pas que la variable d'environnement PATH qui pourrait présenter un danger. Je pense par exemple à la variable LD_PRELOAD qui pourrait modifier insidieusement l'exécution de certaines commandes.
Bref, pour exécuter un script shell avec un environnement sain, je conseillerai l'utilisation de la commande env et de son option '-i'.
Toutefois, je me rends compte que j'omets souvent de le faire pour des commandes telles que rm, echo, cd...
echo et cd sont des commandes internes au shell bash, donc il n'y a pas de chemin à préciser pour ces commandes là.
-- Sébastien Monbrun aka TiChou
Vincent Bernat
OoO Pendant le repas du mercredi 07 février 2007, vers 19:52, Sebastien Monbrun aka TiChou disait:
Bref, pour exécuter un script shell avec un environnement sain, je conseillerai l'utilisation de la commande env et de son option '-i'.
Je ne vois pas trop ce que cela changerait d'un point de vue sécurité. Si le script est destiné à être exécuté avec des privilèges plus importants, les programmes comme sudo assainissent déjà l'environnement et empêchent le préchargement de bibliothèques (car ils sont suid root).
Si comme tu l'indiques, la variable d'environnement LD_PRELOAD contient du code hostile, celui-ci peut très bien détourner les tentatives de modification de l'environnement.
Je trouve au contraire qu'il vaut mieux éviter de définir le chemin précis des commandes. Si un administrateur colle sa commande bzip2 dans /opt/bin/bzip2, il a sans doute ses raisons de le faire. -- BOFH excuse #360: Your parity check is overdrawn and you're out of cache.
OoO Pendant le repas du mercredi 07 février 2007, vers 19:52,
Sebastien Monbrun aka TiChou <gro.uohcit@uohcit.news.free.fr> disait:
Bref, pour exécuter un script shell avec un environnement sain, je
conseillerai l'utilisation de la commande env et de son option '-i'.
Je ne vois pas trop ce que cela changerait d'un point de vue
sécurité. Si le script est destiné à être exécuté avec des privilèges
plus importants, les programmes comme sudo assainissent déjà
l'environnement et empêchent le préchargement de bibliothèques (car
ils sont suid root).
Si comme tu l'indiques, la variable d'environnement LD_PRELOAD
contient du code hostile, celui-ci peut très bien détourner les
tentatives de modification de l'environnement.
Je trouve au contraire qu'il vaut mieux éviter de définir le chemin
précis des commandes. Si un administrateur colle sa commande bzip2
dans /opt/bin/bzip2, il a sans doute ses raisons de le faire.
--
BOFH excuse #360:
Your parity check is overdrawn and you're out of cache.
OoO Pendant le repas du mercredi 07 février 2007, vers 19:52, Sebastien Monbrun aka TiChou disait:
Bref, pour exécuter un script shell avec un environnement sain, je conseillerai l'utilisation de la commande env et de son option '-i'.
Je ne vois pas trop ce que cela changerait d'un point de vue sécurité. Si le script est destiné à être exécuté avec des privilèges plus importants, les programmes comme sudo assainissent déjà l'environnement et empêchent le préchargement de bibliothèques (car ils sont suid root).
Si comme tu l'indiques, la variable d'environnement LD_PRELOAD contient du code hostile, celui-ci peut très bien détourner les tentatives de modification de l'environnement.
Je trouve au contraire qu'il vaut mieux éviter de définir le chemin précis des commandes. Si un administrateur colle sa commande bzip2 dans /opt/bin/bzip2, il a sans doute ses raisons de le faire. -- BOFH excuse #360: Your parity check is overdrawn and you're out of cache.
Stephane Catteau
Vincent Bernat devait dire quelque chose comme ceci :
Je trouve au contraire qu'il vaut mieux éviter de définir le chemin précis des commandes. Si un administrateur colle sa commande bzip2 dans /opt/bin/bzip2, il a sans doute ses raisons de le faire.
Bon, pour moi c'est l'aube là, donc je peux oublier des choses au passage, mais quand même, je m'interroge sur l'intérêt de tout cela.
Hors /usr/home, les répertoires nécessitant d'avoir le droit d'execution pour le groupe et les autres ne leur laisse pas le droit d'écriture. Donc pour placer un binaire compromis dans l'un de ces répertoire, il faut être root. Or, dans un tel cas se contenter de déposer, ailleurs, une copie compromise d'une commande est un gachis. Si vraiment on veut le faire, autant remplacer le binaire initial et en profiter pour modifier les infos qui permettraient de voir que le binaire a été modifié. Dans le même temps, les répertoires nécessitants le droit d'écriture pour tous n'ont pas vraiment besoin du droit d'execution. Donc retirer ce droit, ou mieux monter tout ça en noexec, est bien plus intéressant. Reste les binaires placés quelque part dans /usr/home/someone, mais leur intérêt reste limité, puisque le binaire s'executera avec les droits de someone.
Donc amha, se demander si la dernière fois que l'on a utilisé zcat, on a bien pensé à le préfixer du path, ça n'apporte pas grand chose. Ce serait même plutôt le contraire, parce que cela tend à détourner les yeux du vrai problème. A force de dormir tranquille parce que l'on sait qu'un binaire compromis placé ailleurs ne nous fera aucun dégat, on en oublie qu'avant de faire des dégats, le binaire a été placé sur la machine, ce qui ne devrait tout simplement jamais arriver. Il me semble nettement préférable de trouver un moyen de garantir l'intégrité des sommes de controle (ou quoi que ce soit d'autre) permettant de vérifier l'intégrité des binaires, et de penser à vérifier celle-ci le plus souvent possible. Cela sera plus efficace que le préfixage des commandes, puisque cela marchera même lorsque c'est le binaire initial qui est compromis. Dans le même temps cela nous informera que le binaire a été compromis, et donc que la machine l'a été elle aussi. Et pour finira cela rendra définitivement inutile le préfixage, ce qui simplifiera le débat quant à savoir s'il faut le faire toujours, et comment le faire en étant sûr de ne rien risquer.
Vincent Bernat devait dire quelque chose comme ceci :
Je trouve au contraire qu'il vaut mieux éviter de définir le chemin
précis des commandes. Si un administrateur colle sa commande bzip2
dans /opt/bin/bzip2, il a sans doute ses raisons de le faire.
Bon, pour moi c'est l'aube là, donc je peux oublier des choses au
passage, mais quand même, je m'interroge sur l'intérêt de tout cela.
Hors /usr/home, les répertoires nécessitant d'avoir le droit
d'execution pour le groupe et les autres ne leur laisse pas le droit
d'écriture. Donc pour placer un binaire compromis dans l'un de ces
répertoire, il faut être root. Or, dans un tel cas se contenter de
déposer, ailleurs, une copie compromise d'une commande est un gachis.
Si vraiment on veut le faire, autant remplacer le binaire initial et en
profiter pour modifier les infos qui permettraient de voir que le
binaire a été modifié.
Dans le même temps, les répertoires nécessitants le droit d'écriture
pour tous n'ont pas vraiment besoin du droit d'execution. Donc retirer
ce droit, ou mieux monter tout ça en noexec, est bien plus intéressant.
Reste les binaires placés quelque part dans /usr/home/someone, mais
leur intérêt reste limité, puisque le binaire s'executera avec les
droits de someone.
Donc amha, se demander si la dernière fois que l'on a utilisé zcat, on
a bien pensé à le préfixer du path, ça n'apporte pas grand chose. Ce
serait même plutôt le contraire, parce que cela tend à détourner les
yeux du vrai problème. A force de dormir tranquille parce que l'on sait
qu'un binaire compromis placé ailleurs ne nous fera aucun dégat, on en
oublie qu'avant de faire des dégats, le binaire a été placé sur la
machine, ce qui ne devrait tout simplement jamais arriver.
Il me semble nettement préférable de trouver un moyen de garantir
l'intégrité des sommes de controle (ou quoi que ce soit d'autre)
permettant de vérifier l'intégrité des binaires, et de penser à
vérifier celle-ci le plus souvent possible. Cela sera plus efficace que
le préfixage des commandes, puisque cela marchera même lorsque c'est le
binaire initial qui est compromis. Dans le même temps cela nous
informera que le binaire a été compromis, et donc que la machine l'a
été elle aussi. Et pour finira cela rendra définitivement inutile le
préfixage, ce qui simplifiera le débat quant à savoir s'il faut le
faire toujours, et comment le faire en étant sûr de ne rien risquer.
Vincent Bernat devait dire quelque chose comme ceci :
Je trouve au contraire qu'il vaut mieux éviter de définir le chemin précis des commandes. Si un administrateur colle sa commande bzip2 dans /opt/bin/bzip2, il a sans doute ses raisons de le faire.
Bon, pour moi c'est l'aube là, donc je peux oublier des choses au passage, mais quand même, je m'interroge sur l'intérêt de tout cela.
Hors /usr/home, les répertoires nécessitant d'avoir le droit d'execution pour le groupe et les autres ne leur laisse pas le droit d'écriture. Donc pour placer un binaire compromis dans l'un de ces répertoire, il faut être root. Or, dans un tel cas se contenter de déposer, ailleurs, une copie compromise d'une commande est un gachis. Si vraiment on veut le faire, autant remplacer le binaire initial et en profiter pour modifier les infos qui permettraient de voir que le binaire a été modifié. Dans le même temps, les répertoires nécessitants le droit d'écriture pour tous n'ont pas vraiment besoin du droit d'execution. Donc retirer ce droit, ou mieux monter tout ça en noexec, est bien plus intéressant. Reste les binaires placés quelque part dans /usr/home/someone, mais leur intérêt reste limité, puisque le binaire s'executera avec les droits de someone.
Donc amha, se demander si la dernière fois que l'on a utilisé zcat, on a bien pensé à le préfixer du path, ça n'apporte pas grand chose. Ce serait même plutôt le contraire, parce que cela tend à détourner les yeux du vrai problème. A force de dormir tranquille parce que l'on sait qu'un binaire compromis placé ailleurs ne nous fera aucun dégat, on en oublie qu'avant de faire des dégats, le binaire a été placé sur la machine, ce qui ne devrait tout simplement jamais arriver. Il me semble nettement préférable de trouver un moyen de garantir l'intégrité des sommes de controle (ou quoi que ce soit d'autre) permettant de vérifier l'intégrité des binaires, et de penser à vérifier celle-ci le plus souvent possible. Cela sera plus efficace que le préfixage des commandes, puisque cela marchera même lorsque c'est le binaire initial qui est compromis. Dans le même temps cela nous informera que le binaire a été compromis, et donc que la machine l'a été elle aussi. Et pour finira cela rendra définitivement inutile le préfixage, ce qui simplifiera le débat quant à savoir s'il faut le faire toujours, et comment le faire en étant sûr de ne rien risquer.
Olivier Le Cam
Bonjour,
Merci pour vos réponses et désolé pour le sujet, encodé en utf8 et qui a visiblement été tronqué quelque part.
Je comprends bien que la sécurité ne doit pas se limiter à préfixer les commandes par le chemin permettant de les atteindre. C'était plus dans l'esprit « quitte à frotter, autant faire briller ». :)
Merci encore pour vos réponses,
Au plaisir, -- olc
Bonjour,
Merci pour vos réponses et désolé pour le sujet, encodé en utf8 et qui a
visiblement été tronqué quelque part.
Je comprends bien que la sécurité ne doit pas se limiter à préfixer les
commandes par le chemin permettant de les atteindre. C'était plus dans
l'esprit « quitte à frotter, autant faire briller ». :)
Merci pour vos réponses et désolé pour le sujet, encodé en utf8 et qui a visiblement été tronqué quelque part.
Je comprends bien que la sécurité ne doit pas se limiter à préfixer les commandes par le chemin permettant de les atteindre. C'était plus dans l'esprit « quitte à frotter, autant faire briller ». :)
