Est-il sûr de laisser un shell racine en cours d'exécution dans une session d'écran détachée?

Je suis curieux de savoir s'il est possible de laisser un shell racine s'exécuter dans une session d'écran détachée. Je ne fais généralement jamais ça.

Mis à part le risque que mon compte d'utilisateur non root soit compromis (mot de passe exposé, clé ssh compromise, etc.), existe-t-il d'autres vecteurs d'entrée dans une session d'écran détachée et protégée par mot de passe dont je devrais m'inquiéter, ou un écran détaché peut-il être être considérée comme inerte?

Je pense que c'est un problème de sécurité, car «outre le potentiel de compromission de mon compte utilisateur non root» peut être assez important.

Mais il existe d'autres risques accrus au-delà de cela. Par exemple, vous vous êtes maintenant ouvert à un exploit théorique qui permet de modifier les autorisations dans le répertoire socket de l'écran ( /var/run/screensur mon système, mais /tmpest parfois utilisé). Cet exploit a maintenant un chemin pour obtenir root, ce qui pourrait ne pas être le cas autrement.

sudoa d'autres avantages, si vous pouvez vous entraîner à l'utiliser pour chaque commande plutôt que de le faire sudo su -. Il enregistre les actions (qui, à moins que vous ne vous connectiez à distance, n'augmentent pas significativement la sécurité, mais vous donnent une trace de ce que vous avez fait). Et il aide à prévenir les accidents en exigeant une escalade intentionnelle pour chaque commande, plutôt que de passer à une session entièrement privilégiée.

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 screenexé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␛ldans le flux d'entrée du shell. \ekest 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[21toblige 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 ; tdans 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.

Les tuyaux créés par l'écran ne sont accessibles que par le propriétaire, cela ne devrait donc pas être un problème de sécurité.