Può bash essere sostituito interamente in OS X?

3

A causa di CVE-2014-6271 e CVE-2014-7169 su OS X mi chiedevo: può bash essere sostituito interamente da un'altra shell non interessata (ad es. dash o altri)?

    
posta nrfb 25.09.2014 - 20:52
fonte

6 risposte

6

Per prima cosa, non è necessario farlo a meno che tu non stia offrendo servizi Web a Internet pubblica dal tuo Mac. Se non lo sei, attendi fino a quando non è disponibile un aggiornamento di sicurezza ufficiale di Apple.

Tuttavia, se offri servizi web, potresti voler aggiornare.

Patch ufficiale

Apple ha rilasciato un aggiornamento di sicurezza Bash ufficiale qui

Verifica della vulnerabilità

Prima conferma che stai usando una bash non aggiornata:

$ which bash
/bin/bash
$ /bin/bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.

La bash più recente è 4.3.25

Se non hai installato Xcode, avrai bisogno degli strumenti da riga di comando Xcode, che possono essere installati da

$ xcode-select --install

O dal portale per sviluppatori .

Per installare Brew ( link ):

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Quindi fai:

$ brew doctor

Segui le istruzioni se ci sono problemi. Molti problemi comuni sono indirizzati qui .

Quindi aggiorna brew sull'ultimo elenco di pacchetti:

$ brew update

Per ottenere l'ultima versione 4.3.25:

$ brew install bash

Questo installa bash in /usr/local/Cellar/bash/4.3.25/bin/bash

Il vecchio bash e sh esiste ancora a /bin , quindi dopo l'installazione, rinominerai i vecchi eseguibili in un nuovo file.

$ sudo mv /bin/bash /bin/bash_old
$ sudo mv /bin/sh /bin/sh_old

Se sei molto paranoico, puoi rimuovere le autorizzazioni di esecuzione su bash_old

$ sudo chmod a-x /bin/bash_old /bin/sh_old

Quindi crea un collegamento simbolico alla nuova bash 4.3.25 che brew installò.

$ sudo ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /bin/bash
$ sudo ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /bin/sh

Riavvia ed è completo.

Un avvertimento: questo può violare alcuni script di shell esistenti che potrebbero basarsi su bash 3.2 o le differenze che il Mac sh ha su linux sh . C'è una risposta molto più sofisticata alla sostituzione di bash e sh da fonti in questo post.

Nella maggior parte dei casi è meglio attendere gli aggiornamenti ufficiali.

    
risposta data 25.09.2014 - 23:28
fonte
3

Come @webmarc ha detto, no. Puoi sostituire /bin/bash con qualche altra shell, ma sicuramente interromperesti alcuni programmi perché bash ha diverse differenze nella sua sintassi che lo rendono incompatibile. Non sono riuscito a trovare una shell alternativa compatibile bash. Tuttavia, ho fatto un collegamento simbolico a /bin/sh e finora non ho rilevato problemi.

Riguardo al DHCP qui c'è un attacco di prova del concetto. L'articolo riguarda dhcpcd (un client Linux). Non sono sicuro di Mac OS X. Nella discussione su Hacker News dicono che il client OS X non lo fa usa bash affatto.

Un altro vettore potrebbe essere sshd . Ma l'attacco richiede l'autenticazione. Quindi, a meno che tu non stia eseguendo un servizio ssh come un server git dovresti essere al sicuro.

    
risposta data 26.09.2014 - 01:24
fonte
1

dash contiene solo un piccolo sottoinsieme dei comandi trovati in bash e anche sh (che a sua volta è un sottoinsieme di cose in bash ). Sostituendo entrambi con dash otterrai sicuramente script inoperabili sul tuo sistema e possibilmente interromperà il sistema più di quanto non protegga il tuo sistema.

Puoi ricompilare bash per attenuare alcuni (al momento in cui è stato scritto) di potenziale pericolo o attendere che Apple rilasci e risolva ufficialmente.

    
risposta data 25.09.2014 - 21:00
fonte
1

Sfortunatamente, no ... varie shell hanno sintassi diverse che rendono gli script scritti per una shell possibilmente incompatibile con un'altra shell.

Non ho visto l'infezione basata su DHCP di cui stai parlando, puoi fornire un link nella tua domanda?

    
risposta data 25.09.2014 - 21:00
fonte
0

some sites indicate one could be infected via a DHCP client.

Questo non si applica a OS X. Sui sistemi Linux, uno script di shell viene solitamente chiamato dopo aver ricevuto un lease DHCP dal server. Questo non è il caso su OS X.

A meno che tu non stia utilizzando un server web sul tuo Mac che serve script CGI, hai poco motivo di preoccuparti.

    
risposta data 25.09.2014 - 23:22
fonte
0

Sì, se intendi come / bin / sh, ma potrebbe essere problematico, ma se vuoi sostituire bash come / bin / bash o rimuovere bash interamente, in pratica no, anche se non è impossibile - perché gli script sono file di testo, è possibile modificare ogni script di shell e quindi mantenere il sistema da soli, da soli, per il resto del tempo ... Non esiste una sostituzione drop-in per bash.

No, sostituendo / bin / sh sarebbe facile, ma potrebbe esserci una fine. Se uno script presume il tuo / bin / sh, in realtà è bash e usa le cose univoche bash, quindi lo script che inizia #! / bin / sh si interrompe ora. Ho rinominato il mio / bin / sh in /bin/sh.was.bash e poi ho fatto un link a mksh, e il riavvio è stato accolto con un prompt #. Ho riavviato di nuovo con una bandiera dettagliata e ho trovato alcune righe in / etc / rc - export -n, una cosa bash, l'equivalente della shell korn è typeset + x, Ho modificato lo script rc, e, e ha avviato, e w / tutto bene. Il sistema su cui sto sperimentando è Tiger, quindi c'è uno script rc, e non posso aspettarmi aggiornamenti da parte di Apple. Il moderno OSX non ha uno script rc, MA le moderne app potrebbero andare da Intel linux, dove / bin / sh è bash, a intel-mac, dove / bin / sh è anche bash, e uno sviluppatore potrebbe altrettanto facilmente aggiungere dei bashismi per lanciare demoni e lanciare agenti, e se non ora, ma più tardi quando si scaricano un aggiornamento (per la loro app), che ora si romperà solo sul tuo sistema.

Quindi, forse dovrei dire molto problematico, perché dovresti prenderlo come una ragione, NON farlo. A mia difesa, mi sono occupato dei demoni di lancio e degli script rc, questa settimana e la settimana prima, giocando con le opzioni dynamic_pager, disattivando alcuni daemon di lancio (rendendoli controllabili dalle variabili in hostconfig), quindi per me , questo è solo un esperimento solo un po 'più radicale di quello che avrei potuto fare oggi, comunque.

SE vuoi fare qualcosa, se pensi di essere più vulnerabile di altri, a causa del software aggiuntivo, ecc., puoi guardare ogni script di cui sei preoccupato e cambiare la prima riga (lo shhbang) fare qualcosa di diverso da #! / bin / sh o # / bin / bash e prepararsi a modificare gli script, poiché potrebbero avere funzioni specifiche di bash. BASH è in realtà una shell tipo Korn-shell, più che una shell tipo bourne come ash, o dash, quindi se vuoi mantenere le modifiche banali usa un guscio korn come una sostituzione. Infatti su tiger / bin / ksh c'è la "NUOVA Korn Shell", se questo è ancora vero, direi di andare con quello, quindi non devi installare nulla, e lasciare / bin da solo, che non è una cattiva idea, basta cambiare gli script in #! / bin / ksh, rimuovere i bashismi per le funzionalità, comune alla shell korn, ma potresti avere fortuna e non ce ne saranno.

C'è una possibilità, che 'shhbang' possa essere ignorato, dal momento che è se uno script di shell è invocato come "/ bin / sh / etc / rc", quindi la prima riga è solo un commento, e ignorata, ma con questo approccio puoi solo rompere le cose che cambi, mentre le cambi.

    
risposta data 27.09.2014 - 01:34
fonte

Leggi altre domande sui tag