fonctionnement de * et detournement commandes

Oni_Shadow · Le 12/07/2014, à 18:41

Coucou,
je poste (encore) un topic car je me pose de nombreuse questions a propos des scripts bash du shell linux et de l'utilisation du caractere joker *
comment fonctionne-t-il?
regarder-t-il un par un si chaque fichier correspond ?
comment c'est executé?
si j'amais j'ai un fichier qui s'appelle ls est il suceptible d'etre injecté et d'executer la commande ls lors de l'appel du fichier par le caractere * ?
merci d'eclairecir tout ca...
O_S

serged · Le 13/07/2014, à 08:29

L'expansion des jokers se fait avant de lancer la commande, contrairement à DOS/Windows où la commande doit s'occuper de l'expansion. Ce qui peut parfois poser des problèmes...
si tu as un fichier "ls" :
- Il faut qu'il soit marqué "exécutable"
- De toute façon le shell ne cherche pas dans le répertoire courant le fichier la commande à exécuter
Ainsi si tu veux exécuter (volontairement) un fichier du répertoire courant, il faut :
- Qu'il soit marqué exécutable
- Que tu indique explicitement le chemin du fichier. Par exemple pour installer un programme (qui n'est pas dans les dépôts), il faut souvent taper :

./install

Dans le répoertoire où tu as décompressé l'archive.

Zakhar · Le 13/07/2014, à 08:42

serged a écrit :

- De toute façon le shell ne cherche pas dans le répertoire courant le fichier la commande à exécuter
(...)
./install

... tout à fait... sauf si le répertoire courant est un des répertoires du PATH... ce qui est une assez mauvaise idée parce qu'effectivement, dans ce cas install seul (sans le ./ devant) fonctionnera..

Dernière modification par Zakhar (Le 13/07/2014, à 08:43)

Brunod · Le 13/07/2014, à 08:44

Je nuancerai un peu les propos de serged, qui bien que parfaitement exact, omettent d'évoquer le problème suivant (je cite) :

"Des chercheurs en sécurité de DefenseCode viennent de publier un papier très intéressant pour qui s'intéresse un peu au hacking et au système Unix (Linux, OSX...etc.). Dans ce document, Leon de DefenseCode passe en revue quelques techniques fourbes qui exploitent le symbole '*' (wildcards) combiné à certaines commandes, pour injecter des arguments dans les commandes shells.
Par exemple, si un vilain pirate dépose sur votre serveur un fichier qu'il nomme "-rf'", celui-ci peut être passé en argument à la commande "rm" provoquant pas mal de dégâts. Démonstration :
[root@defensecode public]# ls -al
total 20
drwxrwxr-x. 5 leon leon 4096 Oct 28 17:04 .
drwx------. 22 leon leon 4096 Oct 28 16:15 ..
drwxrwxr-x. 2 leon leon 4096 Oct 28 17:04 DIR1
drwxrwxr-x. 2 leon leon 4096 Oct 28 17:04 DIR2
drwxrwxr-x. 2 leon leon 4096 Oct 28 17:04 DIR3
-rw-rw-r--. 1 leon leon 0 Oct 28 17:03 file1.txt
-rw-rw-r--. 1 leon leon 0 Oct 28 17:03 file2.txt
-rw-rw-r--. 1 leon leon 0 Oct 28 17:03 file3.txt
-rw-rw-r--. 1 nobody nobody 0 Oct 28 16:38 -rf
On voit là un répertoire avec quelques sous-répertoires et fichiers. Le fichier -rf appartient à l'utilisateur nobody. Imaginons maintenant que l'utilisateur root lance maintenant la commande "rm *"
[root@defensecode public]# rm *
[root@defensecode public]# ls -al
total 8
drwxrwxr-x. 2 leon leon 4096 Oct 28 17:05 .
drwx------. 22 leon leon 4096 Oct 28 16:15 ..
-rw-rw-r--. 1 nobody nobody 0 Oct 28 16:38 -rf
Tout le répertoire a été vidé, y compris les sous-répertoires. En réalité, la commande rm couplée à l'étoile passe en revue chaque fichier et sous répertoire comme ceci :
[user@defensecode WILD]$ rm DIR1 DIR2 DIR3 file1.txt file2.txt file3.txt -rf
Vous l'aurez compris, le fichier -rf est alors pris comme un argument, provoquant la suppression des répertoires sans aucun avertissement."

Extrait et plus d'infos ici : http://korben.info/unix-letoile-mort.html

Brunod

Oni_Shadow · Le 13/07/2014, à 10:44

d'accord donc en gros, pas de commande possible, mais les arguments, oui...
du coup je viens de tester et un simple fichier

--attributes-only

permet d'eviter a la commande

cp * ../

de copier les fichiers mais simplement des fichiers avec le meme nom, les atributs, mais vide...
un bon moyen de protéger son serveur ?

Brunod · Le 13/07/2014, à 11:20

oni_shadow a écrit :

...
un bon moyen de protéger son serveur ?

Je n'en sais rien. C'est un sujet très intéressant mais sur lequel je n'ai pas (et n'aurai pas dans l'immédiat) le temps de me pencher. Il faudra que j'y réfléchisse sérieusement; car il ne faut pas penser qu'à une seule commande mais à une solution plus globale. À moins qu'une action ne soit menée au niveau du système directement par les devs.
À suivre...

Postmortem · Le 13/07/2014, à 12:45

Beaucoup de commande GNU acceptent l'option -- qui marque la fin des options. Du coup, en faisant comme ça, on évite le souci, -rf sera bien vu comme un fichier :

rm -- *

Brunod · Le 13/07/2014, à 13:19

Oui, mais ça ne fonctionne que si on exécute la commande avec cette option, ce qui ne se fera pas automatiquement sauf si l'on sait que le fichier existe. Il faudrait une solution qui intègre cette sécurité par défaut, pour ne pas devoir vérifier le contenu d'un répertoire avant d'exécuter une commande.

Zakhar · Le 13/07/2014, à 19:03

Brunod a écrit :

Par exemple, si un vilain pirate dépose sur votre serveur un fichier qu'il nomme "-rf'", celui-ci peut être passé en argument à la commande "rm" provoquant pas mal de dégâts. Démonstration :

Dans un script digne de ce nom, si on te passe un argument pour un fichier à supprimer tu fais :

rm -- "{$1}"

Idem pour toute commande, parce qu'il est tout à fait légal de commencer un nom de fichier par un "-".

Dans le cas du -rf le résultat est assez destructeur, mais dans d'autre cas ton script ne fonctionnera tout simplement pas puisque tu vas tomber sur un nom qui ne correspond pas à une option.

Il est vrai que rm se comporte bizarrement lorsqu'un fichier commence par un '-', et donc il vaut mieux faire :

L'option rm -- * est très bien, je ne comprend pas ta réponse Brunod, peux-tu élaborer ? Ca fonctionne que tu aies ou pas des fichiers commençant pas '-'

Dernière modification par Zakhar (Le 13/07/2014, à 19:05)

Brunod · Le 13/07/2014, à 21:51

@Zakhar : Il ne s'agit pas que de script, je parle des commandes en général.
Je vais faire beaucoup de suppositions. Imaginons un répertoire sur lequel il y a du mouvement que je ne contrôle pas forcément (ftp, samba, qu'importe) sur lequel des fichiers arrivent dont un qui soit nommé comme un paramètre à passer à une commande, gardons le cas de rm;
Je ne vais pas vérifier la liste des fichiers avant de faire un rm * si je veux virer tout le lot. Donc je risque de passer ce "fichier-paramètre" sans le vouloir.
Ai-je répondu à ta question ?

Zakhar · Le 13/07/2014, à 22:27

Oui, tu as répondu...

Mais la suggestion était précisément de prendre l'habitude de taper rm -- *

En réalité, même si on te met un fichier nommé -rf ... je doute que cela fasse grand mal hormis... effectivement s'il y a des sous-répertoires dans le répertoire que tu nettoies.

En effet, tant que tu n'as que des fichiers dans le répertoire où tu lances la commande, rm * ou rm -rf * c'est tout pareil !

Du coup, je vais effectivement me méfier à deux fois avant de faire un rm * !

Dernière modification par Zakhar (Le 13/07/2014, à 22:29)

Brunod · Le 13/07/2014, à 22:39

Oui, mais le problème, c'est qu'il n'y a pas que la commande rm qui est concernée... Donc ça fait plusieurs particularités à retenir, ce qui n'est pas idéal.

Postmortem · Le 13/07/2014, à 22:50

Brunod a écrit :

Il faudrait une solution qui intègre cette sécurité par défaut, pour ne pas devoir vérifier le contenu d'un répertoire avant d'exécuter une commande.

Je ne vois pas comment cette sécurité pourrait être par défaut. Comment rm, ou n'importe quelle autre commande, pourrait décider quand -rf est un fichier ou quand c'est une option ?
Je pense que -- a justement été créé pour ça.

Zakhar · Le 14/07/2014, à 09:13

Et pourtant rm fait déjà certains tests... démonstration :

cd /tmp
mkdir test
cd test
touch -- -i -j
rm *

résultat :

rm a écrit :

rm : option invalide -- 'j'
Saisissez « rm ./-i » pour supprimer le fichier «-i».
Saisissez « rm --help » pour plus d'informations.

de plus, dans le cas présent rien n'est effacé !

$ ls
-i  -j

La suggestion de rm n'est donc pas le --, mais de faire :

rm ./*

Dernière modification par Zakhar (Le 14/07/2014, à 09:14)

Nolanux · Le 14/07/2014, à 09:16

voilà l'article dans son intégralité développez.com
Ce qui me conforte dans l'idée de bien comprendre les mécanismes et la syntaxe d'une commande avant de l'exécuter.

Brunod · Le 14/07/2014, à 11:08

Postmortem a écrit :

Brunod a écrit :
Il faudrait une solution qui intègre cette sécurité par défaut, pour ne pas devoir vérifier le contenu d'un répertoire avant d'exécuter une commande.
Je ne vois pas comment cette sécurité pourrait être par défaut. Comment rm, ou n'importe quelle autre commande, pourrait décider quand -rf est un fichier ou quand c'est une option ?
Je pense que -- a justement été créé pour ça.

Je ne sais pas, comme je disais, je ne me suis pas encore vraiment penché là-dessus. Mais peut-être, si la solution est générique, quelque chose comme interdire les noms de fichiers commençant par "-" ... Quitte à le gérer soi-même sur son système.
BD

Pseudo supprimé · Le 14/07/2014, à 14:39

Brunod a écrit :

Postmortem a écrit :
Brunod a écrit :
Il faudrait une solution qui intègre cette sécurité par défaut, pour ne pas devoir vérifier le contenu d'un répertoire avant d'exécuter une commande.
Je ne vois pas comment cette sécurité pourrait être par défaut. Comment rm, ou n'importe quelle autre commande, pourrait décider quand -rf est un fichier ou quand c'est une option ?
Je pense que -- a justement été créé pour ça.
Je ne sais pas, comme je disais, je ne me suis pas encore vraiment penché là-dessus. Mais peut-être, si la solution est générique, quelque chose comme interdire les noms de fichiers commençant par "-" ... Quitte à le gérer soi-même sur son système.
BD

je ne vois pas comment l'utilisateur pourrait intervenir. C'est le développeur, dans son code, qui évalue le typage, les conditions des arguments, dans une fonction, et renvoie ce qu'il veut en sortie de fonction. La gestion des erreurs est à la charge du développeur, et le comportement par défaut d'une fonction aussi. C'est tout de même prévisible !

Cela veut dire que si tu veux intervenir dans l'évaluation de "*" en tant qu'argument, il ta faudra modifier le code source de rm et poser une condition dessus.
http://www.opensource.apple.com/source/ … .2/rm/rm.c

Le man de rm précise tout de même que la commande attend un fichier.
Le type de variable est annoncée. C'est prévisible, d'autant plus que le script, ou la commande dans un terminal, est subordonnée aux variables d'environnement ou dans un contexte précis.

rm ./*

Brunod · Le 14/07/2014, à 15:00

Hmm non, je ne pensais pas à cela. J'envisageais plutôt une vérification sur la présence de noms de fichiers commençant par "-".
Mais comme je disais, je ne me suis pas encore penché sur le sujet; faut voir si ça tient la route.

Postmortem · Le 14/07/2014, à 16:58

Je ne comprends pas ton raisonnement Brunod. "--" est justement là pour marquer la fin des options et donc éviter qu'un fichier ou tout autre argument soit pris pour une option. C'est exactement ce qu'il faut utiliser pour éviter les problèmes décrits dans les articles ci-dessus.
Si on ne maîtrise pas les noms de fichiers sur lesquels on intervient, il suffit de prendre l'habitude de l'utiliser. Et d'ailleurs, au vu des exemples donnés, je vais l'utiliser plus souvent !

pingouinux · Le 14/07/2014, à 17:02

Bonjour,
Pour que cette option soit par défaut, il suffit de faire un alias

alias rm='rm --'

Postmortem · Le 14/07/2014, à 17:16

J'ai pas essayé mais si on fait un tel alias, on ne pourra pas utiliser d'options ou si ?

pingouinux · Le 14/07/2014, à 17:26

Exact Postmortem, je n'y avais pas pensé… Au pire, pour utiliser l'option -i, par exemple

\rm -i --

Brunod · Le 14/07/2014, à 18:20

Postmortem a écrit :

Je ne comprends pas ton raisonnement Brunod. "--" est justement là pour marquer la fin des options et donc éviter qu'un fichier ou tout autre argument soit pris pour une option. C'est exactement ce qu'il faut utiliser pour éviter les problèmes décrits dans les articles ci-dessus.

Parce que chaque fois qu'une commande rencontre un fichier dont le nom commence par "-", elle risque de le prendre pour un argument. Or modifier ou surveiller toutes les commandes, ainsi et surtout que leurs paramètres, en ligne ou dans les scripts n'est pas possible, je préférerais donc surveiller les fichiers pour voir si ils n'ont pas ce caractère pour débuter.

Postmortem a écrit :

Si on ne maîtrise pas les noms de fichiers sur lesquels on intervient, il suffit de prendre l'habitude de l'utiliser. Et d'ailleurs, au vu des exemples donnés, je vais l'utiliser plus souvent !

Effectivement, c'est une solution, mais je préfère partir sur l'idée de contrôler les fichiers.

Juste pour tester l'importance du problème, sur mon système un petit

sudo find / -name '-*'|wc

me donne
23 138 3828.

Postmortem · Le 14/07/2014, à 18:44

Moi je ne vois pas pourquoi on empêcherait l'utilisateur de mettre - au début d'un nom de fichier.
Je pense que c'est au programme de bien gérer ça, au même titre qu'un programme ne doit pas être gêner par des noms de fichier contenant espace ou n'importe quoi.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 12/07/2014, à 18:41

fonctionnement de * et detournement commandes

#2 Le 13/07/2014, à 08:29

Re : fonctionnement de * et detournement commandes

#3 Le 13/07/2014, à 08:42

Re : fonctionnement de * et detournement commandes

#4 Le 13/07/2014, à 08:44

Re : fonctionnement de * et detournement commandes

#5 Le 13/07/2014, à 10:44

Re : fonctionnement de * et detournement commandes

#6 Le 13/07/2014, à 11:20

Re : fonctionnement de * et detournement commandes

#7 Le 13/07/2014, à 12:45

Re : fonctionnement de * et detournement commandes

#8 Le 13/07/2014, à 13:19

Re : fonctionnement de * et detournement commandes

#9 Le 13/07/2014, à 19:03

Re : fonctionnement de * et detournement commandes

#10 Le 13/07/2014, à 21:51

Re : fonctionnement de * et detournement commandes

#11 Le 13/07/2014, à 22:27

Re : fonctionnement de * et detournement commandes

#12 Le 13/07/2014, à 22:39

Re : fonctionnement de * et detournement commandes

#13 Le 13/07/2014, à 22:50

Re : fonctionnement de * et detournement commandes

#14 Le 14/07/2014, à 09:13

Re : fonctionnement de * et detournement commandes

#15 Le 14/07/2014, à 09:16

Re : fonctionnement de * et detournement commandes

#16 Le 14/07/2014, à 11:08

Re : fonctionnement de * et detournement commandes

#17 Le 14/07/2014, à 14:39

Re : fonctionnement de * et detournement commandes

#18 Le 14/07/2014, à 15:00

Re : fonctionnement de * et detournement commandes

#19 Le 14/07/2014, à 16:58

Re : fonctionnement de * et detournement commandes

#20 Le 14/07/2014, à 17:02

Re : fonctionnement de * et detournement commandes

#21 Le 14/07/2014, à 17:16

Re : fonctionnement de * et detournement commandes

#22 Le 14/07/2014, à 17:26

Re : fonctionnement de * et detournement commandes

#23 Le 14/07/2014, à 18:20

Re : fonctionnement de * et detournement commandes

#24 Le 14/07/2014, à 18:44

Re : fonctionnement de * et detournement commandes

Pied de page des forums