log4j 中 LDAP 查找功能背后的意义

Posted 2023-02-18

【中文标题】log4j 中 LDAP 查找功能背后的意义

【英文标题】：Sense behind the LDAP lookup feature in log4j

【发布时间】：2022-01-19 08:28:16

【问题描述】：

最近披露了一个 0-day 漏洞利用，该漏洞使用security vulnerability in log4j，允许未经授权的远程代码执行。

我想知道，真正的原因是什么，为什么 log4j 实现了这个 JNDI 查找，这完全导致了漏洞？

在 log4j 中使用此 LDAP 查找功能的示例是什么？

【参考方案1】：

Log4j 是 Java 中使用的流行日志框架（您可以通过查看漏洞的广泛影响来了解其流行程度）。 Log4j 提供了一个特定的功能，您可以在其中将标记添加到您的日志记录字符串中，这些标记被插值以获取特定数据。例如。 "%ddd MMM yyyy" 将插入记录消息的日期。

与此同时，JNDI（Java 命名和目录接口）通常用于将配置设置共享给多个（mirco）服务。

您可以想象有人想记录配置设置的情况，例如错误情况。

See this article explaining a bit

基于 Java 的应用程序可以一起使用 JNDI + LDAP 来查找包含它可能需要的数据的业务对象。例如，以下 URL ldap://localhost:3xx/o=BusinessObjectID 可从运行在端口 3xx 上的同一台计算机 (localhost) 或托管在受控环境中的远程计算机上的 LDAP 服务器远程查找和调用 BusinessObject，然后继续从中读取属性。

update it refers to 将其称为“LOG4J2-313：添加 JNDILookup 插件”。动机在Apache JIRA entry

目前，查找插件 [1] 不支持 JNDI 资源。 在配置中支持JNDI资源查找真的很方便。

使用 JNDI 查找插件的一个用例如下： 我想使用 RoutingAppender [2] 将来自同一 Web 应用程序上下文的所有日志放在一个日志文件中（每个 Web 应用程序上下文的日志文件）。 并且，我想使用 JNDI 资源查找来确定目标路由（类似于 logback [3] 的 JNDI 上下文选择器）。

通过 JNDI 查找确定目标路由可能是有利的，因为我们不必添加任何代码来设置线程上下文的属性，而且 JNDI 查找即使在单独的线程中也应该始终可以工作，而无需复制线程上下文变量。

[1]http://logging.apache.org/log4j/2.x/manual/lookups.html [2]http://logging.apache.org/log4j/2.x/manual/appenders.html#RoutingAppender [3]http://logback.qos.ch/manual/contextSelector.html

log4j 的一个大问题是，默认情况下所有模块的所有字符串插值都打开。与此同时，它已成为选择退出，但并非总是如此。

【讨论】：

也许我还是不明白。但不知何故，我仍然想知道这样一个只对极少数用户有帮助的特殊要求，怎么会变成 log4j。 Log4j 是一个非常通用的日志库，这是一个非常具体的功能，他们自己可以轻松实现，他们真的需要这样一个专门的东西。

@eztam 你有使用开源库的经验吗？事情就是这样发展的。 2013 年，当它被添加时，他们对这个添加感到满意。作者提出了它，但自己无法添加。相反，该补丁是由 Apache 日志服务副总裁 Ralph Goers 添加的。

@eztam：Web 应用程序经常执行 JNDI 查找以检索配置参数、数据源和其他对象（例如 Spring does it），因为无法为每个应用程序自定义系统属性。但是通常只允许java:comp/env 查找。这里出现的严重错误是还允许ldap: 查找。我相信那是无意的。

@PiotrP.Karwasz 感谢您的解释。现在这完全有道理。

我真正不明白的是 JNDI 允许访问 任意 LDAP 服务器的原因 - 它可以提供 jar 文件供您的进程执行你！ - 通过 运行时字符串！ 至少它应该被限制为 JVM 配置参数 - 你想要一个不同的 LDAP 服务器，你必须添加它配置并重新启动您的JVM。无论如何，允许访问 任意 运行时确定的 LDAP 服务器的用例是什么？哦，顺便说一句，允许 LDAP 服务器生成一个任意 jar 供您执行？为什么这本身是个好主意？