Code executing in the JVM isn't sandboxed. Sandboxing could have indeed mitigated log4shell. Log4shell was a design where a too powerful embedded DSL was exposed to untrusted data in a daft way - the log("format here...", arg1, arg2) call would interpret DSL expressions in the args carrying logged data. One can even imagine it passing formal verification depending on the specification.
But more broadly the thing is that eliminating these low level language footguns would allow people to focus on the logic and design errors.
That's my take on it from reading so far. That's a massive mitigating factor for exploitation, imo.
Log4Shell was painful because people were using the library as it was intended to be used (a logger takes strings that are possibly attacked controllable). This will not be as bad simply because it won't be easily exploitable to the same degree.
Every case is different... but for the log4shell case in particular:
* newer JVM versions protected against the main attack (JNDI), so if you were on any JDK version released in the last couple of years, you wouldn't be vulnerable.
* Java serialization filters [1], which are highly recommended to be setup in any Java application, would also have prevented the attacks.
* not including large libraries with lots of unused features could have prevented this. In this case, log4j has support for a dozen or so things that should've been opt-in (and I think they are now) but were enabled by default in every installation.
In summary: actually paying attention to possible attacks and ensuring you're defended against them, and reducing the surface area for attacks makes your application much safer.
No, not validating user input and passing it to some crazy feature rich library like JNDI is possible in any language. Not denying that Java did contribute by shipping with such an overengineered mess like JNDI in the first place.
Log4Shell wasn't a bug, log4j worked as expected and documented. It's just a stupid idea for a logging library to work in such a way.
This is a technical analysis of the Log4Shell exploit payload that we published the other day.
I wanted to use it as a moment to help others understand what this exploit is and how they could build it themselves to hopefully make mitigating this easier too.
I'm going to go finish up adding a section on how to decompile the compiled byte code back into Java code that you can read. I'll add that in a few mins to the post.
Sandboxing is mostly irrelevant to the log4j error. You'd have to tell the sandbox to turn off reflection, which isn't really feasible in Java. And that's because Java is so poorly designed that big libraries are all designed to use reflection to present an API they consider usable.
Compare that to a language designed well enough that reflection isn't necessary for good APIs, for instance.
>The underlying problem of Log4Shell is input sanitization
While we can point to Log4j’s “message substitution” feature, there are infinite similar "features" in (whatever software) which can be exploited IF there is public network access in and out of (whatever software).
So I would argue the most significant underlying problem for exploits at this scale is public network access.
Yes, even if access in and out was limited to strongly authenticated and authorized users with least privileged access, we could still have insider attacks. But we would drastically reduce the attack surface and blast radius.
Just to expand on this a bit: One of the largest fallouts from the Log4Shell vulnerability was that companies realized how hard it was to identify where they had log4j in their infrastructure in the first place.
I've spoken with dozens of companies and it was a very similar story: Writing a detection script and then SSH'ing into every box, applying a Helm chart to scan every running container, putting the script into every CI job... Which takes weeks to months of manual effort to deal with.
And that's not even dealing with the "once you found it, who goes in and patches it?" Which is it's own can of worms.
For context: I helped deal with the fallout of Log4Shell by writing a blog post about it (I gave it that name). Since then, we've been working on an Open Source SBOM database called LunaTrace[0] to help fix what I wrote above.
We spent a few hours writing this today due to the sh*tstorm that's hit the internet since this 2nd CVE was posted up. It took us some time to do a security analysis of it and to publish our findings.
If you've patched against Log4Shell, please read this to make sure you're not still vulnerable to this 2nd CVE. In some cases, you're still vulnerable depending on how you patched.
In response to this, Apache published log4j 2.16.0 to mitigate the bugs in prior versions (including 2.15.0, the release that was supposed to mitigate Log4Shell initially)
(Note: I'm the person that coined the term "Log4Shell")
You may be surprised when I tell you what the Apache Software foundation's yearly budget is. You'd think for software that is used by practically every Fortune 500 company and most governments, it would be something reasonable. Maybe a few hundred million dollars a year to pay for a reasonable full-time staff, right?
It turns out... it's about $2 million a year. (Wikipedia[0])
This helps explain to me why the devs of Log4j directly uploaded the file "JNDIExploit.java" (the POC) to GitHub while they were patching. (Here is a full analysis about what happened[1].)
They're not security people. They're volunteers working on this in addition to their full-time job.
What kind of brave soul wants to trudge through and maintain log4j in their spare time for zero compensation? I appreciate the people that are capable of doing that, but I think they are rare!
This whole entire vulnerability was eye opening for everybody and I have actually spent the last year building tooling on GitHub to help fix the problems that Log4Shell exposed.
If you have 2 seconds to try that out or just Star the repo[2], it would be very helpful!
I'm really curious how this would have protected the government from log4shell. Log4j is (or at least was) one of the more reputable open source projects.
This kind of feels like doing something for the sake of doing something about log4shell, without actually solving any problems. And will undoubtedly result in the government paying more taxpayer dollars for software that complies with this new framework.
If you missed the news, the Log4Shell RCE vulnerability in Log4j impacts a memory-safe language (Java).
It's too early to tell -it dropped last friday - but it will probably be marked as one of the most egregious vulnerability to date due to the sheer omnipresence of Log4j in production java's code and the simplicity of its exploitation. We are talking Heartbleed/EternalBlue/Struts2 vulnerability level here.
The difference of ROI of memory-unsafe/memory-managed is not so evident. Usually memory-managed languages have fewer bugs, but those tend to be massively impactful
Java's dynamic classloaders were one of it's original tantalising features. That you could have code from one place running somewhere else - "agents" could literally send their bytes to a device to execute there, run there and then erase themselves when they were done. It sounds crazy these days but it was all meant to be held together by the security model - built in at the core it was safe to let foreign byte code execute locally because the completely managed VM could enforce a security sandbox that allowed the code to do only exactly what it was meant to.
In some ways that is where this and all those features fell down ... if log4j had constrained those classes within a security sandbox it wouldn't matter what they did. But nobody understands or uses Java security permissions. The whole system is byzantine and drives people crazy whenever they do run into it. But if it had worked you could be asking the question, "why did log4j allow the permission for the remote code to do bad things" rather than "why was remote code allowed to execute".
> When it was first revealed in early December 2021, the Log4Shell bug was described as one of the most severe security vulnerabilities ever.
> The Apache Software Foundation, which maintains the open-source tool, quickly released a patch...
Apache horribly mismanaged this and did not release a patch until it was already widely known and being exploited in the wild. They also messed up and had to release several subsequent patches to actually fix the vulnerability. This greatly contributed to "[the] mad scramble to plug the gaps".
I apologize for accidentally creating a meme here. (I got angry when I saw the recent "ProxyNotShell" vulnerability in the media...)
It is an interesting exercise in the power of language though. The name "Log4Shell" was literally picked because there wasn't a CVE and people running searches for "log4j RCE" were seeing a vuln in Log4j v1 from 2016. There needed to be a unique identifier that people could search for and tag on Twitter.
The name just... sort of got picked arbitrarily while I was very tired after doing many hours of security research and reading through Enterprise Java code lol. (You're right that "shell" was used to express RCE, ala Shellshock or other major vulns.)
I think the subsequent vulns (Spring4Shell, Text4Shell) just use the format of the name to be more catchy and ride the coat tails of Log4Shell's notoriety. (Like a meme!)
log4net was never affected by the log4shell vulnerability as there is no .NET equivalent for JNDI [0]. JNDI is remote code execution as a service, and entirely a Java idea that that would be generally useful.
Though if you are concerned about using a library with "log4" in the name and/or shuffled into the Apache graveyard in .NET, there are lots of useful replacement libraries. Microsoft.Extensions.Logging is "out of the box" in modern .NET and a simple NuGet away in older frameworks.
But more broadly the thing is that eliminating these low level language footguns would allow people to focus on the logic and design errors.
reply