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


20

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?


Ce n'est pas une réponse parce que je ne le sais pas, mais je ne pense pas que cela fasse une différence entre faire comme vous l'avez dit et quitter le travail sudo.
phunehehe

7
@phunehehe Il y a une différence car lorsqu'un travail se termine, il se sudodésactive alors qu'un véritable shell racine reste ouvert.
Michael

Réponses:


5

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.


1
Bien qu'aucun exploit de ce type ne soit connu à présent, je vais continuer à ne pas laisser les root shell ouverts à l'écran. Les risques pour le compte utilisateur sont suffisants tels quels. Merci.
Michael

-1 Si j'ai un exploit qui peut changer les permissions des fichiers, je n'ai pas besoin de pirater un écran en cours d'exécution. Je peux faire ce que je veux avec le système.
Let_Me_Be

@Let_Me_Be - cela dépend de qui les autorisations de fichiers votre exploit vous permet de changer. Peut-être que vous ne pouvez faire que quelques choses spécifiques sous certaines hiérarchies. Ce n'est pas si farfelu.
mattdm

L'écran lui-même a une grande surface d'attaque. Je n'ai pas d'attaque complète à montrer , mais il y a clairement des faiblesses.
Gilles 'SO- arrête d'être méchant'

corrigez-moi si je me trompe, mais l'application d'écran est interfacée via une session shell (soit directement sur la console système, soit via une session ssh). pour autant que je sache, ce n'est pas un protocole de mise en réseau en tant que tel. il est donc aussi sécurisé que votre session ssh ou session de terminal. si certains ont accès à la session ssh ou à votre machine physique, tous les paris sont désactivés. s'ils ont suffisamment d'accès pour accéder à n'importe quelle sorte de ligne de commande sous n'importe quel compte d'utilisateur, vous pouvez tout aussi bien gâcher la sécurité de votre machine.
non synchronisé

10

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.


+1 Excellente réponse. Merci d'avoir pris le temps de tout expliquer.
Michael

1

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é.


5
Vous avez utilisé "sont" dans la première partie de votre phrase où vous vouliez probablement dire "devrait être". Ne prenons pas l'habitude de faire des hypothèses.
Shadur

1
Euh? Les tuyaux créés par l'écran SONT accessibles uniquement par le propriétaire (si vous ne les modifiez pas manuellement).
Let_Me_Be
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.