我有一个非常旧的Solr版本,并且一直在尝试查看它是否受到了每个人都在担心的Log4Shell漏洞(CVE-2021-44228)的影响。
CVE似乎只适用于较新的版本,但同事不相信,因此我正在努力找出真相。
我有一个非常旧的Solr版本,并且一直在尝试查看它是否受到了每个人都在担心的Log4Shell漏洞(CVE-2021-44228)的影响。
CVE似乎只适用于较新的版本,但同事不相信,因此我正在努力找出真相。
我大约有95%的把握认为这对于旧版本的Log4j是可以的。原因如下:
I'm on version 1.2. I found the Log4j JAR file on my system, unzipped it, and looked for anything mentioning JNDI:
find / -iname '*log4j*'
unzip /etc/opt/jetty/lib/ext/log4j-1.2.17.jar | grep -i jndi
That brought back nothing, so I feel pretty good there. The CVE says that you'd normally find something by looking in the JAR file. It suggests you do:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
That wouldn't do anything for me.
I dug through the changelog for Log4j. It says for version 2.0-beta9:
Add JNDILookup plugin. Fixes LOG4J2-313. Thanks to Woonsan Ko.
So I think it's safe to say that JNDI didn't exist in Log4j before then. The Jira ticket that added it is here.
I checked the old manual for version 1.2 and compared it to the latest version. In the latest, there's a section for "Lookups" that explains how JNDI works. In version 1.2, that section just isn't there.
我认为这个...还可以吧?
这个漏洞有两个方面。
- Log4j 2的查找机制(属性解析器)被执行在被记录日志的消息文本上。这意味着,如果应用程序记录用户输入(几乎所有人都这样做),则用户可以使查找机制被调用。
- Log4j 2在各个地方支持JNDI,包括作为查找。JNDI本身非常不安全。这些的联合效果是使其成为Log4j 2的关键性问题。Log4j 1和Logback都有使用JNDI的组件,并且两者都没有采取任何措施来限制JNDI的漏洞。在Log4j 1的情况下,这是JMS Appender。暴露面较小但仍然存在。如果某人能够访问日志记录配置,则可能会导致糟糕的结果。
因此,结论是Log4J 1.x是安全的,没有受到Log4Shell的影响,除非您使用JMS appender。在这种情况下,您必须分析在appender中所做的内容。
JMSAppender
。请参见https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 - Maksim