I Mac sono vulnerabili al bug dello shellshock di Bash?


58

Red Hat ha recentemente annunciato un importante bug relativo alla sicurezza nella shell Bash. Alcuni lo chiamano bug "shellshock". Poiché OS X è basato su Unix, è vulnerabile agli attacchi che sfruttano questo bug?

Come utente finale, devo preoccuparmi di una soluzione immediata? O è meglio per me aspettare un aggiornamento software ufficiale da Apple?



Per sapere quali azioni influenzano OSX, vedere security.stackexchange.com/questions/68123/…
user151019

Aggiornato la domanda in modo che sia meno un duplicato e più una richiesta di consulenza per i non addetti ai lavori.
motoscafo

1
Apple ha rilasciato una correzione ora: support.apple.com/kb/DL1769
AL

Risposte:


46

Sì, sei tecnicamente vulnerabile. Quindi, se hai voglia di farti prendere dal panico o fatturare un cliente in preda al panico per qualche ora di panico, provaci!

Ma la realtà è che se non si consente l'accesso SSH da connessioni remote o un server Web che esegue scripting lato server, non si è a rischio. Sei veramente vulnerabile solo se qualcuno che non conosci può accedere in remoto al tuo computer e farlo in un modo in cui un comando Bash può essere eseguito.

Ciò significa che il tuo Mac desktop, che in realtà non esegue applicazioni server di alcun tipo, non corre alcun rischio serio. Sono disposto a mangiare qualche proverbiale "umile torta" qui, ma non credo che la maggior parte degli utenti Mac sarà a rischio alla fine della giornata.

Quindi questo problema riguarda principalmente gli amministratori di sistema su server Mac OS X e Unix / Linux esposti al mondo, non gli utenti desktop che non abilitano la condivisione SSH.

Forse c'è un rischio marginale di creare un malware o un virus Mac per sfruttare questo rischio, ma ne dubito.

EDIT: E solo per elaborare come questo problema - a mio modesto parere - non sia realmente un problema per la maggior parte degli utenti medi, sì, posso eseguire il seguente comando da bashMac OS X 10.9.5:

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

E vedo questo:

vulnerable
hello

Indovina un po? Questo è terrificante solo se non lo pensi razionalmente. Dovevo già aver effettuato l'accesso al mio Mac per aprire anche il Terminale. E per negare ciò che ho detto su SSH sopra, per arrivare al punto in cui posso eseguire questo test anche se SSH è abilitato, dovrei comunque essere loggato per cominciare. E poi, diciamo che ottengo l'accesso tramite SSH, il comando non mi consente di fare NIENTE oltre i miei normali diritti utente come questo:

env x='() { :;}; echo vulnerable' bash -c 'cat /etc/ssh_host_rsa_key'

Significa che se sei veramente vulnerabile all'essere sfruttato da questo hack, la tua sicurezza di base sul sistema dovrebbe essere così compromessa che il fatto che bashha un difetto è davvero il minimo dei tuoi problemi.

Questa è una preoccupazione da un problema generale di controllo e diritti in quanto potenziale per consentire l'accesso non intenzionale poiché il comportamento si estende al di fuori delle norme previste. Ma a mio modesto parere, non è un rischio alla pari di OpenSSL o della varietà del giardino "lasciami la mia password su una nota registrata sul mio schermo".

Alla fine della giornata continuo a correggere tutti i miei server Linux / Unix che eseguo come procedura standard. E sarà felice di patchare i Mac che gestisco una volta che è stata risolta una correzione. Ma per un uso quotidiano pratico, mi sento bene a non preoccuparmene, dal momento che non capisco come un difetto che non consenta privilegi utente elevati si sommi a tutto.

AGGIORNAMENTO: la parola ufficiale di Apple pubblicata qui ; enfasi mia:

"La stragrande maggioranza degli utenti di OS X non è a rischio di vulnerabilità di base recentemente segnalate", ha detto un portavoce di Apple a iMore. "Bash, una shell di comando UNIX e un linguaggio incluso in OS X, ha un punto debole che potrebbe consentire agli utenti non autorizzati di ottenere in remoto controllo dei sistemi vulnerabili. Con OS X, i sistemi sono sicuri per impostazione predefinita e non esposti a exploit remoti di bash a meno che gli utenti non configurino servizi UNIX avanzati. Stiamo lavorando per fornire rapidamente un aggiornamento software per i nostri utenti UNIX avanzati. "

Traduzione: Cosa ho detto sopra riguardo al fatto che si tratta di un problema del server e non di un problema del client? Esattamente.

A UDPATE FINALE: per chiunque abbia difficoltà a compilare dalla fonte, a partire dal 29 settembre, Apple ha rilasciato ufficialmente patch per Mac OS X 10.9.5, 10.8.5 e 10.7.5:

ANCORA UN ALTRO AGGIORNAMENTO FINALE: E ora Apple ha appena rilasciato un aggiornamento di sicurezza combinato che include anche l' bashaggiornamento !

Nota: l'aggiornamento per la protezione 2014-005 include il contenuto di sicurezza dell'aggiornamento 1.0 per OS X bash


7
"o un server Web che esegue scripting lato server" - oppure ha un'applicazione in esecuzione, in ascolto su una porta aperta che consente di effettuare chiamate RPC che finiscono per eseguire comandi shell. Questo potrebbe essere un numero qualsiasi di cose in quanto ci sono molte applicazioni standard che fanno il loro RPC. Penso che questa risposta sia molto ingenua. È molto semplice "eseguire inavvertitamente un server Web" nel corso dell'esecuzione di un'applicazione che esegue operazioni di tipo client-server.
Ian C.

3
@IanC. Puoi fornire un esempio in cui OS X pronto all'uso sarebbe veramente vulnerabile? Ad esempio qualcosa come WebEx o GotoMeeting potrebbe avvicinarsi alle funzionalità di Bash? Il punto è che non riesco a pensare a un semplice scenario di installazione di OS X che esponga veramente le cose. Puoi?
Jake Gould,

8
L'account guest non è disponibile per ssh. In effetti, non è nemmeno possibile renderlo disponibile a ssh, IIRC. Il fatto è che, per la stragrande maggioranza degli utenti di OS X, la vulnerabilità bash non è affatto un problema. Per quelli di noi in cui si tratta di un problema, dobbiamo ricompilare bash non appena è disponibile una correzione testata, ma non è ora.
lbutlr,

3
@IanC. Ok, buoni esempi. Ma ti manca ancora il punto: come si può sfruttare una tale vulnerabilità in ogni esempio che si sta fornendo? In ogni caso un utente avrebbe bisogno di accedere al sistema per cominciare e poi cosa? Non sono irriverente a riguardo, ma non riesco ancora a capire quale sia il rischio reale? Qualcuno, ad esempio, dovrebbe farsi strada attraverso l'API Plex per fare esattamente cosa bash per fare qualcosa al di fuori dei normali diritti utente e privilegi di accesso?
Jake Gould,

6
@danielAzuelos “Tutti sono vulnerabili fintanto che l'account ospite è aperto: [!” L'account ospite non ha nulla a che fare bash. Quindi la paura si basa esattamente su cosa? Inoltre, anche se l'account ospite è aperto e in qualche modo bashutilizzabile, allora? Da quello che vedo un'ipotesi, usare questo exploit non avrebbe privilegi elevati o qualcosa di simile. Seriamente, sono disposto a indietreggiare dalla mia posizione, ma questo sembra più un panico basato su non molto mentre OpenSSL era un vero problema.
Jake Gould,

37

Sì!

Digita questo nella tua shell

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

Se dice vulnerableallora sei vulnerabile.

Se dice

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello

allora sei bravo.

Modifica: collegamento alla correzione


4
Grazie. Ho aggiornato la domanda: se scopriamo di essere vulnerabili, come può risolverlo un utente Mac?
motoscafo

3
@abbyhairboat Ha pubblicato la mia risposta. A meno che non si stia eseguendo un server esposto al mondo esterno non vi è alcun rischio pratico. Gli amministratori del server sono quelli che devono preoccuparsi di questo.
Jake Gould il

1
→ abby: vedi questa risposta correlata: apple.stackexchange.com/a/146851/22003 .
dan

2
Prova questo env X="() { :;} ; echo busted" /bin/sh -c "echo completed"- Anche dopo aver patchato il mio sistema, questo tossisce "rotto" sulla riga di comando. Bah.
Trane Francks,

1
@Mark no, zsh è al sicuro. è necessario sostituire "bash -c" con "zsh -c" per testarlo.
Ismail,

3

Come utente finale , controlla che:

  • il tuo account ospite è spento:

    Preferenze di Sistema> Utenti e gruppi> Utente ospite
    
  • il tuo sshaccesso è disattivato:

    Preferenze di Sistema> Condivisione> Accesso remoto
    

Per impostazione predefinita, entrambi sono disattivati ​​su Mavericks.

Come utente finale , è più sicuro attendere un aggiornamento ufficiale di sicurezza di Apple che risolva questa bashvulnerabilità.


1
Questi sono irrilevanti. Ognuno di questi, per loro stessa natura, concede agli utenti l'accesso per eseguire comandi sul sistema, quindi se li hai abilitati, è tua intenzione consentire agli utenti di eseguire comandi. Il bug Shellshock è un mezzo per gli utenti per i quali non intendevi essere in grado di eseguire comandi per poterlo fare, ad esempio un utente del server web che esegui. Quindi, la tua risposta dovrebbe dire "Disabilita condivisione Web" (ma questa è solo una cosa da verificare)
Josh

Sono irritato che Apple non abbia consigliato di disattivare tali impostazioni. Chi li abiliterebbe? Vorrei. Sono un utente Mac dal 1986, uno sviluppatore di applicazioni web a tempo pieno (quindi ssh è la mia vita) e un papà (quindi un account Ospite per i bambini non è una cattiva idea). Conosco molte persone che sono come me in questi modi che usano laptop Apple. Vuoi perderci? Lasciare aperta questa vulnerabilità è un buon modo.
minopret,

2

Tutte le macchine Mac OS X sono tecnicamente vulnerabili a "Shellshock", fino a quando Apple non emette un aggiornamento di sicurezza che corregge bash, ma ...

La tua domanda dovrebbe essere: posso essere hackerato da remoto?

C'è così tanto software che usa bashdistrattamente che rispondere a questa domanda è estremamente difficile. Se sei preoccupato, suggerirei diverse modifiche System Preferencesper prevenire exploit remoti:

  • Disabilita TUTTI i servizi di condivisione in Preferenze di condivisione.
  • Abilita il firewall in Sicurezza e privacy.

Se sei particolarmente preoccupato, premi il Firewallpulsante Opzioni per:

  • Deseleziona Automatically allow signed software to receive incoming connections.
  • Controllare Block all incoming connections.

C'è ancora una buona probabilità che tu sia vulnerabile ad un attacco di livello usando DHCP, Bonjour, ecc., Ma hey se hai bisogno di un altro servizio, ovviamente puoi lasciarlo in esecuzione mentre speri che non venga sfruttato. E dovrai anche lasciare il firewall più aperto. Probabilmente andrà bene se la tua macchina vive dietro un altro firewall.

Inoltre, ci sono attacchi di escalation di privilegi locali abilitati da "Shellshock?" Sì, quasi sicuramente. Non mi preoccuperei però perché Mac OS X ha abbastanza attacchi simili. Apple non corregge rapidamente i bug dell'escalation dei privilegi locali. E Apple li crea frequentemente con i servizi abilitati per Apple Script. Supponi solo che tutte le macchine Mac OS X siano sempre vulnerabili agli attacchi locali. Se hai bisogno di partecipare a conferenze di hacker come DEFCON, acquista una scatola Linux a tale scopo.

Aggiornamento: ci sono istruzioni per ricompilare la tua bash fissa e anche altre domande trattate . Lo farò da solo, ma IMHO è eccessivo se non si esegue alcun server e si mantiene comunque attivo il firewall di Apple.

Aggiornamento: se hai dimestichezza con l'uso del terminale, c'è un programma chiamato execsnoopmenzionato qui che ti consentirà di verificare se bash viene solitamente chiamato dai processi del tuo server. Non è un proiettile magico poiché il processo del server potrebbe chiamare bash solo in situazioni insolite, ma ti darà una buona idea.

Infine, Apple non è molto brava a patchare le vulnerabilità di sicurezza, ma sono brave in PR, quindi questo verrà patchato relativamente velocemente. È quindi ragionevole pensare "Non ho bisogno di correre più veloce dell'orso, ho solo bisogno di correre più veloce del vasto numero di server facilmente sfruttabili su Internet". :)


2
Non è possibile che i Mac siano vulnerabili a un attacco tramite DHCP, poiché non utilizza Bash.

1
Come fai a saperlo? L'advisory iniziale era un client DHCP vulnerabile. E molti articoli ipotizzano che i client DHCP di Mac OS X e / o iOS potrebbero essere vulnerabili. Tutti i server dovrebbero essere considerati vulnerabili, salvo prova contraria.
Jeff Burdges,

1
No, non dovrebbero essere; questo è FUD assoluto. È possibile esaminare sia il codice open source per l'implementazione dhcp di OS X sia misurare autonomamente le chiamate di sistema per verificare.

3
@JeffBurdges, OS X non usa shell exec con DHCP dalla 10.3, e prima che bash non fosse installato sul sistema. DHCP su OS X non è un problema con Shellshock. (Una cosa in meno di cui preoccuparsi. :))
Trane Francks,

1
→ Jeff: per favore considera: strings /usr/libexec/bootpd | egrep '/bin|bash'e nm -a /usr/libexec/bootpd | egrep 'fork|exec'. Leggendo questi comandi in output su diverse versioni di MacOS X, potresti riconsiderare la tua analisi del rischio a causa di dhcpdMacOS X ... ma solo questa :(.
dan

2

Ho creato questo strumento non appena ho saputo di questa vulnerabilità. Ti fornirà un collegamento a un articolo per correggere la shell se lo strumento determina che sei vulnerabile.

Richiede Mac OS X 10.6 e versioni successive.


3
Forse sono solo io ... ma l'idea di eseguire il codice di una persona a caso per testare un exploit sembra un'idea davvero cattiva quando puoi incollare facilmente una stringa (che è chiaramente solo eseguendo il test e niente di più) in un finestra terminale.
Joe,

Sono d'accordo, ecco perché la fonte è su code.google.com/p/shellshock-check
Thomas Jones,

A volte, tuttavia, può offrire facilità d'uso per testare più sistemi.
Thomas Jones,

Non vedo il beneficio di questa cosa. Il controllo della vulnerabilità è molto più semplice incollando una semplice riga di comando nella finestra del terminale.
Albert Godfrind,

Tuttavia, quando collaudo più macchine, soprattutto nel mio caso, poiché è quello che faccio, inserire un'unità flash e aprire Shellshock Check.app è molto più facile che aprire Safari, cercare il comando bash per verificare, quindi aprire Terminale, incollandolo comando e quindi premendo Invio. È molto più veloce collegare un'unità flash e aprire un'applicazione.
Thomas Jones,
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.