Preface
A tweet last night attracted considerable attention in the security community.
Log4j 2.17.0 has RCE!!
But then:
The security community mostly scoffed…
RCE by modifying a configuration file—is that all?
So how did configuration-file RCE become fashionable?
Because
The story begins with Log4j 2 RCE.
There is a pull request in the Log4j 2 GitHub repository:https://github.com/apache/logging-log4j2/pull/608
A researcher named TopStreamsNet noted:
If you examine how JNDI works in 1.x, lookups occur at JMSAppender.java:207 and JMSAppender.java:222. Set TopicBindingName or TopicConnectionFactoryBindingName to a value JNDI can process—such as ldap://host:port/a—and JNDI behaves exactly as in 2.x. So 1.x is vulnerable; the attack vector is merely safer because it depends on configuration rather than user input.
That started a broader discussion about achieving RCE through configuration files.
The Log4j 2 maintainer replied in particular:
If an attacker can modify a configuration file on system S, then S can be assumed to be substantially compromised. If an attacker can modify log4j.properties (Log4j 1.x), they do not need to download malicious code; they can place a malicious class on the classpath and execute it. Thus, in an extremely strict sense Log4j 1.x has an issue, but it has nothing to do with RCE caused by logging parameters.
The Log4j 2 maintainer clearly did not initially agree with the researcher's view. Then things became interesting.
Just when everyone thought this was not a vulnerability, Red Hat entered the scene:
https://access.redhat.com/security/cve/CVE-2021-4104
They classified this configuration-file RCE as a vulnerability and assigned it a CVSS v3 score of 7.5 (Medium)!
Someone then replied under that Log4j 2 pull request:
Bystander: Look, Red Hat assigned a CVE and gave it a 7.5 score! (It was initially 8.0.)
Of course, someone also replied:
Bystander: Come on, Red Hat. The Log4j maintainers have not even spoken—why are you stirring this up?
Under pressure, the Log4j project eventually accepted the CVE.
We decided to retain the CVE assigned by Red Hat, saving the effort of creating another and rejecting theirs.
Log4j project: Fine, fine—we accept it.
Thus, Red Hat turned the first configuration-file RCE discussed in a Log4j pull request into a CVE.
cause
Before this CVE was published, I had already investigated the claim made by a researcher named TopStreamsNet:
Discussion of Low-Impact RCE in Log4j 1.x and Logback: /sec/1131.html
I also found that configuration-file RCE in Log4j 1.x does not take effect immediately. The configuration must be reloaded, and who voluntarily restarts or reloads it in production? Logback differs because it has a scan property, which automatically detects changes and reloads the configuration. During my research I published a Spring Boot demonstration on GitHub.
Coincidentally, I saw a Logback issue asking whether it was affected by the Red Hat vulnerability. I replied with the Spring Boot demo. The Logback maintainer later assigned CVE-2021-42550 and emailed to ask whether I wanted credit.
The researcher was helpful, but I believe the issue is severely constrained, and @Xiangyixiangwei had already proposed this exploitation method a year earlier:
So I declined the credit.
Later, through @TiGer Xiangyixiangwei noted that exploitation of this Logback issue had appeared in a real-world example:
For reference:https://www.cnblogs.com/zpchcbd/p/15542705.html
Conclusion
Looking back at the Log4j 2.17.0 configuration-file RCE, the classification does seem excessive. Unlike Logback, a modified configuration does not take effect immediately, making an already limited issue even less practical.
In fact, @pwntester also said:
Most Java applications that use a database have a configuration file where a JNDI address can be specified to obtain a JDBC data source.
Applications whose configuration can use JNDI include:
jetty https://wiki.eclipse.org/Jetty/Feature/JNDI#Configuring_JMS_Queues.2C_Topics_and_ConnectionFactories
Apache ODE https://ode.apache.org/using-a-jndi-datasource-under-servicemix-jbi.html
Apache Shrio https://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/jndi/JndiTemplate.html https://www.programmerall.com/article/1371213168/
Tomcat https://tomcat.apache.org/tomcat-8.0-doc/jndi-datasource-examples-howto.html
**TomEE ** https://tomee.apache.org/jndi-names.html
SpringBoot https://blog.roncoo.com/article/133919
and many more
There are many examples. As @pwntester explained, JNDI is like registering an object in a central registry and later looking it up by name. In a web application, for example, database configuration can be managed by server software. Code or configuration files retrieve the registered object by name. If the database changes, only the registration needs updating; the name and application code remain unchanged.
It is astandard Java naming-system interface, a feature. Therefore, wherever JNDI is available, LDAP can generally be used to achieve RCE. LDAP is not the only usable protocol; several others exist:
In short, I can accept that a CVE was assigned to this Log4j 2.17.0 issue. What went too far was announcing on Twitter that Log4j 2.17.0 had yet another RCE—as if this were a new finding—when it was still the same highly constrained issue.
In one sentence:Using a configuration file to achieve RCE is a technique, not generally a conventional vulnerability.