我们已经在运行Apache 2.4。*的64位Windows服务器上安装了OpenSSL 1.1.1d。直到最近（2020年1月），当我们的每日PCI扫描失败并带有以下摘要时，一切都工作正常：远程服务受多个漏洞的影响。显然，对我而言，自然的事情是升级到OpenSSL的最新版本，当我检查https://www.openssl.org/时，发现1.1.1d是最新版本，为了安全起见，我仍然重新安装了它。这没有做任何更改，扫描仍然失败。
扫描报告底部有一个较长的段落，提供了有关影响的更多详细信息，此文本引起了我的注意...
*"OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time".*
外面有人可以帮助我了解阻止此故障的必要措施吗？我在互联网上四处张望，没有人在与我相同的情况下报告此问题。请帮助！
问题的更新-添加了完整的参考参数
影响远程主机上安装的测试产品的版本早于测试版本。因此，它受以下漏洞的影响：-通常，在OpenSSL EC中，组始终存在一个辅助因子，并且该辅助因子用于抵抗旁通道的代码路径中。但是，在某些情况下，可以使用显式参数（而不是使用命名曲线）来构造组。在那些情况下，这样的基团可能不存在辅因子。即使所有参数都匹配已知的命名曲线，也会发生这种情况。如果使用这样的曲线，则OpenSSL会退回到非旁通道抗性代码路径，这可能会导致ECDSA签名操作期间的完全密钥恢复。为了变得容易受攻击，攻击者将不得不具有定时创建大量签名的能力，其中使用libcrypto的应用程序正在使用不存在辅助因子的显式参数。为了避免疑问，libssl不会受到攻击，因为从不使用显式参数。 OpenSSL版本1.1.1、1.1.0和1.0.2受此问题影响。 （CVE-2019-1547）-OpenSSL 1.1.1引入了重写的随机数生成器（RNG）。旨在在fork（）系统调用的情况下提供保护，以确保父进程和子进程不会共享相同的RNG状态。但是，默认情况下未使用此保护。此问题的部分缓解措施是，高精度计时器的输出被混合到RNG状态，因此父子进程共享状态的可能性大大降低。如果应用程序已经使用OPENSSL_INIT_ATFORK显式调用OPENSSL_init_crypto（），则根本不会发生此问题。 OpenSSL版本1.1.1受此问题影响。 （CVE-2019-1549）-OpenSSL具有目录树的内部默认值，该目录树可以在其中找到配置文件以及用于TLS验证的证书。该目录最通常称为OPENSSLDIR，并且可以使用--prefix / --openssldir配置选项进行配置。对于OpenSSL版本1.1.0和1.1.1，mingw配置目标假定将结果程序和库安装在类似Unix的环境中，并且程序安装以及OPENSSLDIR的默认前缀应为'/ usr / local'。但是，mingw程序是Windows程序，因此，他们发现自己在寻找'C：/ usr / local'的子目录，这些子目录可能是世界可写的，从而使不受信任的用户可以修改OpenSSL的默认配置，插入CA证书，修改（甚至替换掉）现有的引擎模块等。对于OpenSSL 1.0.2，在所有Unix和Windows目标（包括Visual C构建）上，OPENSSLDIR都将默认使用'/ usr / local / ssl'。但是，针对1.0.2的各种Windows目标的一些构建说明鼓励您指定自己的--prefix。 OpenSSL版本1.1.1、1.1.0和1.0.2受此问题影响。由于受影响的部署范围有限，因此其严重程度被评估为低，因此我们目前不创建新版本。 （CVE-2019-1552）请注意，SecurityMetrics尚未针对这些问题进行测试，而是仅依赖于应用程序的自报告版本号。另请参阅：http://www.nessus.org/u?c46dca59https://www.openssl.org/news/secadv/20190910.txthttps://www.openssl.org/news/secadv/20190730.txt
这是一个误报。您需要与供应商提起争议，向他们证明版本1.1.1d在其他版本中没有发现漏洞。所有PCI扫描供应商都有一个对误报提出异议的程序。如果他们同意您的争议结果，他们将从您的报告中删除该漏洞。他们应该为您快速解决此问题。发送给他们https://www.openssl.org/news/secadv/20190910.txt，以及您所拥有的实际版本的证据。