O bash pode ser substituído inteiramente no OS X?


3

Por causa do CVE-2014-6271 e CVE-2014-7169 no OS XI, estava se perguntando: o bash pode ser substituído inteiramente por outro shell não afetado (por exemplo, traço ou outros)?



Por favor, faça ao DHCP explorar parte desta pergunta como uma nova pergunta. Obrigado.
Ian C.

Respostas:


6

Primeiro, você não precisa fazer isso, a menos que esteja oferecendo serviços da Web à Internet pública a partir do seu Mac. Caso contrário, aguarde até que haja uma atualização de segurança oficial da Apple.

No entanto, se você estiver oferecendo serviços da web, convém atualizar.

Patch Oficial

A Apple lançou uma atualização de segurança oficial do Bash aqui

Verificando se você está vulnerável

Primeiro confirme que você está usando um bash desatualizado:

$ 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.

O bash mais atual é 4.3.25

Se você não tiver o Xcode instalado, precisará das ferramentas de linha de comando do Xcode, que podem ser instaladas por

$ xcode-select --install

Ou no portal do desenvolvedor .

Para instalar o Brew ( http://brew.sh ):

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

Então faça:

$ brew doctor

Siga todas as instruções se houver problemas. Muitos problemas comuns são abordados aqui .

Atualize o brew para a lista mais recente de pacotes:

$ brew update

Para obter o bash mais recente 4.3.25:

$ brew install bash

Isso instala o bash no /usr/local/Cellar/bash/4.3.25/bin/bash

O antigo bashe shainda existe em /bin, portanto, após a instalação, você renomeará os executáveis ​​antigos para um novo arquivo.

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

Se você é muito paranóico, pode remover permissões de execução no bash_old

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

Em seguida, crie um link simbólico para o novo bash 4.3.25 que o brew instalou.

$ 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

Reinicie e está completo.

Um aviso - isso pode quebrar alguns scripts de shell existentes que podem depender do bash 3.2 ou das diferenças que o Mac shpossui sobre o linux sh. Há uma resposta muito mais sofisticada para substituir o bash e sh de fontes neste post.

Na maioria dos casos, é melhor aguardar atualizações oficiais.


2
“Na maioria dos casos, é melhor aguardar atualizações oficiais.” A menos que alguém esteja executando um servidor, nada disso é realmente necessário. Muitas pessoas vão quebrar as instalações do OS X nos próximos dias, enquanto entram em pânico para neutralizar uma ameaça que mal entendem.
precisa saber é o seguinte

1
@JakeGould - eu concordo.
Christopher Allen

Gostaria de copiar os arquivos em vez de ligar - se por algum motivo, você remove a instalação cerveja, o sistema tem um problema ....
Michael_Scharf

1
Acho apple.stackexchange.com/a/146851/83347 é a melhor resposta, porque ele usa fontes formar maçã ....
Michael_Scharf

3

Como @webmarc disse, não. Você pode substituir /bin/bashpor algum outro shell, mas certamente quebrará alguns programas porque o bash tem várias diferenças na sintaxe dele que o tornaram incompatível. Não consegui encontrar um shell alternativo compatível com o bash. No entanto, vinculei o traço /bin/she não encontrei problemas até agora.

Em relação ao DHCP aqui, há uma prova de ataque de conceito. O artigo é sobre dhcpcd(um cliente Linux). Não tenho certeza sobre o Mac OS X. Na discussão do Hacker News, eles dizem que o cliente OS X não usa o bash.

Outro vetor poderia ser sshd. Mas o ataque requer autenticação. Portanto, a menos que você esteja executando algum serviço ssh como um gitservidor, você deve estar seguro.


“Na discussão do Hacker News, eles dizem que o cliente OS X não usa o bash.” Onde está essa discussão? Você deve fornecer um link.
precisa saber é o seguinte

1
@JakeGould O link já está na resposta. Leia os comentários.
precisa saber é o seguinte

1

dashcontém apenas um pequeno subconjunto dos comandos encontrados em bashe par sh(o que em si é um subconjunto de coisas bash). Substituir por dashcertamente produzirá scripts inoperáveis ​​em seu sistema e possivelmente quebrará seu sistema mais do que ele protege.

Você pode recompilar o bash para atenuar alguns (no momento em que isso foi escrito) do perigo potencial ou aguardar o lançamento da Apple e a correção oficial.


1

Infelizmente, não ... vários shells possuem sintaxes diferentes, tornando os scripts escritos para um shell possivelmente incompatíveis com outro shell.

Não vi a infecção baseada em DHCP da qual você está falando. Você pode fornecer um link na sua pergunta?


0

alguns sites indicam que um pode estar infectado por meio de um cliente DHCP.

Isso não se aplica ao OS X. Nos sistemas Linux, um script de shell geralmente é chamado após o recebimento de uma concessão DHCP do servidor. Este não é o caso no OS X.

A menos que você esteja executando um servidor Web no seu Mac, que serve scripts CGI, você tem poucos motivos para se preocupar.


0

Sim, se você quer dizer / bin / sh, mas isso pode ser problemático, mas se você deseja substituir o bash como / bin / bash ou remover completamente o bash, basicamente não, embora não seja impossível - já que scripts são arquivos de texto, você pode editar todos os scripts de shell e, em seguida, manter o sistema sozinho, pelo resto do tempo ... Não há substituto para o bash.

Não, que você substituísse / bin / sh seria fácil, mas poderia haver um fim para isso. Se um script presumir que seu / bin / sh é realmente bash e usa coisas exclusivas para bash, o script que começa #! / Bin / sh agora seria interrompido. Renomeei meu / bin / sh para /bin/sh.was.bash e, em seguida, criei um link para mksh, e a reinicialização foi recebida com o prompt #. Reiniciei novamente com flag detalhado e encontrei algumas linhas em / etc / rc - export -n, uma coisa bash, o equivalente do shell korn é typeset + x, modifiquei o script rc e, e ele foi inicializado e c / tudo de bom. O sistema em que estou experimentando é o Tiger, então há um script rc e não posso esperar atualizações da Apple. O OSX moderno não possui um script rc, mas os aplicativos modernos podem ir do intel linux, onde / bin / sh é bash, para o intel-mac, onde / bin / sh também é bash,

Então, talvez eu deva dizer muito problemático, porque você deve tomá-lo como uma razão, NÃO para fazer isso. Em minha defesa, eu andei bisbilhotando com daemons de lançamento e os scripts rc, nesta semana e na semana anterior, jogando com as opções dynamic_pager, desativando alguns daemons de lançamento (tornando-os controláveis ​​por variáveis ​​no hostconfig), então para mim , isso é apenas um experimento um pouco mais radical do que eu poderia ter feito hoje, de qualquer maneira.

Se você quiser fazer algo, se achar que pode ser mais vulnerável do que outros, por causa de software adicional, etc., poderá olhar para cada script que lhe interessa e alterar a primeira linha (o shhbang) para fazer algo diferente de #! / bin / sh ou # / bin / bash, e esteja preparado para editar os scripts, pois eles podem ter recursos específicos do bash. O BASH é realmente um shell do tipo korn-shell, mais do que um shell do tipo bourne, como ash ou dash, portanto, se quiser manter as edições triviais, use um shell do korn como substituto. De fato, no tiger / bin / ksh é o "NEW Korn Shell", se isso ainda for verdade, eu diria que vá com isso, então você não precisará instalar nada e deixe / bin sozinho, o que não é uma má idéia. , basta alterar os scripts para #! / bin / ksh, remover bashisms de recursos, comuns ao korn shell,

Há uma chance de que 'shhbang' possa ser ignorado, pois, se um script de shell for chamado como "/ bin / sh / etc / rc", a primeira linha será apenas um comentário e será ignorada, mas com essa abordagem você só pode quebrar as coisas que muda, à medida que as muda.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.