该 CVE 不会影响端口，只会影响 Log4j，因为它需要使用 Java 接口（并且某些 JVM 版本会阻止漏洞被利用）。这些端口可能具有类似的漏洞，但它们的性质可能大不相同，因此我们会为它们发布不同的 CVE，以帮助区分漏洞、修补和修复步骤。

让我从一些背景信息开始。据我了解，CVE-2021-44228（“Log4Shell”）漏洞具有三个主要组成部分：

1. Log4j 中的一个设计缺陷（默认情况下，在版本 2.15.0 之前）解析和扩展由${和分隔的某些子字符串}，称为查找，不仅在硬编码格式模式中，而且实际上在所有记录的数据中，包括提供为的任何用户输入参数。这是推荐的缓解技术（升级到 2.15.0+ 或log4j2.formatMsgNoLookups在版本 2.10.0+ 中设置为 true）解决的部分。

2. 一个名为 的特定查找jndi，默认启用，它允许使用JNDI（Java 命名和目录接口™）API 使用LDAP等协议从任意远程源加载数据。对于旧的 2.10.0 之前的 Log4j 版本，一些替代缓解技术（例如此 Java 代理修补程序）通过禁用此查找来工作。

3. 如果给定合适的输入数据，Java LDAP 实现中的错误和/或设计缺陷使其容易受到远程代码执行的影响。有已知的方法可以缓解这些问题，但显然攻击面很广，很难完全消除。

使用 JNDI + LDAP 进行远程代码执行的可能性实际上已经有一段时间了；上面的最后一个链接是 2016 年讨论它的演示文稿。至少自 2017 年以来，在 2.10.0 版本中添加了关闭它的选项时，对 Log4j 中所有记录数据的查找应用不当的问题也已为人所知。但显然它当时并不被认为是一个主要的安全问题（尽管 IMO 它应该是），因为没有jndi查找的能力，它允许所有外部请求（！）它允许是一种有限的日志伪造形式。

正是所有这三个缺陷的结合，才允许将这种易于使用但有限的日志伪造漏洞利用（第 1 部分）提升为易于使用的远程代码执行漏洞利用（第 2 部分和第 3 部分）。

（此外，一旦 RCE 漏洞被广为人知，人们发现第 1 部分和第 2 部分也可用于在远程请求中泄露敏感数据，例如存储在环境变量中的私钥，而实际上不需要第 3 部分中的 RCE 漏洞。但是 AFAIK 这只是在 RCE 已知后的过去几天里才被发现或至少公开的。）

无论如何，所有这一切的结果是 log4j 端口到其他语言可能具有相同的设计缺陷（上面的第 1 部分），允许在用户输入中解析查找。但是，JNDI（第 2 部分）特定于 Java，因此当前形式的完整 RCE 漏洞利用不太可能在 log4j 端口上运行到非 Java 系统。

当然，我仍然认为解析不受信任的日志数据中的任何字符串替换是一个安全漏洞，并且至少是一个潜在的漏洞利用点。给定一个潜在易受攻击的系统，您应该能够通过输入如下字符串来测试其对 log4j 样式查找漏洞利用的漏洞：

TEST ${upper:foo} ${env:HOME:~} ${date:MM-dd-yyyy} ${base64:SGVsbG8gV29ybGQhCg==} $${foo}

它将被记录的地方。如果记录的所有内容都是没有更改的逐字输入字符串，那么您的系统可能不会受到攻击。但是，如果任何${}块在日志中被替换为其他内容，或者如果$$变成$或出现任何其他更改，您应该尽快向端口的维护人员报告，并在修复之前寻找方法在本地更改此行为，例如通过配置。

根据发布常见漏洞的CVE 站点，它表示它通过 JNDI 配置影响 Log4J。

JNDI 是 – Java Naming and Directory Interface™ (JNDI) 是一个应用程序编程接口 (API)，它为使用 Java™ 编程语言编写的应用程序提供命名和目录功能。

由于在 .Net 应用程序中我们不使用 Java 或其运行时，因此此漏洞不会影响 .Net 世界。