Esta é uma pergunta canônica sobre como entender e corrigir o problema de segurança do Heartbleed.

O que exatamente é o CVE-2014-0160 AKA "Heartbleed"? Qual é a causa, quais SOs e versões do OpenSSL são vulneráveis, quais são os sintomas, existem métodos para detectar uma exploração bem-sucedida?

Como posso verificar se meu sistema está afetado? Como essa vulnerabilidade pode ser mitigada? Deveria me preocupar que minhas chaves ou outros dados privados tenham sido comprometidos? Com que outros efeitos colaterais devo me preocupar?

Primeiro , antes de surtar, certifique-se de entender se essa vulnerabilidade realmente se aplica a você. Se você possui um servidor, mas nunca teve nenhum aplicativo usando TLS, isso não é uma tarefa de alta prioridade para você corrigir. Se, por outro lado, você já teve aplicativos habilitados para TLS, então está pronto para um deleite. Leia:

O que exatamente é o CVE-2014-0160, também conhecido como "Heartbleed"?

É uma grande bagunça, é isso que é. Em resumo, uma vulnerabilidade explorável remotamente foi descoberta nas versões 1.0.1 a 1.0.1f do OpenSSL, através das quais um invasor pode ler certas partes da memória do sistema. Essas partes são aquelas que mantêm dados confidenciais, como chaves privadas, chaves pré-compartilhadas, senhas e dados corporativos de alto valor, entre outras coisas.

O bug foi descoberto independentemente por Neel Mehta, do Google Security (21 de março de 2014) e pela empresa finlandesa de testes de segurança de TI Codenomicon (2 de abril de 2014).

Qual é a causa?

Bem, código incorreto no OpenSSL. Aqui é a confirmação de que introduziu a vulnerabilidade, e aqui é a confirmação de que fixa a vulnerabilidade. O bug apareceu em dezembro de 2011 e foi corrigido hoje, 7 de abril de 2014.

O bug também pode ser visto como um sintoma de um problema maior. Os dois problemas relacionados são: (1) que processo existe para garantir que o código incorreto não seja introduzido em uma base de código e (2) por que os protocolos e extensões são tão complexos e difíceis de testar. O item (1) é uma questão de governança e processo no OpenSSL e em muitos outros projetos. Muitos desenvolvedores simplesmente resistem a práticas como revisão de código, análise e varredura. O item (2) está sendo discutido no GT TLS da IETF. Consulte Heartbleed / complexidade do protocolo .

O código incorreto foi inserido com códigos maliciosos?

Não vou especular se isso foi realmente um erro ou se algum código foi inserido em nome de um ator ruim. No entanto, a pessoa que desenvolveu o código para o OpenSSL afirma que foi inadvertido. Veja O homem que introduziu séria falha de segurança "Heartbleed" nega que a tenha inserido deliberadamente .

Quais sistemas operacionais e versões do OpenSSL são vulneráveis?

Como mencionado acima, qualquer sistema operacional que esteja usando ou aplicativo vinculado ao OpenSSL 1.0.1 a 1.0.1f.

Quais são os sintomas, existem métodos para detectar uma exploração bem-sucedida?

Esta é a parte assustadora. Até onde sabemos, não há maneira conhecida de detectar se essa vulnerabilidade foi ou não explorada. Teoricamente, é possível que em breve sejam liberadas assinaturas de IDS que possam detectar essa exploração, mas, até o momento da redação deste documento, elas não estavam disponíveis.

Há evidências de que o Heartbleed estava sendo explorado ativamente em estado selvagem desde novembro de 2013. Veja o artigo de natureza selvagem do EFF : as agências de inteligência usavam o Heartbleed em novembro de 2013? E a Bloomberg relata que a NSA havia armado a exploração logo após a introdução da vulnerabilidade. Veja a NSA disse explorar o bug do Heartbleed por inteligência por anos . No entanto, a Comunidade de Inteligência dos EUA nega as alegações da Bloomberg. Veja IC NA GRAVAÇÃO .

Como posso verificar se meu sistema está afetado?

Se você estiver mantendo o OpenSSL no seu sistema, poderá simplesmente emitir openssl version:

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

Se a distribuição é manter OpenSSL, então você provavelmente não pode determinar a versão do OpenSSL, devido à volta remendar usando opensslcomando ou as informações do pacote (por exemplo, apt-get, dpkg, yumou rpm). O processo de correção posterior usado pela maioria das distribuições (todas?) Usa apenas o número da versão base (por exemplo, "1.0.1e"); e não inclui uma versão de segurança efetiva (por exemplo, "1.0.1g").

Há uma pergunta em aberto no Superusuário para determinar a versão de segurança efetiva para o OpenSSL e outros pacotes quando os pacotes são devolvidos. Infelizmente, não há respostas úteis (além de consultar o site da distribuição). Consulte Determinar a versão de segurança efetiva quando confrontado com o Backpatching ?

Como regra geral: se você já instalou uma das versões afetadas e já executou programas ou serviços vinculados ao suporte do OpenSSL para TLS, estará vulnerável.

Onde posso encontrar um programa para testar a vulnerabilidade?

Poucas horas após o anúncio da Heartbleed, várias pessoas na Internet publicaram aplicativos da Web acessíveis ao público que supostamente poderiam ser usados ​​para verificar um servidor quanto à presença dessa vulnerabilidade. Até o momento em que escrevi este artigo, não revisei nenhum, portanto não divulgarei mais suas aplicações. Eles podem ser encontrados com relativa facilidade com a ajuda do seu mecanismo de pesquisa preferido.

Como essa vulnerabilidade é mitigada?

Atualize para uma versão não vulnerável e redefina ou proteja os dados vulneráveis. Conforme observado no site Heartbleed , as etapas de resposta apropriadas são amplamente:

1. Patch sistemas vulneráveis.
2. Regenere novas chaves privadas.
3. Envie um novo CSR para sua CA.
4. Obtenha e instale um novo certificado assinado.
5. Invalidar chaves de sessão e cookies
6. Redefinir senhas e segredos compartilhados
7. Revogar certificados antigos.

Para uma análise e resposta mais detalhadas, consulte O que um operador de site deve fazer sobre a exploração do Heartbleed OpenSSL? no Security Stack Exchange.

Deveria me preocupar que minhas chaves ou outros dados privados tenham sido comprometidos? Com que outros efeitos colaterais devo me preocupar?

Absolutamente. Os administradores de sistemas precisam assumir que seus servidores que usavam versões vulneráveis ​​do OpenSSL estão realmente comprometidos e respondem de acordo.

Logo após a divulgação da vulnerabilidade, o Cloudfare ofereceu um desafio para verificar se a chave privada de um servidor poderia ser recuperada na prática. O desafio foi vencido de forma independente por Fedor Indutny e Ilkka Mattila. Veja O Desafio Heartbleed .

Onde posso encontrar mais informações?

Despejo de link, para quem procura mais detalhes:

• OpenSSL SECADV 2014047
• CVE-2014-0160
• Heartbleed
• Anúncio do Ubuntu
• Anúncio RHEL
• Anúncio oficial do OpenSSL

Uma linha do tempo bastante detalhada dos eventos de divulgação pode ser encontrada na linha do tempo da divulgação da Heartbleed: quem sabia o quê e quando .

Se você é um programador e está interessado em vários truques de programação, como detectar um ataque do Heartbleed através do msg_cbretorno de chamada do OpenSSL , consulte o Aviso de Segurança 2014047 do OpenSSL .

Uma explicação simples do bug, por XKCD:

Ubuntu 12.04, 12.10 e 13.10

O Ubuntu emitiu o USN-2165-1 , que afirma que os pacotes atualizados estão agora disponíveis nos arquivos. Execute os dois comandos a seguir para obter a correção.

sudo apt-get update
sudo apt-get upgrade

Ubuntu 14.04

Fiz upload de um pacote Debian contendo a nova versão (1.0.1g) para um PPA que configurei para esse fim. Esses três comandos adicionam meu PPA ao seu sistema, atualizam a lista de pacotes disponíveis e atualizam tudo:

sudo add-apt-repository ppa:george-edison55/openssl-heartbleed-fix
sudo apt-get update
sudo apt-get upgrade

_{Nota: o PPA também fornece pacotes para o Ubuntu 12.04 e 13.10, caso você prefira executar a nova versão (1.0.1g) em vez de apenas usar as versões corrigidas nos arquivos.}

Ubuntu 10.04

Esta é uma versão LTS, a versão do servidor ainda é suportada e recebe atualizações de segurança. Mas a vulnerabilidade heartbleed não afetou o pacote openssl de uma instalação padrão do ubuntu 10.04, porque a versão está abaixo de 1.0.1.

A versão para desktop chegou ao fim da vida útil e precisa ser atualizada / reinstalada.

Ubuntu 13.04 e outras versões desatualizadas

O Ubuntu 13.04 teve um ciclo de suporte muito curto, o que você não pode esperar. Já chegou ao fim da vida útil e não recebe mais atualizações de segurança. Por muito tempo deveria ter sido atualizado. Se alguém ainda o estiver usando, atualize agora, do zero, ou pode ser atualizado não destrutivo para 13.10 seguindo este procedimento fácil: http://www.tecmint.com/upgrade-ubuntu-13-04-raring-ringtail -to-ubuntu-13-10-saucy-salamander / Após a atualização, o sistema recebe o patch heartbleed da 13.10.

Para todas as outras versões desatualizadas do ubuntu, significa basicamente que é necessária uma nova instalação.

Verifique se o patch foi aplicado

Basicamente, execute openssl version -ae verifique se a data de compilação é 7 de abril de 2014 ou posterior, mas veja mais aqui .

Reiniciar

A melhor maneira de garantir que todos os serviços, dependendo do OpenSSL, sejam reiniciados é reiniciar .

RedHat 6.5 e CentOS 6.5

Estes são vulneráveis. A errata do RedHat RHSA-2014-0376 diz que existem bibliotecas corrigidas disponíveis e qualquer pessoa afetada deve atualizar o mais rapidamente possível.

No momento da redação deste artigo, o CentOS ainda não tinha uma versão fixa, mas a postagem de Karanbir Singh no CentOS-Announcement diz que eles produziram uma versão atualizada do openssl ( openssl-1.0.1e-16.el6_5.4.0.1observe os últimos quatro dígitos importantes) que possui o TLS explorável comando desativado e que pode ser aplicado com segurança, pois será substituído por uma versão fixa quando for lançado.

A versão temporariamente corrigida ainda não parece ter atingido todos os espelhos, mas está no repositório principal em http://mirror.centos.org/centos/6/updates/x86_64/Packages/ (e da mesma forma para i686).

Edit : como Iain diz, agora parece haver uma versão totalmente corrigida para o C6.5, e parece ter sido empurrada pelos espelhos com pressa. Um straight yum updateconseguiu para meus servidores; ele é openssl-1.0.1e-16.el6_5.7.

Versões do RH6 e C6 anteriores à 6.5

Estes não são vulneráveis. De acordo com este comunicado da Red Hat ,

Este problema não afetou as versões do openssl fornecidas com o Red Hat Enterprise Linux 5 e o Red Hat Enterprise Linux 6.4 e versões anteriores.

A postagem de Karanbir Singh no CentOS-Announce é igualmente clara sobre o versionamento:

Hoje, no dia anterior, fomos informados de um problema sério no openssl enviado no CentOS-6.5

Debian Wheezy

O Debian emitiu o DSA-2896-1 e as bibliotecas corrigidas estão disponíveis aqui . Um script de shell está disponível aqui .

1. Patch

O repositório Apt-get foi atualizado e agora as bibliotecas corrigidas estão disponíveis via apt-get update && apt-get upgrade

apt-get upgrade libssl1.0.0 openssl

Como alternativa (não recomendado), os pacotes podem ser atualizados manualmente:

wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_amd64.deb

dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u5_amd64.deb

2. Reinicie o servidor / serviços

Para melhor proteção, reinicie o servidor inteiro ou, se o servidor não puder ficar offline, reinicie os serviços necessários.

3. Verifique a versão do OpenSSL

love@server:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
love@server:~$ dpkg -l libssl1.0.0
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-====================================================
ii  libssl1.0.0                 1.0.1e-2+deb7u6  amd64            SSL shared libraries

Gostaria de salientar que as chaves privadas não são os únicos ativos que devem ser considerados comprometidos. O bug pode vazar qualquer memória em execução no mesmo espaço de endereço (ou seja, o mesmo processo) que o OpenSSL. Portanto, se você estiver executando um processo de servidor no qual uma versão vulnerável do OpenSSL está vinculada estaticamente ou dinamicamente, qualquer informação que esse processo já tenha manipulado , incluindo senhas, números de cartão de crédito e outros dados pessoais, deve ser considerada potencialmente comprometida.

FreeBSD 10.0 ou openssl a partir das portas

A equipe de segurança do FreeBSD emitiu um comunicado sobre o CVE-2014-0160 (aka "Heartbleed") e: FreeBSD-SA-14: 06.openssl

1. Atualizando o FreeBSD

   • Atualizando o FreeBSD através de um patch binário

     Os sistemas executando uma versão RELEASE do FreeBSD nas plataformas i386 ou amd64 podem ser atualizados através do utilitário freebsd-update (8):

     # freebsd-update fetch
     # freebsd-update install
     

   • Atualizando o FreeBSD a partir das fontes

     1. Faça o download do patch relevante no local abaixo e verifique a assinatura PGP desanexada usando o seu utilitário PGP.

        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch
        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc
        # gpg --verify openssl-10.patch.asc
        

     2. Execute os seguintes comandos como root:

        # cd /usr/src
        # patch < /path/to/patch
        

     3. Recompile o sistema operacional

        usando buildworld e installworld conforme descrito no manual do FreeBSD .

2. Atualize a porta openssl com a versão mínima 1.0.1_10

3. Reinicie todos os daemons usando a biblioteca ou reinicie o sistema

4. Aja como se o sistema tiver sido comprometida, re-emissão de todas as suas chaves SSL e / ou certificados e informações potencialmente vazado (ver EEAA resposta mais geral).

FreeBSD 9.xe FreeBSD 8.x

Por padrão, esses sistemas não são vulneráveis ao problema do Heartbleed , pois dependem da versão 0.9.x mais antiga da biblioteca openssl , a menos que você tenha instalado o openssl a partir das portas (consulte as etapas acima).

Se esses sistemas não estiverem vulneráveis ​​ao problema do Heartbleed , talvez seja aconselhável atualizar seu sistema mais cedo ou mais tarde devido a outra vulnerabilidade local (consulte FreeBSD-SA-14: 06.openssl e a seção "FreeBSD 10.0" no andar de cima):

Um invasor local pode espionar um processo de assinatura e recuperar a chave de assinatura. [CVE-2014-0076]

Nota :

O comunicado original do Heartbleed lista o FreeBSD 8.4 e 9.1 como potencialmente vulnerável. Isso não é verdade devido à falta de extensão de pulsação (a biblioteca padrão do OpenBSD openssl é a versão 0.9.x).

Achei quase impossível determinar as versões do SSL em uso em vários dispositivos com os quais trabalho. Embora tecnicamente não seja uma atenuação, poder identificar hosts atualmente vulneráveis ​​estava no topo da minha lista.

Montei uma pequena VM que executará verificações em hosts e portas arbitrários usando o módulo de teste do FiloSottile . À primeira vista, o código parece sólido.

O lançamento da VM concluída está aqui . Está no formato VMX.

Palavras de Advertência

Este script e VM mostrarão apenas o status atual dos seus sistemas. É perfeitamente possível que em algum momento no passado seus sistemas estivessem em um estado vulnerável e pudessem ter sido abusados.

Algo aparecendo aqui é definitivamente uma alta prioridade para corrigir, mas isso não o tira do sério para aplicar atualizações e alterar todas as suas chaves.

Amazon Linux (distribuição Linux usada no Amazon EC2)

https://aws.amazon.com/amazon-linux-ami/security-bulletins/ALAS-2014-320/

Visão geral do problema: Uma verificação de limites ausentes foi encontrada na maneira como o OpenSSL lidava com os pacotes de extensão de pulsação TLS. Essa falha pode ser usada para revelar até 64k de memória de um cliente ou servidor conectado.

Versões afetadas: qualquer Amazon Linux AMI no qual o openssl 1.0.1 esteja instalado, qualquer Amazon Linux AMI 2013.03 ou posterior e qualquer Amazon Linux AMI que tenha sido atualizada para 2013.03 ou posterior. O OpenSSL é instalado por padrão na Amazon Linux AMI.

Pacotes afetados: openssl

Correção de problema: Execute yum update openssl para atualizar seu sistema. Após a instalação do novo pacote, é necessário que você reinicie manualmente todos os serviços que estão usando o openssl ou que reinicie sua instância. Embora o novo pacote ainda tenha o nome openssl-1.0.1e, ele contém a correção para o CVE-2014-0160.

Novos pacotes: i686:

openssl-1.0.1e-37.66.amzn1.i686

openssl-static-1.0.1e-37.66.amzn1.i686

openssl-perl-1.0.1e-37.66.amzn1.i686

openssl-devel-1.0.1e-37.66.amzn1.i686

openssl-debuginfo-1.0.1e-37.66.amzn1.i686

x86_64:

openssl-devel-1.0.1e-37.66.amzn1.x86_64

openssl-1.0.1e-37.66.amzn1.x86_64

openssl-debuginfo-1.0.1e-37.66.amzn1.x86_64

openssl-perl-1.0.1e-37.66.amzn1.x86_64

openssl-static-1.0.1e-37.66.amzn1.x86_64