Quels sont les problèmes de sécurité et les conditions de concurrence dans l'utilisation de «find -exec»?


14

Depuis la findpage de manuel :

-exec command ;
    There are unavoidable security problems
    surrounding use of the -exec action; you should use the
    -execdir option instead.

-execdir command {} +
    Like -exec, but the specified command is run from the
    subdirectory containing the matched file, which is not
    normally the directory in which you started find.  This a much
    more secure method for invoking commands, as it avoids race
    conditions during resolution of the paths to the matched
    files.

Qu'est-ce que ça veut dire? Pourquoi y a-t-il des conditions de concurrence avec son exécution à partir du répertoire de départ? Et comment sont ces risques de sécurité?


En relation: Pourquoi le bouclage sur la sortie de find est-il une mauvaise pratique? où cela est couvert dans certaines des réponses.
Stéphane Chazelas

Réponses:


13

Trouvé les détails ici :

L' -execaction entraîne l'exécution d'un autre programme. Il transmet au programme le nom du fichier qui est envisagé à l'époque. Le programme appelé effectuera généralement une action sur ce fichier. Encore une fois, il existe une condition de concurrence qui peut être exploitée ici. Nous prendrons comme exemple spécifique la commande

 find /tmp -path /tmp/umsp/passwd -exec /bin/rm

Dans cet exemple simple, nous identifions un seul fichier à supprimer et invoquons /bin/rmpour le supprimer. Un problème existe car il existe un intervalle de temps entre le moment où find décide qu'il doit traiter l' -execaction et le moment où la /bin/rmcommande émet réellement l'appel système unlink () pour supprimer le fichier du système de fichiers. Au cours de cette période, un attaquant peut renommer le /tmp/umsp répertoire en le remplaçant par un lien symbolique vers /etc. Il n'y a aucun moyen /bin/rmde déterminer qu'il fonctionne sur le même fichier que find avait en tête. Une fois le lien symbolique en place, l'attaquant a persuadé find de provoquer la suppression du /etc/passwdfichier, ce qui n'est pas l'effet voulu par la commande qui a été effectivement invoquée.

Je ne sais pas dans quelle mesure quelqu'un pourrait jamais exploiter cela; mais je suppose qu'il y a la réponse!


Dans le cas ci - dessus, execdirserait d' abord chdir à /tmp/umspavant d' exécuter la commande, et ainsi théoriquement, le répertoire d'un attaquant re - lier aurait pas d' effet .. si l'édition de liens est passé après découverte « décide » d'évaluer , -execmais avant que la rmcommande peut faire son travail. Mais je me demande pourquoi cela ferait une différence: l'attaquant pourrait simplement faire le lien à nouveau après que l'utilisateur a décidé d'écrire la findcommande.
Otheus

1
@RuiFRibeiro Le lien n'est pas l'argument transmis à la commande, c'est un répertoire intermédiaire. /tmp/umspest un répertoire quand findil le voit, mais lors de son rmexécution, l'attaquant l'a changé en étant un lien symbolique vers /etc. /tmp/umsp/passwdest un fichier normal tout au long, mais pas le même.
Gilles 'SO- arrête d'être méchant'

2

Je crois que la raison pour laquelle -execc'est dangereux est parce que si l'utilisateur ne spécifiait pas le nom complet et le chemin d'accès au programme à exécuter, il exécuterait potentiellement le mauvais programme.

Exemple:

find /some/path -exec coolprogram

Dans /some/path, quelqu'un en a fait un autre coolprogram, et il télécharge toutes vos données vers un mauvais acteur.

Mais attendez, dites-vous, ne devez-vous pas l'exécuter comme ./coolprogram? Oui, mais certaines personnes l'ont fait PATH=.:/bin:whatever, qui exécuteront le programme dans le répertoire courant.

C'est probablement simplifié, mais je pense que cela pourrait être dangereux dans certains cas. J'ai dû résoudre un problème une fois où un octet zéro cpios'est retrouvé dans le mauvais répertoire. Cela a provoqué un plantage du programme car cpioil ne fonctionnait pas car il exécutait le fichier zéro octet dans le répertoire.


3
Ces risques ne sont pas isolés find -exec. Si vous avez mis .votre chemin, exécuter simplement coolprogramdans votre répertoire actuel est déjà dangereux, que vous le findfassiez ou non!
Danny Tuppeny

1
D'accord, mais il semble que -execdir surveille également la condition que j'ai mentionnée:The ‘-execdir’ action refuses to do anything if the current directory is included in the $PATH environment variable. This is necessary because ‘-execdir’ runs programs in the same directory in which it finds files – in general, such a directory might be writable by untrusted users. For similar reasons, ‘-execdir’ does not allow ‘{}’ to appear in the name of the command to be run.
Doug

Je suppose que la morale de l'histoire est celle d'avoir. sur votre chemin est également une mauvaise idée, c'est pourquoi je m'assure que ce n'est pas là.
Doug

Intéressant de savoir comment interdire le .chemin et {}la commande. Peut-être qu'à l'avenir, Linux interdira .complètement le chemin et les outils n'auront pas besoin d'implémenter leurs propres contrôles de sécurité! :)
Danny Tuppeny

1
Je pense que 90% du code que j'écris ne sert qu'à attraper les 5% des choses qui tournent mal. :)
Doug
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.