Como corrigir o bug Heartbleed (CVE-2014-0160) no OpenSSL?

152

A partir de hoje, um bug no OpenSSL foi encontrado afetando as versões 1.0.1 a 1.0.1f ( inclusive) e 1.0.2-beta .

Desde o Ubuntu 12.04, estamos todos vulneráveis a esse bug. Para corrigir essa vulnerabilidade, os usuários afetados devem atualizar para o OpenSSL 1.0.1g .

Como cada usuário afetado pode aplicar essa atualização agora ?

    
por Lucio 08.04.2014 / 00:17
fonte

6 respostas

141

Atualizações de segurança estão disponíveis para 12.04, 12.10, 13.10 e 14.04 veja Aviso de Segurança do Ubuntu USN-2165-1 .

Primeiramente, você precisa aplicar as atualizações de segurança disponíveis, por exemplo, executando

sudo apt-get update
sudo apt-get upgrade

na linha de comando.

Não se esqueça de reiniciar os serviços (HTTP, SMTP, etc.) que usam a versão afetada do OpenSSL; caso contrário, você ainda estará vulnerável. Veja também Heartbleed: O que é e o que é opções para mitigá-lo? em Serverfault.com.

O comando a seguir mostra (após uma atualização) todos os serviços que precisam ser reiniciados:

sudo find /proc -maxdepth 2 -name maps -exec grep -HE '/libssl\.so.* \(deleted\)' {} \; | cut -d/ -f3 | sort -u | xargs --no-run-if-empty ps uwwp

Depois disso, você precisa para gerar novamente todas as chaves SSL do servidor e avaliar se as chaves podem ter vazado, caso em que os invasores podem ter recuperado informações confidenciais de seus servidores.

    
por Florian Diesch 08.04.2014 / 00:46
fonte
71

O bug é conhecido como Heartbleed .

Estou vulnerável?

Geralmente, você é afetado se você executar algum servidor que você gerou uma chave SSL em algum momento. A maioria dos usuários finais não é (diretamente) afetada; Pelo menos o Firefox e o Chrome não usam o OpenSSL. O SSH não é afetado. A distribuição dos pacotes do Ubuntu não é afetada (depende de assinaturas GPG).

Você está vulnerável se você executar qualquer tipo de servidor que use as versões 1.0–1.0.1f do OpenSSL (exceto as versões do curso que foram corrigidas desde que o bug foi descoberto). As versões afetadas do Ubuntu são 11,10 oníricos até 14,04 pré-lançamentos confiáveis. É um erro de implementação, não uma falha no protocolo, portanto somente os programas que usam a biblioteca OpenSSL são afetados. Se você tiver um programa vinculado à versão 0.9.x antiga do OpenSSL, isso não será afetado. Apenas programas que usam a biblioteca OpenSSL para implementar o protocolo SSL são afetados; programas que usam o OpenSSL para outras coisas não são afetados.

Se você executou um servidor vulnerável exposto à Internet, considere comprometido, a menos que seus registros não mostrem conexão desde o anúncio de 2014-04-07. (Isso pressupõe que a vulnerabilidade não foi explorada antes de seu anúncio.) Se o seu servidor foi exposto apenas internamente, se você precisa alterar as chaves, isso dependerá de outras medidas de segurança implementadas.

Qual é o impacto?

O bug permite qualquer cliente que pode se conectar ao seu servidor SSL para recuperar cerca de 64kB de memória do servidor. O cliente não precisa ser autenticado de forma alguma. Ao repetir o ataque, o cliente pode despejar partes diferentes da memória em tentativas sucessivas.

Um dos dados críticos que o invasor pode recuperar é a chave privada SSL do servidor. Com esses dados, o invasor pode representar seu servidor.

Como eu me recupero em um servidor?

  1. Coloque todos os servidores afetados offline. Enquanto estiverem em execução, eles estão potencialmente vazando dados críticos.

  2. Atualize o libssl1.0.0 package e verifique se todos os servidores afetados foram reiniciados.
    Você pode verificar se os processos afetados ainda estão sendo executados com o '' grep 'libssl. (excluído)' / proc / / maps '

  3. Gere novas chaves . Isso é necessário porque o bug pode ter permitido que um invasor obtivesse a chave privada antiga. Siga o mesmo procedimento que você usou inicialmente.

    • Se você usar certificados assinados por uma autoridade de certificação, envie suas novas chaves públicas para sua CA. Quando você obtiver o novo certificado, instale-o no seu servidor.
    • Se você usar certificados autoassinados, instale-o em seu servidor.
    • De qualquer forma, mova as chaves e os certificados antigos para fora do caminho (mas não os exclua, apenas certifique-se de que eles não estão mais sendo usados).
  4. Agora que você tem novas chaves não comprometidas, é possível colocar seu servidor de volta online .

  5. Revoga os certificados antigos.

  6. Avaliação de danos : qualquer dado que esteja na memória de um processo que atende conexões SSL pode ter vazado. Isso pode incluir senhas de usuários e outros dados confidenciais. Você precisa avaliar o que esses dados podem ter sido.

    • Se você estiver executando um serviço que permita a autenticação de senha, as senhas dos usuários que se conectaram desde um pouco antes de a vulnerabilidade ser anunciada devem ser consideradas comprometidas. (Um pouco antes, porque a senha pode ter permanecido sem uso na memória por um tempo.) Verifique seus logs e altere as senhas de qualquer usuário afetado.
    • Invalide também todos os cookies da sessão, pois eles podem ter sido comprometidos.
    • Certificados de clientes não são comprometidos.
    • Todos os dados que foram trocados desde um pouco antes da vulnerabilidade podem ter permanecido na memória do servidor e, portanto, podem ter vazado para um invasor.
    • Se alguém registrou uma conexão SSL antiga e recuperou as chaves do seu servidor, ele pode agora descriptografar a transcrição. (A menos que PFS fosse assegurado - se você não sabe, não foi.)

Como eu me recupero em um cliente?

Existem apenas algumas situações em que os aplicativos clientes são afetados. O problema no lado do servidor é que qualquer um pode se conectar a um servidor e explorar o bug. Para explorar um cliente, três condições devem ser atendidas:

  • O programa cliente usou uma versão com bugs da biblioteca OpenSSL para implementar o protocolo SSL.
  • O cliente está conectado a um servidor mal-intencionado. (Então, por exemplo, se você se conectou a um provedor de e-mail, isso não é uma preocupação.) Isso teve que acontecer depois que o proprietário do servidor tomou conhecimento da vulnerabilidade, então presumivelmente após 2014-04-07.
  • O processo do cliente tinha dados confidenciais na memória que não foram compartilhados com o servidor. (Então, se você acabou de executar wget para baixar um arquivo, não há dados para vazar.)

Se você fez isso entre 2014-04-07 à noite UTC e atualizou sua biblioteca OpenSSL, considere todos os dados que estavam na memória do processo do cliente a serem comprometidos.

Referências

por Gilles 08.04.2014 / 12:02
fonte
40

Para ver qual versão do OpenSSL está instalada no Ubuntu, execute:

dpkg -l | grep openssl

Se você vir a seguinte saída de versão, o patch para CVE-2014-0160 deve ser incluído.

ii  openssl      1.0.1-4ubuntu5.12      Secure Socket Layer (SSL)...

Analisando o link , ele mostra quais tipos de bugs foram corrigidos:

...
 SECURITY UPDATE: memory disclosure in TLS heartbeat extension
    - debian/patches/CVE-2014-0160.patch: use correct lengths in
      ssl/d1_both.c, ssl/t1_lib.c.
    - CVE-2014-0160
 -- Marc Deslauriers <email address hidden>   Mon, 07 Apr 2014 15:45:14 -0400
...
    
por crimi 08.04.2014 / 08:40
fonte
17

Se os seus repositórios do apt-get não contiverem nenhuma versão pré-compilada do 1.0.1g OpenSSL , basta baixar as fontes do site oficial e compilá-las.

Abaixo da linha de comando única para compilar e instalar a última versão openssl.

curl https://www.openssl.org/source/openssl-1.0.1g.tar.gz | tar xz && cd openssl-1.0.1g && sudo ./config && sudo make && sudo make install

Substitua o arquivo binário antigo openssl pelo novo por meio de um link simbólico.

sudo ln -sf /usr/local/ssl/bin/openssl 'which openssl'

Vocês são todos bons!

# openssl version should return
openssl version
OpenSSL 1.0.1g 7 Apr 2014

Cf esta postagem no blog .

NB: Conforme indicado na postagem do blog, essa solução não corrigirá "Nginx e o servidor Apache que precisam ser recompilados com fontes openSSL 1.0.1g".

    
por Quentin Rousseau 08.04.2014 / 04:18
fonte
12

Para aqueles que não querem fazer uma atualização de pacote em todo o servidor. Eu li um monte desses guias hoje e apt-get upgrade openssl === apt-get upgrade isso irá aplicar todas as correções de segurança exigidas pela sua máquina. Maravilhoso, a menos que você esteja explicitamente inclinado em uma versão antiga do pacote em algum lugar.

Esta é a ação mínima necessária no Ubuntu 12.04 LTS executando o Apache 2:

  • Acesse este endereço e prove que você tem a vulnerabilidade. Você deve usar o ENDEREÇO EXTERNO DIRETO DO SEU WEB SERVER. Se você usar um balanceador de carga (por exemplo, ELB), talvez não esteja entrando em contato diretamente com seu servidor da web.

  • Execute o seguinte 1 liner para atualizar pacotes e reiniciar. Sim, eu vi todos os guias dizendo que você deveria ter um carimbo de data e hora depois de 4 de abril de 2014, isso não parece ser o caso para mim.

    apt-get update & amp; & amp; apt-get install openssl libsl1.0.0 & amp; & amp; /etc/init.d/apache2 restart

  • Certifique-se de ter as versões de pacote apropriadas instaladas e verifique seu servidor da Web para ver a vulnerabilidade mais uma vez.

Os pacotes de chaves são os seguintes, eu determinei esta informação usando o comando abaixo e então editei o arquivo (você não precisa saber muito sobre o estado das minhas máquinas).

$ dpkg -l | grep ssl

ii  libssl-dev                       1.0.1-4ubuntu5.12          SSL development libraries, header files and documentation
ii  libssl1.0.0                      1.0.1-4ubuntu5.12          SSL shared libraries
ii  openssl                          1.0.1-4ubuntu5.12          Secure Socket Layer (SSL)* binary and related cryptographic tools

1.0.1-4ubuntu5.12 NÃO deve conter a vulnerabilidade. Certifique-se de que este é o caso, novamente indo para o site abaixo e testando o seu servidor web.

link

    
por Adrian 08.04.2014 / 23:56
fonte
11

Eu notei muitos comentaristas aqui que precisam de ajuda urgentemente. Eles estão seguindo as instruções, atualizando, reinicializando e ainda vulneráveis ao usar alguns dos sites de teste.

Você deve verificar se não tem pacotes em espera, como libssl.

:~$ sudo apt-get upgrade -V
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
  libssl-dev (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  libssl1.0.0 (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  linux-image-virtual (3.2.0.31.34 => 3.2.0.60.71)
  linux-virtual (3.2.0.31.34 => 3.2.0.60.71)
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

Para atualizar os apt-mark unhold libssl1.0.0 (por exemplo). Em seguida, atualize: apt-get upgrade -V . Em seguida, reinicie os serviços afetados.

    
por Domino 08.04.2014 / 19:51
fonte