Supponiamo che ci sia una backdoor (probabilmente non intenzionale).
Il /etc/passwd
predefinito sulle workstation Sun dei primi anni '90 includeva una voce simile a questa:
games::0:0:games:/nopath:/bin/false
In altre parole, un account denominato "giochi" senza password. Apparentemente il genio che ha avuto questa idea non aveva immaginazione e gli ha assegnato un uid e un gid pari a zero (cioè radice e ruota). In generale, andava bene, poiché la home directory non aveva significato e la shell era impostata su un programma che terminava sempre con errori. Inoltre, le impostazioni predefinite per qualsiasi accesso tramite rete -- telnet, rlogin, rcp, ftp -- sono state impostate per impedire l'accesso da parte di qualsiasi uid pari a zero. C'era una voce passwd separata per root, con una password, una home directory e una shell impostate correttamente.
Ciò significava che se provavi ad accedere come giochi, accadeva quanto segue:
- L'accesso come giochi sulla console all'inizio avrebbe avuto esito positivo, ma poi avrebbe generato il
/bin/false
shell, che uscirà immediatamente. - L'uso di telnet o rlogin negherebbe completamente l'accesso. Anche se avesse avuto successo, il
/bin/false
shell si chiuderebbe immediatamente. - FTP e scp non usano shell, ma sono stati configurati per negare l'accesso a uid zero, quindi non puoi accedere in questo modo.
- Un login alla GUI avvierebbe i servizi della GUI di default, inclusi un window manager, un clock client e un terminale. Quest'ultimo uscirà immediatamente perché la sua shell figlia uscirà immediatamente. Quindi otterresti uno schermo vuoto ad eccezione di un orologio. (Maggiori informazioni di seguito...)
- Se davvero avessi per accedere come root, dovresti farlo dalla console, o prima rlogin/telnet come un altro utente su quella macchina e poi
su root
. In entrambi i casi utilizza la radicepasswd
ingresso piuttosto che i giochipasswd
entry, e quindi funziona nel modo in cui dovrebbe funzionare root.
Quindi l'account di gioco sembra fallire sempre, a meno che tu non abbia effettuato un accesso alla GUI. In quel caso, l'unica cosa che appariva era l'orologio. Tuttavia, è possibile fare clic con il pulsante destro del mouse sullo sfondo per ottenere un menu principale, con un elenco di programmi fornito in fabbrica che gli utenti normalmente personalizzerebbero per se stessi. (La personalizzazione del menu non ha funzionato per l'account di gioco; non ricordo esattamente perché.) Potresti provare a visualizzare più finestre di terminale, il che fallirebbe. C'era un puzzle game (che potrebbe essere stato l'impulso per l'account in primo luogo). Un'altra scelta era disconnettersi. E poi c'era lo strumento di debug grafico, dbxtool
.
dbxtool
era un'interfaccia grafica per dbx
debugger simbolico, simile al gdb
di oggi . Essendo uid zero, potevi collegarti e controllare qualsiasi processo sul sistema, anche se questo non era utile perché i programmi forniti da Sun erano compilati senza simboli. Potresti lanciare una shell, ma questo userebbe il tuo SHELL
variabile di ambiente, che era /bin/false
. Tuttavia, potresti anche modificare le variabili ambientali! Ciò significava che potevi ottenere una shell di root come segue:
- Accedi tramite la GUI come giochi, senza password.
- Fai clic con il pulsante destro del mouse per visualizzare il menu principale.
- Inizia un
dbxtool
. setenv SHELL /bin/sh
- (Facoltativo)
setenv HOME /
- Avvia una shell con
!
- Poiché il terminale non è impostato, esegui
stty sane
Voilà, root shell senza password!
Quindi, non dare per scontato che un utente non possa uscire da una shell non valida.
Non è possibile ignorare l'esecuzione dello script. Questa è la tua shell di login , e verrà avviato ogni volta che accedi. E come shell di login , ti disconnetterà ogni volta che finisce. Ma puoi usare stranezze, bug e incoerenze sulla shell di login per scappare.
Una cosa che potresti fare è scappare in una shell usando qualsiasi opzione nel menu. Se il menu ti consente di avviare vim
, less
, more
o altri comandi, puoi teoricamente liberarti. Se l'amministratore di sistema è esperto, quei comandi utilizzeranno le loro versioni limitate e non funzioneranno.
Ricordo una sfida di wargame in cui c'era un caso simile:la shell indicava qualcosa che stampava semplicemente un output usando more comando, quindi ha terminato la sessione. Tuttavia, poiché more dispone di un editor di testo integrato (in questo caso particolare era vi), bastava ridimensionare la finestra del terminale da cui ci si connetteva in modo che ne venisse attivato altro, quindi usarlo per uscire dalla shell.
Quindi, la risposta dipende da cosa fa il tuo script. Controlla l'uomo pagine per ciascuno dei comandi che stai eseguendo per evitare una vulnerabilità.