Does this affect SL4J library as well ?
Log4j RCE Found
401–410 of 531 posts
Re: Log4j RCE Found
#402Re: Log4j RCE Found
#403Earlier quoted context omitted.
> Turns out, by including "." in some part of the URL to this remote class, Log4j lets off its guard & simply looks up to that server and dynamically loads the class file. No it doesn't. That was disabled by default in 2009, and was disabled by default in every release of Java 8 or later: https://github.com/openjdk/jdk8u/commit/006e84fc77a582552e71... Unless i am mistaken, i don't believe the attack as described by L…
This is my understanding of it as well. While the bug is still bad due to the fact that a JVM instance will connect to the attacker's endpoint, any JVM above 8u121 wouldn't execute the code with Java's default configuration. It's also mentioned as part of the release notes for 8u121: https://www.oracle.com/java/technologies/javase/8u121-relnot... Edit: Looking deeper into it; the JDK version used within the POC's Git…
Aha! It's more complicated than i thought:
https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Inj...
Re: Log4j RCE Found
#404Earlier quoted context omitted.
> why would you roll your own instead of using a tried and true library For one, the very reason we are all in this thread right now.
Plenty of "roll your own x"s have critical security bugs too, they just don't make the front page of HN. Do you really think, in general, roll your own is safer?
Not in general. Your own cryptography implementation? Hell no. Your own simple logging solution that doesn't need anything fancy from log4j? Probably.
Re: Log4j RCE Found
#405Earlier quoted context omitted.
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 the…
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...
Re: Log4j RCE Found
#406Re: Log4j RCE Found
#407The amount of impact this has is absolutely mind-boggling: https://github.com/YfryTchsGD/Log4jAttackSurface/tree/master...
Re: Log4j RCE Found
#408I've been thinking about this since I saw it here on HN yesterday, and I can't help but entertain the idea that this might end up being 'the worst software security flaw ever'.
absolutely, most vulnerabilities are stopped by the frontend this one gets all the way through and hits the backend better hope your backend is on a separate LAN with no internet access..!
This one could possibly hit past the backend and hit tools like sentry, a log aggregation and such, through an unaffected backend.
Re: Log4j RCE Found
#409log4j is a very popular and ubiquitous Java library. Having a zero-day remote code execution vulnerability in it is a serious problem that undoubtedly affects a huge portion of the internet.
It's almost mind boggling that it went for so long undetected. It's been sitting there for 7 years.
'Shellshock' was sitting there since 1989 and only detected in 2014.
Re: Log4j RCE Found
#410log4j is a very popular and ubiquitous Java library. Having a zero-day remote code execution vulnerability in it is a serious problem that undoubtedly affects a huge portion of the internet.
After ~12 hours of getting this mitigated at work, yeah. The only things I could imagine much worse would be broken RSA, or something like this in the linux network stack. Even something in SSHD would be less bad, because SSHDs tend to be protected. This occurs in the main business function of requests.