log4j 中 LDAP 查找功能背后的意义
Sense behind the LDAP lookup feature in log4j
最近披露了一个 0-day 漏洞，它使用 security vulnerability in log4j 允许未经授权的远程代码执行。
我想知道，真正的原因是什么，为什么 log4j 实现了这个导致漏洞的 JNDI 查找？
在 log4j 中使用此 LDAP 查找功能的示例是什么？
Log4j 是 Java 中使用的一种流行的日志记录框架（您可以通过查看该漏洞的广泛影响来判断流行程度）。 Log4j 提供了一个特定的功能，您可以在其中将标记添加到您的日志记录字符串中，这些标记会被插值以获取特定数据。例如。 “%d{dd MMM yyyy}”将插入记录消息的日期。
同时，JNDI（Java 命名和目录接口）通常用于将配置设置共享到多个（微）服务。
您可以想象这样一种情况，例如有人想在其中记录配置设置。错误情况。
See this article explaining a bit
A Java based application can use JNDI + LDAP together to find a Business object containing data that it might need. For example, the following URL ldap://localhost:3xx/o=BusinessObjectID to find and invoke theBusinessObject remotely from an LDAP server running on either a same machine (localhost) on port 3xx or remote machine hosted in a controlled environment and goes on to read attributes from it.
update it refers to mentions it as "LOG4J2-313: Add JNDILookup plugin." The motivation is found in the Apache JIRA entry
Currently, Lookup plugins [1] don't support JNDI resources.
It would be really convenient to support JNDI resource lookup in the configuration.
One use case with JNDI lookup plugin is as follows:
I'd like to use RoutingAppender [2] to put all the logs from the same web application context in a log file (a log file per web application context).
And, I want to use JNDI resources look up to determine the target route (similarly to JNDI context selector of logback [3]).
Determining the target route by JNDI lookup can be advantageous because we don't have to add any code to set properties for the thread context and JNDI lookup should always work even in a separate thread without copying thread context variables.
[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 的大问题是，默认情况下，所有模块的所有字符串插值都开启。与此同时，它已成为退出选项，但并非总是如此。
最近披露了一个 0-day 漏洞，它使用 security vulnerability in log4j 允许未经授权的远程代码执行。
我想知道，真正的原因是什么，为什么 log4j 实现了这个导致漏洞的 JNDI 查找？
在 log4j 中使用此 LDAP 查找功能的示例是什么？
Log4j 是 Java 中使用的一种流行的日志记录框架（您可以通过查看该漏洞的广泛影响来判断流行程度）。 Log4j 提供了一个特定的功能，您可以在其中将标记添加到您的日志记录字符串中，这些标记会被插值以获取特定数据。例如。 “%d{dd MMM yyyy}”将插入记录消息的日期。
同时，JNDI（Java 命名和目录接口）通常用于将配置设置共享到多个（微）服务。
您可以想象这样一种情况，例如有人想在其中记录配置设置。错误情况。
See this article explaining a bit
A Java based application can use JNDI + LDAP together to find a Business object containing data that it might need. For example, the following URL ldap://localhost:3xx/o=BusinessObjectID to find and invoke theBusinessObject remotely from an LDAP server running on either a same machine (localhost) on port 3xx or remote machine hosted in a controlled environment and goes on to read attributes from it.
update it refers to mentions it as "LOG4J2-313: Add JNDILookup plugin." The motivation is found in the Apache JIRA entry
Currently, Lookup plugins [1] don't support JNDI resources. It would be really convenient to support JNDI resource lookup in the configuration.
One use case with JNDI lookup plugin is as follows: I'd like to use RoutingAppender [2] to put all the logs from the same web application context in a log file (a log file per web application context). And, I want to use JNDI resources look up to determine the target route (similarly to JNDI context selector of logback [3]).
Determining the target route by JNDI lookup can be advantageous because we don't have to add any code to set properties for the thread context and JNDI lookup should always work even in a separate thread without copying thread context variables.
[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 的大问题是，默认情况下，所有模块的所有字符串插值都开启。与此同时，它已成为退出选项，但并非总是如此。