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


A partir de hoje, um bug no OpenSSL foi encontrado afetando versões 1.0.1 através 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 todos os usuários afetados podem aplicar essa atualização agora?


152
2018-04-07 22:17


origem


Você tem uma versão afetada do openssl? - Braiam
Eu tenho a versão corrigida 1.0.1-4ubuntu5.12 e eu reiniciei o serviço apache, mas filippo.io/Heartbleed teste no meu site ainda diz que sou vulnerável Alguma ideia do porquê?
@Mat Eu não sei o que esse site testa, mas talvez ele detecte que você está usando uma chave antiga. Como a chave pode ter vazado, você precisa regenerá-la. - Gilles
Você realmente não quer atualizar o OpenSSL para atacar novas versões, isso é uma dor inacreditável. Muito mais fácil é simplesmente instalar o pacote atualizado que corrige o problema: ubuntu.com/usn/usn-2165-1 - sarnold
você reiniciou seus serviços após a atualização? - Axel


Respostas:


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

Então, primeiro você precisa aplicar as atualizações de segurança disponíveis, por exemplo, executando

sudo apt-get update
sudo apt-get upgrade

da 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 quais são as 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 regenere todas as chaves SSL do servidor, em seguida, avalie se suas chaves podem ter vazado e, nesse caso, os invasores podem ter recuperado informações confidenciais de seus servidores.


141
2018-04-07 22:46



Não tenho certeza se isso funciona no Ubuntu 12.04.4 LTS. Após a atualização completa, openssl version dá OpenSSL 1.0.1 14 Mar 2012. Essa não é a versão corrigida, certo? Ou eu estou interpretando mal? - Paul Cantrell
O que fazer com o Ubuntu 13.04? Nenhum openssl atualizado disponível :-( - Frodik
No Ubuntu 12.04 até mesmo o OpenSSL fixo exibe a versão 1.0.1 14 Mar 2012. Ler resposta de crimi para descobrir se sua instalação está incluindo a correção. - dan
Obrigado, @dan! Resumindo a resposta de @crimi aqui: se você correr dpkg -l | grep ' openssl ' e você consegue 1.0.1-4ubuntu5.12 então você é bom de ir. - Paul Cantrell
Corrigir e reiniciar não é suficiente. Você precisa regenerar chaves e avaliar se suas chaves vazaram, assim como outros materiais confidenciais. Veja por exemplo O Heartbleed significa novos certificados para cada servidor SSL? - Gilles


O bug é conhecido como Heartbleed.

Eu sou vulnerável?

Geralmente, você é afetado se você executar algum servidor que você gerou uma chave SSL para 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 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 quem 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 pacotee verifique se todos os servidores afetados foram reiniciados.
    Você pode verificar se os processos afetados ainda estão sendo executados com o `` grep 'libssl.(suprimido) '/ 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 usado 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 em 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 estejam mais sendo usados).
  4. Agora que você tem novas chaves descompromissadas, você pode traga seu servidor de volta online.

  5. Revogar os certificados antigos.

  6. Avaliação de danos: qualquer dado que tenha estado na memória de um processo que serve 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 permite a autenticação de senha, as senhas dos usuários que se conectaram desde um pouco antes da vulnerabilidade ser anunciada devem ser consideradas comprometidas. (Um pouco antes, porque a senha pode ter ficado sem uso na memória por um tempo.) Verifique seus logs e altere as senhas de qualquer usuário afetado.
    • Também invalida todos os cookies de sessão, pois eles podem ter sido comprometidos.
    • Certificados de cliente não são comprometidos.
    • Quaisquer 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 servidor, ele pode descriptografar a transcrição. (A menos que PFS foi assegurado - se você não sabe, não foi.)

Como eu me recupero em um cliente?

Existem poucas situações nas quais 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 conectado a um servidor malicioso. (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 eram compartilhados com o servidor. (Então, se você acabou de correr wget para baixar um arquivo, não havia 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


71
2018-04-08 10:02



Eu não acredito que "apenas o lado do servidor de conexões SSL / TLS é afetado" é verdadeiro. openssl.org/news/secadv_20140407.txt diz que pode revelar segredos do cliente ou do servidor. ubuntu.com/usn/usn-2165-1 concorda. As chances de você usar certificados de cliente ao se conectar a um servidor mal-intencionado são pequenas, mas a possibilidade existe. - armb
@armb Você faz um bom ponto. Não importa se os certificados de cliente são usados, o vazamento de dados não está relacionado ao uso de certificados. Eu tenho contou com a ajuda de profissionais. - Gilles
Os certificados de cliente são os casos em que você vazaria chaves privadas, mas sim, senhas, cookies de autorização, etc., poderiam vazar de qualquer maneira. No entanto, com um cliente baseado em OpenSSL como curl ou wget em uso típico, você não teria segredos para outros sites na memória enquanto se conectava a um servidor mal-intencionado, então nesse caso eu acho que o único vazamento seria se você desse aos segredos do cliente antecipando-se a fornecê-los a um site legítimo, e o Heartbleed vazou-os durante o aperto de mão antes que a verificação do certificado mostrasse que você não está conectado ao site certo. - armb
@Gilles Você pode estar interessado nas respostas para Que clientes são provados ser vulneráveis ​​a Heartbleed?. Consegui ganhar memória "interessante" no nginx (modo proxy), wget, links e outros. - Lekensteyn
@ MuhamedHuseinbašić O pacote openssl contém ferramentas de linha de comando. Ele não é usado por aplicativos que usam a biblioteca OpenSSL para implementar o protocolo SSL (como o Apache). Mas você deve apenas aplicar as atualizações de segurança da distribuição. - Gilles


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

Olhando para https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12, mostra que tipo de bugs são 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
...

40
2018-04-08 06:40



Eu fiz o upgrade e obtive a versão 5.12, mas essa ferramenta ainda me diz que sou vulnerável filippo.io/Heartbleed Pensamentos? - toxaq
Eu testei nossos servidores atualizados deste lado e ele me disse que eu não sou afetado. Você reinicializou seu sistema ou, pelo menos, tem certeza de que todos os processos necessários foram reiniciados? - crimi
Depois de atualizar o OPENSSL, tudo o que tive que fazer foi reiniciar o serviço apache, mas graciosa não ajudou. Eu tive que ir e reiniciar usando sudo service apache2 restart - Tom Hert
Acabei de encontrar a causa da minha vulnerabilidade: eu tinha o mod-spdy-beta instalado. Depois de removê-lo e reiniciar o Apache, todos os testes estão verdes agora. - Andreas Roth
Atualizando openssl não conserta aplicativos como Apache, Nginx ou postfix. Você tem que atualizar libssl1.0.0 e reinicie-os conforme explicado em outros posts. - tnj


Se seu repositórios apt-get não contém qualquer precompilado 1.0.1g OpenSSL versão, então basta baixar fontes do site oficial e compilá-lo.

Abaixo da linha de comando única para compilar e instalar a última versão do 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 antigo arquivo binário openssl pelo novo através de um symlink.

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

Você é tudo de bom!

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

Cf isto postagem no blog.

NB: Como dito na postagem do blog, essa solução não corrigirá "o servidor Nginx e Apache que precisa ser recompilado com fontes openSSL 1.0.1g".


17
2018-04-08 02:18



Como normalmente o Ubuntu não fornece a nova versão upstream, mas corrigiu as versões de todas as versões suportadas para manter as mudanças no mínimo. - Florian Diesch
Nota: Certifique-se de reiniciar seu servidor após atualizar o OpenSSL. Apache e Nginx pegaram a nova biblioteca e a vulnerabilidade foi fechada. - dAngelov
Heh, agora que aproveito o tempo para ler o detalhes desta postagem, fico ainda mais horrorizado - baixar um tarball de algum lugar aleatório da Internet, desempacotar e executar partes dele como root é apenas um comportamento imprudente. Seria um pouco melhor se as assinaturas do tarball fossem baixadas e verificadas, mas garantir que as assinaturas foram assinadas pela chave certa é uma questão difícil. Distribuições já foram feitas para garantir a provisão segura de tarballs e patches. Obrigado. - sarnold
pode ser uma boa idéia compilar a partir da fonte AGORA, e instalar uma nova versão mais recente do apt, dessa forma a sua mais segura do que sem esperar em versões mais antigas do Ubuntu, de qualquer forma, apenas meus dois centavos - nwgat
@sarnold openssl.org não parece um lugar aleatório para baixar a fonte do openssl. A Canonical deveria tornar isso desnecessário, mas openssl.org devemos ser o upstream autoritativo para trabalhar. - Rustavore


Para aqueles que não querem fazer um upgrade de pacote em todo o servidor. Eu li um monte desses guias hoje e apt-get upgrade openssl === apt-get upgrade isso 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 requerida no Ubuntu 12.04 LTS executando o Apache 2:

  • Vamos para esse 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 && apt-get instala o openssl libssl1.0.0 && /etc/init.d/apache2 restart

  • Assegure-se de ter as versões de pacotes apropriadas instaladas e verifique seu servidor da Web sobre 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.

http://filippo.io/Heartbleed/


12
2018-04-08 21:56



Usando um site externo para provar uma vulnerabilidade em um servidor parece ser a abordagem errada para mim. - Rinzwind
Os scripts externos de teste de vulnerabilidades estão se tornando cada vez mais comuns nos dias de hoje. Ele faz exatamente o que um script interno faz, a conexão é iniciada a partir de um servidor externo. Você pode procurar sites como o WhiteHatSecurity.com para obter um exemplo de um programa que inicia todas as conexões remotamente. Há casos em que isso não aconteceria, por exemplo, teste de vulnerabilidade de rede, mas para testar um servidor da Web voltado para a frente (que, em geral, um servidor SSL será), isso é quase ideal. - Adrian
Por que instalar o pacote se ele está sendo atualizado? - Braiam
apt-get install openssl libssl1.0.0 fez isso por mim. Corrida openssl version -a agora mostra: built on: Mon Apr 7 20:33:29 UTC 2014 - topher
"Scripts de testes de vulnerabilidade externos estão se tornando cada vez mais comuns hoje em dia", o que abre a possibilidade de o site externo abusar do meu sistema: tudo o que eles precisam saber é que ele falha e invade meu sistema antes de corrigi-lo. Não, este não é o caminho correto. (e sim eu hospedo meus próprios sites com apache e openssl). - Rinzwind


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 aqueles apt-mark unhold libssl1.0.0 (por exemplo). Então atualize: apt-get upgrade -V. Em seguida, reinicie os serviços afetados.


11
2018-04-08 17:51