Le shell di bash dovrebbero essere sostituite con la nuova versione con patch? [duplicare]


-2

Questa domanda ha già una risposta qui:

Questa domanda ha generato un sacco di downvoting su tre siti di SE, quindi lasciatemi provare a spiegare da dove proviene.

La magnitudo del problema "shellshock" di bash potrebbe risultare più grande di qualsiasi altra da quando Y2K.

Essendo stato parte di una sostituzione completa di un grande data center per Y2K, sono allarmato dal panico generato su shellshock (nome appropo, btw). Sono preoccupato che affrettare correzioni veloci senza una pianificazione e test approfonditi creerà problemi molto più grandi di quello che pensiamo di dover affrontare.

Per Y2K, abbiamo appreso che le correzioni del codice data erano la parte facile.

La parte di produzione dei tempi di inattività enormemente complessa, soggetta a errori e non programmata stava scoprendo e correggendo / attenuando i guasti in altri software causati dalle correzioni. Alcuni di questi non sono stati scoperti fino a quando i nuovi sistemi non sono stati in produzione per mesi. Nonostante uno sforzo erculeo, alcuni hanno addirittura portato a cambiamenti nella politica organizzativa perché erano troppo dirompenti per essere risolti.

Non sto suggerendo che l'applicazione di patch di sicurezza sia sconsigliabile.

Tuttavia, solo in questo caso, ho notato una serie sospetta di eventi che culminano non solo in un'altra vulnerabilità di routine, ma che richiedono un massiccio aggiornamento dei sistemi che interessano praticamente ogni persona che utilizza un computer sul pianeta.

La vulnerabilità è reale. Ma c'è bisogno di un'azione istantanea?

È questa combinazione di fattori che mi fa riflettere ...

Un fatto...

Una cronologia ...

Ramificazioni ...

  • La "vulnerabilità" shellshock di Bash è stata una "caratteristica" di Bash per 22 anni. Ci penseresti in tutto quel tempo, in tutti quegli ambienti ad alta sicurezza che eseguono Unix o Linux, qualcuno si sarebbe preoccupato dell'abuso.
  • Ora, ogni installazione di Bash nel mondo sta per essere sostituita.
  • Sebbene Bash sia open source, poche persone si prendono il tempo per studiare il codice di programmi così grandi e complessi.
  • Bash è scritto in C, che supporta il codice del linguaggio assembly incorporato. Codice che ancora meno programmatori hanno le competenze per leggere.
  • Bash è scritto in C, che supporta facilmente il trattamento di qualsiasi blocco di binario, come qualcosa etichettato come dati o una piccola immagine, come codice.
  • Quindi, un programmatore esperto poteva nascondere il codice "backdoor" in bella vista, e probabilmente non sarebbe stato scoperto a meno che non causasse un errore di qualche tipo.

Il reclamo ...

" US-CERT consiglia agli utenti e agli amministratori di revisionare TA14-268A, Vulnerability Note VU # 252743 e Redhat Security Blog (link is external) per ulteriori dettagli e fare riferimento ai loro rispettivi fornitori di sistemi operativi basati su Linux o Unix per una patch appropriata . "

La domanda...

Le shell di bash dovrebbero essere sostituite con queste nuove versioni con patch?

RISORSE


Aggiornamento 2017-09-28

Dopo 3 anni, qualcuno in realtà ha trovato una scheggia di utilità in questo e ha fatto salire la domanda?

Bene, lasciami un mea culpa ...

L'attenzione di cui sopra sulle circostanze che circondano l'annuncio di Shellshock sono state una reazione istintiva da parte mia. Una reazione mi dispiace. Mentre il fatto, il tono "cospirativo" ha prodotto una reazione che ha oscurato qualche cosa di valore. Lo lascio intatto solo in modo che i molti buoni commenti abbiano un senso.

Sono già state rilasciate e sono state messe a punto abbastanza nuove versioni della maggior parte del software coinvolto, che Shellshock potrebbe ancora preoccupare solo coloro che utilizzano sistemi a bassa potenza che devono utilizzare software meno recenti. All'epoca, il mio allarme riguardava i pericoli di rimuovere ciecamente funzionalità di 22 anni da quei sistemi senza analisi dell'impatto. Apparentemente, si scopre che la funzionalità è stata usata raramente, se non mai.


1
Sì, se stai utilizzando un server & amp; senti che sei a rischio. No se stai usando Mac OS X come client. E questo è ben trattato su questo sito. Per farla breve: se non hai idea di come compilare dal sorgente o trattare con componenti di sistema profondi, sarai tu stesso il più grande rischio a causa del bash problema tecnico. apple.stackexchange.com/questions/146893/...
JakeGould

Ho appena riletto il tuo post. Quindi stai sostanzialmente affermando che nessuno dovrebbe fidarsi di nessun aggiornamento quindi non applicare patch e & amp; Questo è quanto?
JakeGould

@Jake, mi dispiace, ho dimenticato di rispondere Si prega di vedere le modifiche della notte scorsa.
DocSalvager

Risposte:


2

Si, dovresti. Anche nel peggiore dei casi, stai scambiando una versione sfruttabile di un programma per uno che è teoricamente sfruttabile solo da chiunque abbia creato una potenziale porta sul retro.

Molte persone conoscono il problema attuale e possono usarlo contro di te in questo momento, ma presumibilmente poche persone conoscono questa ipotetica porta sul retro che potrebbe non esistere nemmeno.

La decisione mi sembra facile ... almeno se ti riferisci alla patch ufficiale rilasciata dal fornitore del tuo sistema operativo. Per quanto riguarda le patch di terze parti, si tratta di una questione di fiducia.

Personalmente, applicherò le patch, ma aspetterò Apple, o almeno un repository attendibile (Homebrew ecc.) Per rilasciare una versione di bash della serie 3.2 con la correzione.


1
Se utilizzi un client Mac OS X, le probabilità che questo si ripercuota su di te sono praticamente nulle. Maggiori dettagli qui. apple.stackexchange.com/questions/146893/...
JakeGould

Anche se le probabilità sono ridotte, in genere si desidera correggere le vulnerabilità della sicurezza. L'altro post, ad esempio, si concentra sullo sfruttamento diretto da sistemi esterni. Ma per quanto riguarda l'escalation dei privilegi? Sei assolutamente positivo sul fatto che non ci siano eseguibili setuid sul tuo sistema che eseguono qualcosa tramite bash in un modo che consenta di influenzare le loro variabili di ambiente in modo malevolo?
Scott Dudley

1
@TraneFrancks L'unica cosa valida sulla domanda originale qui specificamente è che questo potenziale "exploit" è in circolazione da 22 anni. Puoi indicare un'istanza in cui qualcosa di simile a questa sicurezza compromessa? Se accendo la condivisione web sul mio desktop, quella in & amp; di per sé non sarà vulnerabile. Le più moderne installazioni di Apache non usano lo scripting CGI. E questa è la debolezza. Quindi, semplicemente abilitare la condivisione web non ti renderà un bersaglio. Sostengo la mia affermazione che questo è tutto panico con poca realtà tangibile per sostenerlo.
JakeGould

1
@TraneFrancks Il migliore, ragionevole, razionale e amp; spiegazione succinta dell'impatto di questo difetto può essere trovato qui . E se sai qualcosa su come funzionano i server web e su come il rischio Apache sia davvero inesistente nei moderni server Linux, allora questo è un enorme problema. E questo è da RedHat! La gente che l'ha scoperto. Tutti i miei server Linux sono corretti. I miei server Mac non fanno nulla per innescare bash a qualsiasi livello. E i miei clienti Mac sono solo clienti. Mi sento bene.
JakeGould

1
"e come il rischio Apache sia davvero inesistente nei moderni server Linux" Ovviamente non si esegue un server condiviso cPanel su cui "CGI Center" è una funzionalità prevista dagli utenti orientati al Web 1.0. (Gestisco una società di hosting.) I miei server CentOS sono corretti e non vulnerabili. Onestamente, non so perché pensi che io non stia bene. Mi sento meraviglioso Per quanto riguarda il non-problema di RH: "A causa dell'uso pervasivo della shell Bash, questo problema è abbastanza serio e dovrebbe essere trattato come tale." Da qui: access.redhat.com/articles/1200223
Trane Francks
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.