41–50 of 531 posts
The best part is surely the diffstat of the "fix": +465 −9 This is insanity.
Did you look at it? Half of it is test and license headers plus the fix involves adding a whitelisting and filtering code.
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/mbechler/marshalsec - https://github.com/veracode-research/rogue-jndi Minecraft servers were being actively exploited according to various tweets.
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.
I don't get what the point of this feature even is. What is a legitimate reason for a logging library to make network requests based on the contents of what is being logged? And is this enabled out-of-the-box with log4j2?
I encountered a similar problem recently, my own logger can get the current container/pod IP address, it's painful to tell which host from the IPs in logs, so I had to do a manual DNS lookup to include a hostname instead. I was hoping the logger could automatically do a lookup and cache it for me.
What’s the actual bug and how would it be exploited?
Thanks for the write-up but I have a few questions. Why does log4j's .log() method attempt to parse the strings sent to it? It is the last thing I would expect it to do. Is the part in the sample code where the user's input is output back to them part of the exploit? If so how does it fit into the attack? What will the attacker see beyond the string they originally sent as input? Could you update your mitigation step…
Isn't it generally considered bad practice to log user controlled data (without some form of sanitization)? I think static analyzers tend to find these since they're a type of injection attack (an attacker could insert fake log lines or otherwise interfere with the log contents)
Most people don't take "log injection" that seriously as a bug class in Java. There are usually no consequences for ignoring it, so it's common. The RCE adds a lot of flavour to an otherwise bland bug.
This should be something that static code analyzers should pick up. If a dependency log4j dependency is Just in time to ruin all of the reports project managers present to executives
Earlier quoted context omitted.
I see a GitHub Advisory being made at https://github.com/advisories/GHSA-jfh8-c2jp-5v3q
The CVE is being crafted as I write this...
i've argued no given the complexity of today's logging pipelines and caught a lot of flak for it in the past... now i feel vindicated.