Supposons qu'il existe une porte dérobée (probablement involontaire).
Le /etc/passwd par défaut sur les stations de travail Sun du début des années 1990 comportait une entrée semblable à celle-ci :
games::0:0:games:/nopath:/bin/false
En d'autres termes, un compte nommé "jeux" sans mot de passe. Apparemment, le génie qui a eu cette idée n'avait aucune imagination et lui a attribué un uid et un gid de zéro (c'est-à-dire racine et roue). En général, c'était correct, car le répertoire personnel n'avait pas de sens et le shell était défini sur un programme qui se terminait toujours avec un échec. De plus, les paramètres par défaut pour tout accès par réseau - telnet, rlogin, rcp, ftp - ont été définis pour empêcher l'accès par tout uid de zéro. Il y avait une entrée passwd distincte pour root, avec un mot de passe, un répertoire personnel et un shell correctement définis.
Cela signifiait que si vous tentiez de vous connecter en tant que jeux, voici ce qui se passerait :
- La connexion en tant que jeux sur la console réussirait d'abord, mais générerait ensuite le
/bin/falseshell, qui se fermerait immédiatement. - Utiliser telnet ou rlogin refuserait carrément la connexion. Même s'il avait réussi, le
/bin/falseshell se fermerait immédiatement. - FTP et scp n'utilisent pas de shells, mais ils ont été configurés pour refuser l'accès à l'uid zéro, vous ne pouvez donc pas vous connecter de cette façon.
- Une connexion GUI démarrerait les services GUI par défaut, y compris un gestionnaire de fenêtres, un client d'horloge et un terminal. Ce dernier se fermerait immédiatement car son shell enfant se fermerait immédiatement. Vous obtiendrez donc un écran vide à l'exception d'une horloge. (Plus d'informations ci-dessous...)
- Si vous aviez vraiment pour vous connecter en tant que root, vous devez soit le faire à partir de la console, soit d'abord vous connecter/telnet en tant qu'autre utilisateur sur cette machine, puis
su root. Dans les deux cas, utilise la racinepasswdentrée plutôt que les jeuxpasswdentrée, et fonctionne donc comme root devrait fonctionner.
Ainsi, le compte de jeux semblait toujours échouer, à moins que vous ne vous connectiez à l'interface graphique. Dans ce cas, la seule chose qui apparaissait était l'horloge. Cependant, vous pouvez cliquer avec le bouton droit sur l'arrière-plan pour obtenir un menu racine, avec une liste de programmes fournie par l'usine que les utilisateurs personnaliseraient normalement pour eux-mêmes. (La personnalisation du menu ne fonctionnait pas pour le compte de jeux; je ne me souviens pas exactement pourquoi.) Vous pourriez essayer d'afficher plus de fenêtres de terminal, ce qui échouerait. Il y avait un jeu de puzzle (qui a peut-être été à l'origine du compte en premier lieu). Un autre choix était de se déconnecter. Et puis il y avait l'outil de débogage graphique, dbxtool .
dbxtool était une interface graphique pour le dbx débogueur symbolique, similaire au gdb d'aujourd'hui . Étant uid zéro, vous pouviez vous connecter à n'importe quel processus du système et le contrôler, même si cela n'était pas utile car les programmes fournis par Sun étaient compilés sans symboles. Vous pourriez lancer un shell, mais cela utiliserait votre SHELL variable d'environnement, qui était /bin/false . Cependant, vous pouvez également modifier les variables d'environnement ! Cela signifiait que vous pouviez obtenir un shell root en procédant comme suit :
- Connectez-vous via l'interface graphique en tant que jeux, sans mot de passe.
- Cliquez avec le bouton droit pour afficher le menu racine.
- Démarrer un
dbxtool. setenv SHELL /bin/sh- (Facultatif)
setenv HOME / - Démarrer un shell avec
! - Parce que le terminal n'est pas configuré, faites
stty sane
Voila, root shell sans mot de passe !
Donc, ne présumez pas qu'un utilisateur ne peut pas sortir d'un shell invalide.
Vous ne pouvez pas ignorer l'exécution du script. Ceci est votre shell de connexion , et sera lancé à chaque fois que vous vous connecterez. Et en tant que shell de connexion , vous déconnectera à chaque fois qu'il se terminera. Mais vous pouvez utiliser des bizarreries, des bogues et des incohérences sur le shell de connexion pour vous échapper.
Une chose que vous pouvez faire est de vous échapper vers un shell en utilisant n'importe quelle option du menu. Si le menu vous permet de démarrer vim , less , more ou d'autres commandes, vous pouvez théoriquement vous libérer. Si l'administrateur système est expérimenté, ces commandes utiliseront leurs versions restreintes et ne fonctionneront pas.
Je me souviens d'un défi de wargame où il y avait un cas similaire - le shell pointait vers quelque chose qui imprimait simplement une sortie en utilisant le plus commande, puis a mis fin à la session. Cependant, depuis plus dispose d'un éditeur de texte intégré (dans ce cas particulier, c'était vi), il suffisait de redimensionner la fenêtre du terminal à partir de laquelle vous vous connectiez pour que plus soit activé, puis de l'utiliser pour échapper au shell.
Donc, la réponse dépend de ce que fait votre script. Vérifiez l'homme pages pour chacune des commandes que vous exécutez pour éviter une vulnérabilité.