Third High Severity CVE in Log4j Is Published

Thanks to all Log4j developers. As users of your free software since ~20 years, we&#x27;re sure that, if this vuln disclosure had been better and there were no sign of widespread in-the-wild exploitation, you would have done a better job at patching it, and a single release would have been enough.<p>We won&#x27;t hold a grudge against you; open source means collaboration, and you don&#x27;t blame hard-working people that give away their software for free for honest mistakes. Your software still did far more good than bad to the software world.<p>Thanks!

If information security people would spend the same amount of time they are spending complaining about this vulnerability trying to educate their organisations on the importance of supporting open source solutions they depend on we wouldn’t be in this situation. I am sick of reading of very senior people complaining about the impact this vulnerability has had on their week when their companies don’t even contribute a penny to open source projects.

I see plenty of comments about security teams that should be doing this or that.<p>I do not know about your security teams, but my security teams are now sitting 9 days straight trying to stop that shitshow. With teams complaining that they have to patch instead of doing Great Things.<p>After that these security teams will be back to invisible work and forgotten again. Until the next issue.<p>If your company has a truly different approach to security, tell it here - you may get really talented people knocking in because they are fed up with the security theater at their current job.

I’m enjoying the Apache Software Exploit Advent Calendar

The most reliable place to find new bugs and security holes is next to others you just found out about.<p>Bugs come in bunches. If you have fixed just one or two, more lurk <i>right there</i>. And, anyplace else that coder worked. The more you have found, the more remain to be found. Look at other places that coder worked that week. Or year.

It&#x27;s amazing that this library is used by so many large enterprises yet none of them made an effort to thoroughly audit the code (actually, it looks like Alibaba reported the first one. But the point stands that the code was used for so long and by so many.)

Might want to read this thread:<p><a href="https:&#x2F;&#x2F;issues.apache.org&#x2F;jira&#x2F;browse&#x2F;LOG4J2-3230" rel="nofollow">https:&#x2F;&#x2F;issues.apache.org&#x2F;jira&#x2F;browse&#x2F;LOG4J2-3230</a><p>It&#x27;s pretty interesting technically, and it&#x27;s not really affecting 2.16.0 much except in weird edge-cases.

It&#x27;s been a minute since I primarily developed in Java, but back then we had switched away from log4j in favor of slf4j &#x2F; logback. These were written by the author of log4j. We switched because they were significantly simpler than log4j.<p>Switching over merely involved changing the jar files we used, and redoing the config.

I maintain `debug` for Node.js and the Log4J devs are living my worst nightmare when it comes to that library. It&#x27;s used just about everywhere and any sort of zero-day would have far reaching implications.<p>Hugs for all of you. This can&#x27;t be fun.

They should open source it so the community can improve and fix bugs.

So, again, why is log4j &quot;evaluating&quot; stuff in log strings? This is the root cause that people should be addressing<p>Why are people still using JDNI? It is frail enough to have logs depend on a dns lookup, I can&#x27;t imagine depending on a LDAP lookup. This is not such a fundamental issue as the above but it is pretty dangerous.<p>Oh yes and of course one of the worse and least pythonic package in the Python standard library was &quot;inspired&quot; by the log4j monstrosity

This isn’t a RCE right? Compared to the previous one I wouldn’t call a denial of service high severity at this point. It might have been high severity two weeks ago.<p>But to be clear: nested&#x2F;recursive template expansion and expansion of user provided strings were never <i>by design</i>, correct, and the removal shouldn’t just be by configuration or considered breaking - it should simply be corrected (just like the jndi should be removed and not even be optionally possible)?

Here&#x27;s what I don&#x27;t get: What is so complicated about logging that you can&#x27;t implement the necessary functionality in your own codebase, and instead have to adopt a third-party library?<p>The latter option represents a liability, which in this case (as with others) has shown can be a tremendous risk. Is the time saving really worth it, at the cost of risking disasters like this?<p>I get that the tradeoff it is worth it for complicated things (e.g. crypto libraries). But logging, really?<p>Software development culture today is too quick to adopt a huge tree of dependencies of unknown quality, rather than thinking about how to minimize dependencies to only those truly necessary. The leftpad fiasco was but an extreme example of this, but I see it all the time, and it seems probable that there are hundreds (maybe even thousands) of similarly severe problems out there in widely used dependencies that we just don&#x27;t know about yet.

At least this one is &quot;only&quot; denial of service and not another RCE?

I have never understood why logging has needed such complex frameworks.

I was pretty horrified to learn that log4j makes network calls, was even surprised to hear it parses log strings.<p>Fortunately our log4j was too old and JVM too young to be vulnerable to the first exploit, but it seemed best to rip out log4j and replace it with something simpler anyway.<p>java.util.logging seemed the obvious choice, but the API is different, so would have been a lot of s&#x2F;debug&#x2F;fine and so on.<p>In the end, we:<p>- wrote a new class with the same &#x27;api&#x27; as the part of log4j that we use<p>- globally replaced &#x27;import org.apache.log4j.Logger&#x27; with our new class<p>- fixed any compile errors by adding new methods to our class<p>- wrote a test to make sure it rolled correctly and could handle lots of threads etc.<p>Here&#x27;s the code if you want to do something similar (don&#x27;t know how long it will be accessible from there): &lt;<a href="https:&#x2F;&#x2F;ideone.com&#x2F;XKg5M9" rel="nofollow">https:&#x2F;&#x2F;ideone.com&#x2F;XKg5M9</a>&gt;

More evidence that user provided data shouldn’t be logged at all.

Does anyone know about the quality of crypto implementations in Java Cryptographic Extension (JCE), the standard crypto library in Java?<p>We use a product that uses JCE. The log4j vulnerabilities worry me about the security of software in Java ecosystem in general.

Hopefully this puts an end to those annoying log4j-LOTR memes.<p>(Unless some hobbits have 3 breakfasts?)

Is this still about malicious payloads in serialized Java packets? I don&#x27;t use Java so maybe I&#x27;m being unjust, but I&#x27;m smiling slightly because Python went through this 20 years ago with regard to the pickle protocol. It was originally intended to be ok for transporting hostile data, and it took a fair amount of persuasion and a few security incidents to turn the community&#x27;s thinking around about that. ast.literal_eval was invented partly for this reason, but the generally preferred way to serialize now is usually json.