Existe-t-il un moyen pour un attaquant d'utiliser mkdir pour compromettre un système?

Je configure un compte utilisateur restreint pour l'utilisateur ricardo, un utilisateur gênant sur mon système. Je veux lui accorder le droit de créer des répertoires en utilisant sudo, ce qu'il doit parfois faire. J'envisage cette règle dans mon /etc/sudoersdossier:

ricardo   ALL=(root) NOPASSWD: /bin/mkdir

En utilisant uniquement cette règle, y a-t-il un moyen pour ricardo de compromettre intentionnellement ou accidentellement le système?

Je soupçonne qu'une attaque comme celle-ci fonctionnerait, où «quelque chose» est un module du noyau qui tentera de se charger après le montage de rootfs:

$ sudo mkdir -m 777 /lib/modules/`uname -r`/a
$ cp evil.ko /lib/modules/`uname -r`/a/«something».ko

Notez également que vous pouvez utiliser d'autres noms, en fonction des alias déclarés dans le module. Je suppose qu'il ne sera pas chargé jusqu'à ce que depmod soit exécuté, ce qui se produira la prochaine fois qu'il y aura une mise à jour du noyau - donc mkdiril ne s'affichera même pas récemment dans le journal sudo.

Il y a beaucoup de choses dans / etc qui lisent tous les fichiers d'un répertoire, parfois récursivement. Pire encore, certains de ces répertoires n'existent pas par défaut, et la seule façon de les connaître est de lire la page de manuel, les scripts d'initialisation, etc. pour le programme qui les utilise. Certains, pire encore, sont obsolètes et ne peuvent même plus être documentés.

edit: Pensé à quelques autres répertoires, ceux-ci dans /usr/local:

• /usr/local/lib/perl/5.14.2(diffère selon la version de Perl, essayez perl -Vde le découvrir). Créez-y un Filesous - répertoire et mettez-y un Find.pm. Désormais, chaque fois que quelqu'un utilise File::Find, il utilise la version de l'attaquant. De même, faites de même avec Getopt::Long. Les utilitaires système sont souvent écrits en Perl, donc cela donne probablement racine. (Essayez ack-grep --color -a 'use.+::' /usr/sbin | less -R)
• Je pense que Python, Ruby, etc. ont des répertoires similaires. Les utilitaires système sont également écrits en Python.
• Subvertissez beaucoup de choses que quelqu'un compile avec des sous-répertoires de /usr/local/include.

En s'exécutant en mkdirtant que root, l'utilisateur peut empêcher d'autres processus / utilisateurs de créer de nouveaux fichiers et répertoires en créant des répertoires avec des noms identiques (et / ou des droits incorrects) auparavant.

Cela pourrait être important pour la sécurité, en particulier avec les fichiers journaux et de verrouillage .

Comme l'a noté jordanm , le nombre maximal d' inodes peut également être utilisé, ce qui peut bloquer l'ensemble du système.

En ajoutant l'utilisateur à des groupes spécifiques (ou en utilisant des ACL ), vous devriez pouvoir résoudre les problèmes sans accorder de droits via sudo.

Vous devez le rediriger vers une prison chroot. Ou encore mieux, pour une petite VM, qu'il peut planter une fois par heure. Il vous suffit de fournir une nouvelle copie.

Il existe des possibilités grâce à la possibilité de créer des répertoires avec un accès en écriture. Avec mkdir -m 777 blahl' ricardoutilisateur peut écrire tout ce qu'ils veulent dans le nouveau répertoire. Vous auriez besoin d'un processus sur le système fonctionnant déjà en tant qu'utilisateur différent qui recursera dans une arborescence de répertoires pour charger la configuration, les scripts ou les modules. Ensuite, l'utilisateur pourrait éventuellement ajouter ses propres éléments à charger ou à exécuter. La première chose à laquelle je peux penser, c'est si vous exécutez un serveur Web qui peut exécuter php ou cgi. Vous pouvez ensuite exécuter des scripts en tant que cet utilisateur. J'ai du mal à trouver des exemples plus réels, en particulier rootceux, mais je suis sûr qu'ils sont sur le point.

ssh est un exemple de démon qui intercepte ce type de scénario. Si vous avez créé un .sshrépertoire pour un utilisateur qui n'en avait pas et mettez votre propre authorized_hostsfichier en place. sshdremarque que les autorisations des répertoires sont trop ouvertes et ignore la clé publique.

Vous pourriez certainement vous ennuyer en créant des répertoires où des fichiers devraient apparaître (comme des fichiers tmp transitoires ou des fichiers d'échange) que beaucoup de programmes ne géreraient pas bien.

Vous pouvez créer de nombreux groupes de contrôle, mais il ne semble pas que vous en fassiez quoi que ce soit. Vous pourriez peut-être mettre un système à genoux au moins. Il a fallu environ 10000 cgroups sur une boîte avec 256M pour que le tueur OOM retire sshd.

Si vous contrôlez l' -moption mkdiret l'UMASK de l' sudoenvironnement, je pense que c'est redevenu une nuisance.