OpenSSL 1.1.1 < 1.1.1d 多个漏洞导致 PCI 扫描失败？
OpenSSL 1.1.1 < 1.1.1d Multiple Vulnerabilities causing PCI Scan failure?
我们在 windows 服务器 64 位 运行 Apache 2.4 上安装了 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?c46dca59 https://www.openssl.org/news/secadv/20190910.txt https://www.openssl.org/news/secadv/20190730.txt
这是误报。您需要向供应商提出争议，向他们表明 1.1.1d 版本没有在其他版本中发现的漏洞。所有 PCI 扫描供应商都有一个对误报提出异议的流程。如果他们同意您的争议结果，他们将从您的报告中删除该漏洞。他们应该会尽快为您解决此问题。向他们发送 https://www.openssl.org/news/secadv/20190910.txt，以及您拥有的实际版本的证据。
由于 Kapish M and Rodrigo M 的回复，我现在不得不回答我自己的问题，他们为我提供了重要信息并引导我走上了正确的道路。
事实证明，安装在 windows 服务器上的 OpenSSL 版本不会取代作为 XAMPP 的一部分安装的 Apache 包的 OpenSSL 版本。 Vulnerability Scanner 扫描 Apache 内部的 OpenSSL（或者可能两者都有，但绝对是 apache 内部）。
我在服务器版本 1.1.1d 上安装的 OpenSSL 完全独立于 XAMPP 包的一部分（在我的例子中 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 通过了。
- 在服务器上安装最新版本的 OpenSSL
- 导航到 Binaries 文件夹的位置，即 YourDrive:\Program Files\OpenSSL-Win64\bin
- 复制以下文件（此文件列表归功于 Edmoncuaft）
- libcrypto-1_1.dll
- libssl-1_1.dll
- openssl.exe
- 导航到您的 Apache 二进制文件文件夹
- 你的驱动器：xampp\apache\bin
[非常重要] 创建步骤 3 中提到的 3 个文件的备份副本，以备不时之需。
停止 Apache 服务器
将 YourDrive:\Program Files\OpenSSL-Win64\bin 中的 3 个文件复制到 YourDrive:xampp\apache\bin
（重新）启动 Apache 服务器
这些是我遵循的步骤，当我们再次 运行 PCI 扫描时，它通过了，没有漏洞！
我希望这对其他人有用。
我们在 windows 服务器 64 位 运行 Apache 2.4 上安装了 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?c46dca59 https://www.openssl.org/news/secadv/20190910.txt https://www.openssl.org/news/secadv/20190730.txt
这是误报。您需要向供应商提出争议，向他们表明 1.1.1d 版本没有在其他版本中发现的漏洞。所有 PCI 扫描供应商都有一个对误报提出异议的流程。如果他们同意您的争议结果，他们将从您的报告中删除该漏洞。他们应该会尽快为您解决此问题。向他们发送 https://www.openssl.org/news/secadv/20190910.txt，以及您拥有的实际版本的证据。
由于 Kapish M and Rodrigo M 的回复，我现在不得不回答我自己的问题，他们为我提供了重要信息并引导我走上了正确的道路。
事实证明，安装在 windows 服务器上的 OpenSSL 版本不会取代作为 XAMPP 的一部分安装的 Apache 包的 OpenSSL 版本。 Vulnerability Scanner 扫描 Apache 内部的 OpenSSL（或者可能两者都有，但绝对是 apache 内部）。
我在服务器版本 1.1.1d 上安装的 OpenSSL 完全独立于 XAMPP 包的一部分（在我的例子中 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 通过了。
- 在服务器上安装最新版本的 OpenSSL
- 导航到 Binaries 文件夹的位置，即 YourDrive:\Program Files\OpenSSL-Win64\bin
- 复制以下文件（此文件列表归功于 Edmoncuaft）
- libcrypto-1_1.dll
- libssl-1_1.dll
- openssl.exe
- 导航到您的 Apache 二进制文件文件夹
- 你的驱动器：xampp\apache\bin
[非常重要] 创建步骤 3 中提到的 3 个文件的备份副本，以备不时之需。
停止 Apache 服务器
将 YourDrive:\Program Files\OpenSSL-Win64\bin 中的 3 个文件复制到 YourDrive:xampp\apache\bin
（重新）启动 Apache 服务器
这些是我遵循的步骤，当我们再次 运行 PCI 扫描时，它通过了，没有漏洞！
我希望这对其他人有用。