OpenSSL 1.1.1 < 1.1.1d 多个漏洞导致 PCI 扫描失败？

Question

我们在运行 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，“/usr/local/ssl”在所有 Unix 和 Windows 目标（包括 Visual C 构建）上用作 OPENSSLDIR 的默认值。但是，针对 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

Answer 1

感谢Kapish M 和Rodrigo M 的回复，我现在不得不回答我自己的问题，他们给了我重要的信息并带领我走上了正确的道路。

事实证明，安装在 Windows 服务器上的 OpenSSL 版本不会取代 OpenSSL 版本，后者是作为 XAMPP 的一部分安装的 Apache 捆绑包的一部分。漏洞扫描程序针对 Apache 内部的 OpenSSL 进行扫描（或者可能两者兼有，但绝对是 apache 之一）。

我在服务器版本 1.1.1d 上安装的 OpenSSL 与 XAMPP 包中的 OpenSSL 完全分开（在我的情况下为 1.1.1c ）。我发现的问题是，尽管拥有最新版本的 Apache 2.2.41，但随附的 OpenSSL 版本并不是最新版本的 OpenSSL，并且没有官方记录的更新方式XAMPP 包中的 OpenSSL。事实上，XAMPP 官方网站确实表示他们还没有为 Windows 准备好 1.1.1d，除了 Linux（在给出这个答案时是正确的）https://www.apachefriends.org/blog/new_xampp_20191227.html 明确表示 OpenSSL 1.1。 1d（仅限 UNIX）。

以下是我在通过收到的回复有了更好的理解后为解决我的问题所做的事情。我仍然不确定我的方法是否安全，因为这不是我的专业领域，但它肯定让我的 PCI-Scan 通过了。

1. 在服务器上安装了最新版本的 OpenSSL
2. 导航到 Binaries 文件夹的位置，即 YourDrive:\Program Files\OpenSSL-Win64\bin
3. 复制以下文件（此文件列表归功于Edmoncuaft）
   • libcrypto-1_1.dll
   • libssl-1_1.dll
   • openssl.exe
4. 导航到您的 apache 二进制文件文件夹
   • 你的驱动器：xampp\apache\bin

5. [非常重要]创建步骤 3 中提到的 3 个文件的备份副本，以备您需要恢复时使用。

6. 停止 Apache 服务器

7. 将 3 个文件从 YourDrive:\Program Files\OpenSSL-Win64\bin 复制到 YourDrive:xampp\apache\bin

8. （重新）启动 Apache 服务器

这些是我遵循的步骤，当我们再次运行 PCI 扫描时，它通过了，没有漏洞！

我希望这对其他人有用。

Answer 2

这是一个误报。您需要向供应商提出争议，向他们表明 1.1.1d 版本没有在其他版本中发现的漏洞。所有 PCI 扫描供应商都有处理误报的流程。如果他们同意您的争议结果，他们将从您的报告中删除该漏洞。他们应该很快为您解决这个问题。向他们发送https://www.openssl.org/news/secadv/20190910.txt，以及您拥有的实际版本的证据。