OpenSSL 1.0.1j - Correção de vulnerabilidade "POODLE" (upgrade) no RHEL 6.5

Question

Eu tenho um problema quando atualizei meu OpenSSL no RHEL 6.5. O OpenSSL está faltando a biblioteca libcrypto.so.10 . Em vez disso, o openssl 1.0.1j created lib é libcrypto.so.1.0.0 . Fiz um link flexível, mas ainda não funciona para outros pacotes usando libcrypto.so.10 .

Alguém tem experiência com esse problema?

Explicação (adendo / edição): isso é uma informação necessária, já que muitos estarão procurando usar a versão 1.0.1j diretamente do pacote OpenSSL para escapar do último (2014.10.15) "POODLE" vulnerabilidade no OpenSSL. Se você pegar o arquivo tar.gz do openssl.org neste momento, você não deve ter um problema. Anteriormente, havia um problema por um curto período de tempo e essa publicação ainda pode existir em outros sites, portanto, evite baixar o arquivo diferente de openssl.org: downloads do openssl .

Por favor, leia o aviso SSL3 na resposta @jvp sobre os RPMs, uma vez que as atualizações não resolvem completamente os problemas do servidor que surgem quando os servidores permitem tais conexões. Uma discussão sobre essa vulnerabilidade adicional pode ser encontrada em: divisão ncas de us-cert.gov

Veja a resposta sobre o uso de RPMs baseados em Red Hat para EL6 e EL7.

Olhe para o diretório /usr/lib para 32 bits e /usr/lib64 para 64 bits e o layout deve ser o seguinte:

• libcrypto.a
• libcrypto.so - > libcrypto.so.1.0.1j
• libcrypto.so.10 - > libcrypto.so.1.0.1j
• libcrypto.so.1.0.1j
• .libcrypto.so.1.0.1j.hmac
• .libcrypto.so.10.hmac - > .libcrypto.so.1.0.1j.hmaclibssl.a
• libssl.so - > libssl.so.1.0.1j
• libssl.so.10 - > libssl.so.1.0.1j
• libssl.so.1.0.1j
• .libssl.so.1.0.1j.hmac
• .libssl.so.10.hmac - > .libssl.so.1.0.1j.hmac

Existem também os subdiretórios openssl e package do lib, mas estes nunca foram um problema.

    

Answer 1

Os RPMs estão disponíveis para RHEL [6 | 7] e irmãos (isto é, CentOS et al.) e estão disponíveis via yum na maioria dos repositórios.

Observe que esses RPMs abordam uma parte das vulnerabilidades "POODLE" por:

• CVE-2014-3567,
• CVE-2014-3566 e
• CVE-2014-3513

VEJA: cert.gov

A atualização de segurança não resolve alguns problemas SSLv3 específicos, portanto, aqueles com servidores sendo atualizados devem remover qualquer possibilidade de clientes se conectarem usando este protocolo e - especificamente - métodos CBC.

Remover o SSL3 das configurações do servidor é muito fácil de fazer:

NGINX / TENGINE:

• adicione / substitua ssl_protocols TLSv1 TLSv1.1 TLSv1.2; no http seção de configuração e
• certifique-se de que a diretiva 'ssl_protocols' é não sobrecarregado em qualquer seção do servidor.

Se você encontrar alguma diretiva de servidor, apenas remova-a e deixe o 'HTTP' governar ... como deveria, de qualquer maneira.

APACHE:

• adicione / substitua SSLProtocol All -SSLv2 -SSLv3 na seção de configuração SSL global e
• como no Nginx, verifique seus vhosts.

Como no OpenSSL snafus anterior, em vez de emitir novos números de RPM para corresponder ao número de versão do OpenSSL atualizado (1.0.1j), o .rpm tem um patch retornado para a última extensão .rpm da distro; que é 1.0.1e (para distribuições baseadas em RHEL) e está totalmente versionado - como neste momento - como 1.0.1e-30.[variable by specific machine version] .

Então, pegando o CentOS 6 de 64 bits como exemplo, o .rpm que você obterá será openssl-1.0.1e-30.el6_5.2.x86_64.rpm .

Como acontece com qualquer atualização do OpenSSL, qualquer coisa que dependa do OpenSSL, como servidores da Web, VPNs e semelhantes, deve ser reiniciada no servidor antes que a atualização entre em ação.

    

Answer 2

wget http://www.openssl.org/source/openssl-1.0.1j.tar.gz
tar -xvf openssl-1.0.1j.tar.gz
cd openssl-1.0.1j
./config --prefix=/usr no-threads shared
make
make test
make install

openssl version