Como faço para corrigir a vulnerabilidade do shellshock em um sistema Ubuntu obsoleto que não consigo atualizar?

22

Eu tenho um sistema que administro remotamente (2 fusos horários) que executa o Ubuntu 9.04, Jaunty. Por várias razões, principalmente por desconfiar de tentar fazer uma atualização de distribuição de tão longe, não posso atualizá-la para uma versão mais recente. Obviamente, ele não é mais suportado e não há patches oficiais. Existem instruções disponíveis sobre como corrigir o código e recompilar o bash-me para remover as vulnerabilidades do shellshock?

— Claus
fonte

5

Que pesquisa você fez sobre esse assunto? A solução mais simples provavelmente seria reconstruir e corrigir você mesmo. Talvez você precise aceitar isso, é hora de atualizar o servidor.

— Ramhound 25/09

Sim, essa é a minha opção de fallback. O servidor está saindo, só estou tentando mantê-lo mancando até que os fundos entrem para sua substituição. Se eu estivesse no local, morderia a bala e faria a atualização, mas muito raramente tenho que ir sem problemas, e sem poder colocar as mãos nela, prefiro não arriscar que, se não tiver para.

— Claus

Basta colocar algumas palavras-chave na página para que as pessoas possam encontrar isso. Também trabalhei para mim no Mac, OS X, Mavericks, com base no teste publicado em arstechnica.com/security/2014/09/…

1

deixe-o sem remendo, "mancando" mudará rapidamente. Seja muito claro, você está usando uma distribuição que foi lançada há cinco anos . O suporte terminou em outubro de 2010. Você tem muito mais vulnerabilidades com as quais se preocupar.

— precisa saber é o seguinte

29

Roubou isso do AskUbuntu , de alguém que roubou o Hacker News. Trabalhou em dois servidores antigos para mim

mkdir src
cd src
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 1 28); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz 
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 1 28);do patch -p0 < ../bash43-$i; done
#build and install
./configure --prefix=/ && make && make install
cd .. 
cd ..
rm -r src

Atualização: Acabei de notar que, se você não adicionar --prefix=/ao comando configure, você terminará /usr/local/bin/bashatualizado e /bin/bashainda estará vulnerável.

— unkilbeeg
fonte

Há um erro no script: a sequência "0 25" deve ser "1 26". Se você estiver lendo isso e puder editar a resposta, atualize-a. Obrigado!

— Joelparkerhenderson

Enquanto o ./configure --prefix=/ && makecorre bem, o make installparece exigirsudo

— Stewart

Obrigado por divulgar isso - uma maneira justa de corrigir as coisas durante a migração. Algumas pessoas têm muitos vms e não é realista reconstruir cada um. Usar isso como uma correção imediata e resolvê-lo por mais tempo em uma instalação mais atualizada é essencial.

— Jas Panesar

@ rubo77 Ele precisa ser agora 1 27 (o novo 27 patch é o mais importante)

— joelparkerhenderson

1

Adicionado um patch 28. Este não parecem corrigir a vulnerabilidade CVE-2014-7186/7187.

— Unkilbeeg

2

Há também uma solução para atualizar seu sources.list para o mais novo e depois usar o apt-get para atualizar apenas o bash. É muito rápido e eu escrevi um artigo sobre isso. Aqui está o que você basicamente faz:

Atualize para os repositórios apt-get mais recentes do Ubuntu 'confiáveis' (talvez você também precise alterar os URLs old-repositories.ubuntu.com se os usar, consulte o artigo vinculado):

sudo sed -i 's/YOUR_OS_CODENAME/trusty/g' /etc/apt/sources.list

Atualize o bash / aplique a correção:

sudo apt-get update
sudo apt-get install --only-upgrade bash

E possivelmente mude novamente os repositórios apt-get.

— Erik Duindam
fonte

Funcionou perfeitamente!

— Peter Kruithof 26/09/14

-1

O comando deve ser

sudo apt-get update && sudo apt-get install --only-upgrade bash

— ColdenZero
fonte

2

Isso não vai ajudar; como o OP disse, ele não é mais suportado, portanto não haverá uma atualização para o bash.

— Andrew Ferrier

-3

Uma opção simples é não usar o bash. Verifique se dashestá instalado e se /bin/shé um link simbólico dash, não bash. (Este é o padrão em algumas versões do Debian, mas não tenho certeza sobre o Ubuntu.) Se você possui contas de usuário para acesso ssh com comandos forçados, também é necessário alterar os shells de login deles. Você também pode precisar verificar se há scripts explicitamente usando o bash; grepping for #!/bin/bashdeve encontrá-los.

— R ..
fonte

5

É um pouco como dizer: "descobrimos que você pode ter segfaults em C ++, basta usar Java" ...

— DevSolar

3

Uma analogia mais próxima seria dizer a alguém com um bug no GCC para tentar clang. Ambos implementam o mesmo idioma (com conjuntos diferentes, mas às vezes sobrepostos, de extensões fora do padrão) e é improvável que a necessidade real seja de "bash", mas de "shell interpreter".

— R ..

Como você disse, existem scripts que podem usar explicitamente o bash. Mesmo se você solicitar os arquivos existentes que usam o bash, no futuro alguém poderá adicionar um novo script ao sistema que use explicitamente o bash. O mesmo vale para sistemas embarcados que usam o busybox (/ bin / sh aponta para o busybox), mas também possuem o bash instalado. A melhor coisa é atualizar o bash nos sistemas vulneráveis.

— precisa saber é o seguinte

A maioria dos scripts Unix / Linux requer o bash ou algum outro shell moderno como o ksh ou zsh. Elas têm muitas funcionalidades que as pessoas esperam em qualquer idioma, mas não estão presentes nos invólucros "básicos" como (BusyBox) ash / Dash / sh (original). Essas cascas mais simples têm apenas 20 a 30% da funcionalidade das cascas maiores, o que as torna mais rápidas. No entanto, eles exigem o uso extensivo de utilitários externos para muitas operações comuns, como manipulação avançada de strings e correspondência de padrões. Bash e outros podem correr cinzas, et.al. scripts. Mas não vice-versa.

— DocSalvager