We just released Log4j 2.17.0 which addresses this issue: <a href="https://logging.apache.org/log4j/2.x/download.html" rel="nofollow">https://logging.apache.org/log4j/2.x/download.html</a>
This looks worrying, but if you read the issue thread it seems that this can only be triggered if you can edit the pattern string of the logger. This is something you can only do on the server itself (if made configurable) or in the build artefact that you deploy.<p>From a quick glance at the comments this looks like a minor issue due to the attack vector being very, very small — i.e., the attacker must have access to where the logging pattern is defined, and if that is the case, this attack is probably not the most worrisome they could pull off.<p>I hope I'm not wrong, otherwise we'll be patching everything again.
There's a new CVE filed for it, just now. And here are the others for reference.<p>12/18 - <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-45105" rel="nofollow">https://nvd.nist.gov/vuln/detail/CVE-2021-45105</a> Score: -<p>12/14 - <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-45046" rel="nofollow">https://nvd.nist.gov/vuln/detail/CVE-2021-45046</a> Score: 3.7<p>12/14 - <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-4104" rel="nofollow">https://nvd.nist.gov/vuln/detail/CVE-2021-4104</a> Score: 8.1<p>12/10 - <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-44228" rel="nofollow">https://nvd.nist.gov/vuln/detail/CVE-2021-44228</a> Score: 10.0
This is nothing surprising. I'm not talking about the bug, but the report.<p>If you shine a thousand spotlights at a problem, you'll find more problems.<p>Glad this library is finally getting the code review it deserves. Hope the whole SDK gets the fine-tooth comb treatment it is overdue.<p>Like it or not... 50% of the Internet runs on Java (and my statistics are 50% accurate. I swear, 50% of the time.)
Get away from languages like C, they said. There are double free, dangling pointer, undefined behavior, they said.<p>Wow, a LOGGER engine that execute arbitrary code. wow
Avoid frameworks and libraries whenever possible.<p>The last time I benchmarked java.util.logging though, it lost out to log4j by a wide enough margin. Has anyone done any benchmarking lately?
So, let me get this: Log4j is disabling JNDI, fixing various string substitution issues and who knows what else, but the root cause of the whole mess - that Log4j attempts string substitution on the <i>actual parameter values</i> remains untouched? Why?
Reading stories like this makes me very sad about the state of my profession. Something that is supposed to be a simple stupid logging library is on the front pages of the mainstream media due to all the havoc it's causing. We really have a long way to grow up as a profession.
Perhaps I missed this, and I get there are backwards compatibility issues, but can't a version ship where default is that the logged strings (not formatting strings) are not parsed <i>at all</i>. This seems like a major design flaw - I don't want my logging library doing <i>any</i> parsing of the logged input.
Sometimes I wonder if it would be possible to estimate the probability of the presence of nasty vulnerabilities like this one on a software stack.<p>At one point, it seems that "everyone use this so it must be secure enough" replaced "we're a large company, did we spend enough time reviewing code of the open source stuff we use?".<p>It seems the Linus's quote "given enough eyeballs, all bugs are shallow", is not really true.<p>Imagine if a well funded agency like the NSA employed at least hundreds of full time developers whose job would be to sniff for those vulns. I'm pretty sure you could automate searching for those vulns, and that only the NSA has such tool.
I wonder if this won't be a boon for them in the long run. Lots of eyes on log4j security nowadays, it will come out stronger if with fewer users. I imagine a lot of user have switched to other logging solutions now or plan to in the near future.
I still try to understand why anybody would want a logger that executes embedded code and loads remote code from aribtrary web urls. That's like having a toaster that needs regular tire changes so it doesn't run me over.
Do they just, like, not have a QA department over there? Have people really still not understood that they amount of resources spent on QA must be exponentially proportional to dependents count? And that QA, not software "engineering", is the most important job that requires the most highly qualified people?
Three releases for essentially the same bug in a week is not okay.
Just shut this project down. It’s seemingly a cesspit of bad code, bad testing and general incompetence.