Как исправить уязвимость OpenSSL Padding Oracle (CVE-2016-2107) для nginx на debian jessie?

Насколько я понял, этого должно быть достаточно для обновления openssl (сделано давно, теперь снова установлены все доступные обновления (там нет openssl)) и перезапустить nginx. Я даже попытался полностью остановить nginx (проверил его с помощью ps ) и запустить его снова.

Но ssllabs по-прежнему говорит мне, что я уязвим. Что еще мне нужно сделать или что может быть причиной того, что он все еще уязвим?

версии:

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, связанный с 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
2
задан 9 July 2016 в 13:18
3 ответа

Я понял.

Я установил certbot из debian unstable, который установил 1.0.2f-2 . unstable привязан к приоритету "-100" (не устанавливайте из нестабильного, если не запрошено с помощью -t unstable ). Это означает, что версия находится между версией jessie 1.0.0X-Y и текущей нестабильной версией 1.0.2.h-1 . Это предотвратило обновление до следующей версии в нестабильной версии, в то время как обновление в стабильной версии является «более старой» версией по отношению к номеру версии.

2
ответ дан 3 December 2019 в 10:37

У меня была аналогичная проблема на сервере Debian Wheezy. https://www.ssllabs.com/ssltest/ всегда показывал, что мой сервер был уязвим для CVE-2016-2107. Другие серверы с (на мой взгляд) такой же конфигурацией не имели этой проблемы с безопасностью.

openssl, apache, php - все те же версии и та же конфигурация.

После некоторого расследования я обнаружил, что mod_spdy был установлен и активирован на этом конкретном сервере.

После удаления mod_spdy проблема была решена.

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

из https://stackoverflow.com/questions/25593257/how-do-i-remove-spdy-mod-spdy

0
ответ дан 3 December 2019 в 10:37

Установка необходимых обновлений (как было предложено https://serverfault.com/users/126632/michael-hampton в комментариях), похоже, решила проблему для меня. .

apt-get update && apt-get upgrade
1
ответ дан 3 December 2019 в 10:37

Теги

Похожие вопросы