35

According to the notes for CVE-2021-44228 at mitre.org:

Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".

Therefore, assuming the defaults are in place, are my web facing applications protected from the threat this vulnerability introduces if the application is running on JRE/JDK 8u121 or newer?

Fire Quacker
  • 2,432
  • 1
  • 19
  • 29
Appleoddity
  • 503
  • 1
  • 4
  • 7

3 Answers3

49

No, you really need to update log4j.

Here is an excerpt from LunaSec's announcement:

According to this blog post (see translation), JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. In these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load remote code using LDAP.

However, there are other attack vectors targeting this vulnerability which can result in RCE. An attacker could still leverage existing code on the server to execute a payload. An attack targeting the class org.apache.naming.factory.BeanFactory, present on Apache Tomcat servers, is discussed in this blog post.

It looks like the change in 8u121 helped, but it does not entirely prevent an RCE. The recommendation is to upgrade log4j and not trust a Java update to fix it.

Fire Quacker
  • 2,432
  • 1
  • 19
  • 29
  • 9
    https://research.kudelskisecurity.com/2021/12/10/log4shell-critical-severity-apache-log4j-remote-code-execution-being-actively-exploited-cve-2021-44228/ this has been overtaken by events. "Also updated to note that guidance regarding certain Java Development Kit (JDK) versions not being impacted is no longer correct. Researchers have been able to leverage “Gadgets” in a vulnerable applications classpath to execute malicious code, regardless of the version of Java being used." – jwenting Dec 14 '21 at 11:40
  • 4
    To add to this, there is now a new CVE based on this one. So they recommend upgrading to 2.16.0 – Dean Meehan Dec 14 '21 at 22:28
  • If the Java version bundled in an application that uses an affected log4j is greater than 8u191, does it means log4shell can't be exploited according to LunaSec's blog post ? – pmbonneau Dec 14 '21 at 23:06
  • 3
    @pmbonneau It means that LDAP can't be used to load remote code, but there are still other ways to attack. Even if the Java version is greater than 8u191, you need to update log4j. – Fire Quacker Dec 14 '21 at 23:38
  • Better answer would be: no, you really need to get rid of log4j2 – Danubian Sailor Dec 16 '21 at 13:17
  • now 2.17.0 due to CVE-2021-45105 – Tim Perry Dec 21 '21 at 20:56
16

https://research.kudelskisecurity.com/2021/12/10/log4shell-critical-severity-apache-log4j-remote-code-execution-being-actively-exploited-cve-2021-44228/

No, you're not safe. Currently we have to assume that the JDK version is irrelevant when it comes to the closing of this vulnerability.

Better safe than sorry I'd say anyway. We're currently rushing to analyse and update all our systems (and that's quite a few in-house and 3rd party applications) to use Log4J2 2.16 or move them away from Log4J altogether (e.g. to Logback or commons logging, whichever is easier to implement rapidly).

As there are of course transient dependencies on old versions aplenty around in most any application, this means not just changing your direct dependencies but also put in a lot of exclusions in your Maven (or whatever) build files to ensure no older versions are pulled in under the hood.

In all the work appears to mostly be rather straightforward, just tedious.

jwenting
  • 337
  • 1
  • 5
4

Probably not, at least according to:

https://twitter.com/marcioalm/status/1470361495405875200

Basically, the java property changes mean that it won't load a remote class on to the class path. However, the post linked above suggests that the remote server can just return a payload with a standard serialisation attack (leveraging any of the huge number of 'gadget' classes which can be used to cause untrusted code execution).

schroeder
  • 123,438
  • 55
  • 284
  • 319
stripybadger
  • 141
  • 1