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

Question

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

最近，一个 0day 漏洞被披露，该漏洞利用了log4j 中的安全漏洞，允许未经授权的远程代码执行。

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

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

Answer 1

Log4j 是 Java 中使用的一种流行的日志框架（您可以通过查看该漏洞的广泛影响来计算流行程度）。Log4j 提供了一项特定功能，您可以在其中将标记添加到日志记录字符串中，然后对其进行插值以获取特定数据。例如，“%d{dd MMM yyyy}”将插入记录消息的日期。

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

您可以想象这样一种情况：有人想要在错误情况下记录配置设置。

看这篇文章稍微解释一下

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

它引用的更新将其称为“LOG4J2-313：添加 JNDILookup 插件”。动机可以在Apache JIRA 条目中找到

目前，Lookup 插件 [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 的一个大问题是，默认情况下所有模块的所有字符串插值都是打开的。与此同时，它已成为选择退出，但情况并非总是如此。

我真正不明白的是 JNDI 允许访问_任意 LDAP 服务器_ - 可以为你的进程提供 _jar 文件来为你执行！_ - 通过_运行时字符串！_ 至少它应该受到 JVM 配置参数的限制 - 如果您想要不同的 LDAP 服务器，则必须将其添加到配置中并重新启动 JVM。无论如何，允许访问_任意_运行时确定的 LDAP 服务器的用例是什么？哦，顺便说一句，允许 LDAP 服务器提供任意 jar 供您执行？为什么这本身就是一个好主意？ (8认同)
也许我还是不太明白。但不知怎的，我仍然想知道这样一个特殊的需求，只对极少数用户有帮助，怎么可能会进入log4j。Log4j 是一个非常通用的日志库，这是一个非常具体的功能，可以由他们自己轻松实现，他们确实需要这样一个专门的东西。 (3认同)
@eztam：Web应用程序经常进行JNDI查找来检索配置参数、数据源和其他对象（例如[Spring就是这样做的](https://docs.spring.io/spring-boot/docs/current/reference/html/features .html#features.external-config))，因为无法针对每个应用程序自定义系统属性。然而，通常只允许“java:comp/env”查找。这里出现的严重错误是还允许“ldap:”查找。我相信那是无意的。 (2认同)

归档时间：	4 年，8 月前
查看次数：	5570 次
最近记录：	4 年，8 月前