Como corrigir a vulnerabilidade do OpenSSL Padding Oracle (CVE-2016-2107) para o nginx no debian jessie?

2

Tanto quanto eu entendi, deve ser suficiente para atualizar o openssl (feito há muito tempo, agora instalado todas as atualizações disponíveis novamente (sem openssl lá)) e reinicie o nginx. Eu até tentei parar completamente o nginx (verifiquei com ps ) e comecei novamente.

Mas o ssllabs ainda me diz que estou vulnerável. O que mais eu preciso fazer, ou o que pode estar causando que ainda é vulnerável?

versões:

ii  nginx                              1.9.10-1                          all          small, powerful, scalable web/proxy server
ii  nginx-common                       1.9.10-1                          all          small, powerful, scalable web/proxy server - common files
ii  nginx-full                         1.9.10-1                          amd64        nginx web/proxy server (standard version)
ii  openssl                            1.0.1t-1+deb8u2                   amd64        Secure Sockets Layer toolkit - cryptographic utility

ii  libssl-dev:amd64                   1.0.1t-1+deb8u2                   amd64        Secure Sockets Layer toolkit - development files
ii  libssl-doc                         1.0.1t-1+deb8u2                   all          Secure Sockets Layer toolkit - development documentation
ii  libssl1.0.0:amd64                  1.0.1t-1+deb8u2                   amd64        Secure Sockets Layer toolkit - shared libraries
ii  libssl1.0.2:amd64                  1.0.2f-2                          amd64        Secure Sockets Layer toolkit - shared libraries

lsof relacionado ao nginx

lsof 2>/dev/null |grep -i libssl|grep nginx
nginx     17928              root  mem       REG              251,0    430560    2884885 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
nginx     17929          www-data  mem       REG              251,0    430560    2884885 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
nginx     17930          www-data  mem       REG              251,0    430560    2884885 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
nginx     17932          www-data  mem       REG              251,0    430560    2884885 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
nginx     17933          www-data  mem       REG              251,0    430560    2884885 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
    
por allo 08.07.2016 / 22:44

3 respostas

2

Eu entendi.

Instalei certbot do debian unstable, que instalou 1.0.2f-2 . unstable é fixado na prioridade "-100" (não instale da unstable a menos que seja solicitado com -t unstable ). Isso significa que a versão está entre a versão de jessie 1.0.0X-Y e a versão instável atual 1.0.2.h-1 . Isso impediu uma atualização para a próxima versão na unstable, enquanto a atualização na stable é uma versão "antiga" em relação ao número da versão.

    
por 09.07.2016 / 12:59
1

Instalar as atualizações necessárias (como sugerido por link nos comentários) parece corrigir o problema para mim.

apt-get update && apt-get upgrade
    
por 23.08.2016 / 17:34
0

Eu tive um problema semelhante em um servidor Wheezy do Debian. O link sempre mostrou que meu servidor estava vulnerável ao CVE-2016-2107. Outros servidores, com (na minha opinião) a mesma configuração, não tinham esse problema de segurança.

openssl, apache, php - todas as mesmas versões e mesma configuração.

Após algumas investigações descobri que o mod_spdy foi instalado e ativado neste servidor em particular.

Depois de desinstalar o mod_spdy, o problema foi resolvido.

dpkg -r mod-spdy-beta 
dpkg -P mod-spdy-beta

de link

    
por 02.08.2016 / 13:36