Sostituire bash con un'altra shell è un passo prudente?

Per determinare in modo definitivo il grado in cui questo potrebbe o potrebbe non essere "un passo prudente", penso che dovresti fare qualche ricerca di sicurezza originale sulle possibili sostituzioni, che includono:

• trattino di Debian
• Ksh di OpenBSD
• Busybox ash
• MirBSD / MirOS mksh
• ... e sicuramente altri

La risposta di Mark suggerisce che almeno OpenBSD ha già ricevuto un controllo di sicurezza, ma non sono sicuro della portata o se ci sono prove a sostegno di ciò (chiaramente, non hanno applicato alcun controllo a una pietra miliare della sicurezza delle comunicazioni (OpenSSL ) fino a poco tempo fa quando lo hanno biforcato in LibreSSL). D'altra parte, è abbastanza chiaro per me che nessuno si è preso la briga di leggere la fonte di Bash per sicurezza fino a poco tempo fa, o "shellshock" sarebbe stato scoperto molto tempo fa; l'intera cosa che "importa la funzione" è un'enorme bandiera rossa che ogni ricercatore di sicurezza esaminerebbe non appena l'hanno visto (e si spera che raccomandi l'intera funzionalità per la rimozione). Ma per gli altri, non è così chiaro.

Ciò che è chiaro, tuttavia, è che tutti i precedenti hanno una superficie di attacco molto più piccola di Bash. Affinché un utente malintenzionato possa assumere il controllo di un programma, deve esserci un canale di input. Ovviamente possono essere cose non ovvie come limiti di risorse, clock di sistema, ecc. Ma sono ancora input; un programma senza alcun input è banalmente non vulnerabile. Il bug di progettazione della sicurezza in Bash è che sta prendendo input potenzialmente non attendibili (i contenuti di variabili di ambiente arbitrarie) e li sottopone ad elaborazione complicata (analisi come codice). D'altra parte, per quanto ne sappia, nessuna delle shell sopra elencate esegue alcuna elaborazione dei contenuti delle variabili di ambiente (eccetto quelle individuali con significato stabilito specificato come LANG e LC_* , ENV , IFS , PATH , PS1 , ecc.) o altro input; semplicemente trattano i contenuti come dati astratti che sono passati attraverso.

Quindi, dal punto di vista della progettazione della sicurezza, anche senza audire queste alternative, stimerei che fossero scelte più sicure di Bash. Se questo rimarrà il caso non è chiaro. Certamente Bash sta ricevendo molta nuova attenzione in questo momento, che altre shell hanno meno probabilità di ricevere, quindi potremmo finire con la maggior parte dei problemi di Bash che vengono risolti mentre i problemi in altre shell rimangono sconosciuti. Quindi devi considerare vari fattori, ad esempio se è probabile che tu scelga di mirare individualmente, nel qual caso utilizzare software meno mainstream potrebbe essere una responsabilità.

Personalmente, uso Busybox nella maggior parte dei casi. Se non altro, sia cenere che cruscotto usano circa 1/5 della memoria di bash e si avviano 2-8 volte più velocemente, quindi sono scelte molto pratiche anche da un punto di vista non di sicurezza.

L'unica shell che conosco è stata seriamente ispezionata per problemi di sicurezza è la variante di OpenBSD di ksh , e non so se può essere installata su un sistema Linux. Oltre a questo, l'unico vantaggio in termini di sicurezza nel cambiare la shell del tuo sistema è che usando una shell meno comune, meno persone ti bersagliano, ma per lo stesso motivo, meno persone cercheranno bug nella shell scelta. / p>

Debian / Ubuntu ha evitato la maggior parte del problema perché avevano dash come shell di sistema e le distribuzioni di router WRT * hanno utilizzato busybox , ma nessuna delle due ha selezionato la shell per ragioni di sicurezza. In entrambi i casi, la shell alternativa è stata selezionata per migliorare le prestazioni riducendo i tempi di caricamento e il footprint della memoria.

È un po 'ridicolo reagire a una vulnerabilità che si trova in un prodotto sostituendola con un'altra. Vedi il classico problema dell'indagine sulla sopravvivenza dei bombardieri WW2 per il motivo. In sostanza, stai reagendo a un incidente raro e improbabile come se fosse una prova definitiva della sicurezza di Bash rispetto a quella di altre shell.

Ricorda che gli exploit visibili non dicono assolutamente nulla sul numero di non rivelati e sul numero di vulnerabilità esistenti nel software. Potrebbe essere che Bash è pieno di bug o potrebbe essere che dopo essere andato sotto esame è completamente privo di vulnerabilità. Il problema è che nessuno è in grado di avanzare alcuna rivendicazione fino a quando tutti il codice di tutti le shell sono state esaminate a fondo o ancora meglio dimostrate corrette.

Sarebbe meglio con le metriche sulla qualità del codice scritto da ciascun progetto e sulla sua capacità di rilevare e correggere i bug e di rispondere agli incidenti critici piuttosto che speculare su una manciata di vulnerabilità.

Debian e Ubuntu lo fanno già usando dash invece di bash per /bin/sh . Ovviamente, questo sostituisce una base di codice meno ispezionata in una parte chiave dell'infrastruttura di sistema, quindi è una possibilità distinta che abbia vulnerabilità sconosciute con uguale impatto sui recenti problemi di bash .

Qualsiasi cosa tu faccia su questa vulnerabilità dovrebbe essere basata su un'analisi dei potenziali vettori potenziali di rischio. Il solo utilizzo della shell come shell interattiva, per essere estremi, non comporta alcun rischio da questo bug.

Il bug esiste solo quando alcuni programmi consentono a una parte ostile di controllare il contenuto delle variabili di ambiente come visto da un'invocazione della shell. Ad esempio, un server Web che imposta una variabile di ambiente sul valore dell'intestazione dell'agente utente da una richiesta e non la disinfetta. Se si esegue tale servizio, è logico, con o senza questo bug, utilizzare la shell più semplice possibile. Meno c'è il guscio, meno posti ci potrebbero essere esposizioni di sicurezza. Certo, sarebbe meglio se il server web fosse in esecuzione in un carcere che ha sollevato tutta questa domanda. Quindi, se devi eseguire un server web o qualcosa del genere che lancia shells in ambienti non-sandbox, ridurre la tua esposizione eseguendo la shell più semplice disponibile ha senso.