Si vous avez un shell racine dans une session écran (détaché ou non, protégé par mot de passe ou non) et que votre screen
exécutable n'est pas setxid, un attaquant qui obtient vos privilèges peut exécuter des commandes dans ce shell. Si rien d'autre, ils peuvent le faire en traçant le processus d'écran.
Si screen est setuid ou setgid, et que la session est détachée et protégée par mot de passe, il faut en principe le mot de passe d'écran pour exécuter les commandes dans ce shell. Si ce principe se vérifie, quelqu'un qui aurait seulement compromis votre compte devrait mettre un cheval de Troie en place et attendre que vous tapiez le mot de passe. Cependant, la surface d'attaque (c'est-à-dire le nombre d'endroits où les choses peuvent mal tourner en raison d'un bug ou d'une mauvaise configuration) est inconfortablement grande. En plus des fonctions de sécurité de base du système, vous faites confiance:
- écran pour obtenir le bon mot de passe.
- écran pour empêcher l'accès à la session par d'autres moyens.
- écran pour utiliser correctement les mécanismes de contrôle d'accès du système d'exploitation (par exemple, les autorisations sur les tuyaux).
- le noyau pour effectuer correctement les vérifications de sécurité de ptrace (c'est une source fréquente de vulnérabilités).
- le shell en cours d'exécution pour ne rien faire de stupide.
- une autre caractéristique pour ne pas vous mordre.
"Une autre fonctionnalité pour ne pas vous mordre": oui, c'est vague. Mais c'est toujours un problème de sécurité. Vous pourriez être tenté de rejeter cela comme un simple vœu pieux, mais avez-vous vraiment pensé à tout? Par exemple…
Tant que vous pouvez écrire sur le terminal, vous pouvez injecter des données dans l'entrée de ce shell. Sous la configuration par défaut de l'écran sur ma machine:
printf '\ekfoo\017bar\e\\' >/dev/pts/33
printf '\e[21t' >/dev/pts/33
Cela s'insère ␛]lfoobar␛l
dans le flux d'entrée du shell. \ek
est la séquence de contrôle qui permet à une application (ou à tout ce qui peut écrire sur le terminal) de définir le titre de la fenêtre (voir la section «Nommer les fenêtres» dans le manuel de l'écran ), et \e[21t
oblige le terminal à signaler son titre sur l'entrée standard de l'application ( screen ne documente pas cette séquence, mais l'implémente; vous pouvez la trouver sous CSI Ps ; Ps ; Ps ; t
dans la liste des séquences de contrôle xterm . En fait, au moins sous l'écran 4.0.3, tous les caractères de contrôle sont supprimés du titre rapporté, donc le shell lit lfoobar
(en supposant qu'il ␛]
n'est pas lié à une commande d'édition) et pas de nouvelle ligne. L'attaquant ne peut donc pas réellement exécuter une commande de cette façon, mais peut bourrer une commande commechmod u+s /bin/sh
suivi de beaucoup d'espaces et d'une invite qui semble probable.
Screen implémente plusieurs autres séquences de contrôle risquées similaires, je ne sais pas quelle est leur potentialité pour les vulnérabilités. Mais j'espère que vous pouvez maintenant voir que la protection offerte par les mots de passe de session d'écran n'est pas si grande. Un outil de sécurité dédié tel que sudo est beaucoup moins susceptible d'avoir des vulnérabilités.
sudo
.