f-strings don't "parse user input". .format doesn't have access to objects not explicitly provided to the call, and can't call functions. So again, how do you intend to trigger any of this if not through a hypothetical logger that uses eval?
Thanks for invalidating my naive/fud scenario, I must apologize for fearmongering, when I played with it in a py repl it really felt like a vector for attack. I up-voted all parties trying to prove me wrong, and someone already down-voted me(rightfully).
It's cool, I also poked at it a bit thinking there was potential. Certainly the Flask article makes some good points about it.
(Maybe) Unpopular opinion: this whole ordeal is also due to the JRE being a clusterfuck of legacy and poor ideas. I understand it was the 90s but allowing to download arbitrary .class files from a server is _insane_, no matter how you spin it around.
The "poor idea" in the 90s was that developers were going to read specifications. Sun Micro specially suffered from this. Thus the "clusterfuck" of JRE, for example, offered something called a Security Manager, but it was "insane" to think commodity IT developers would use it ("wat's dat!?")
How is reminding of the fundamental problem of dependencies’ impact on security a yak-shaving?
Because in a company setting at least, you will soon discover that you need more than file-based logs in the specific format some coder defined for his pet project. So, you start logging to a database which is easy enough and then you start writing some simple templating code so that different logalizers can work on the logs etc. And then you discover that your logging is slowing down the whole application as more us…
So? The fact that someone needs this functionality doesn't mean everyone needs it. What you are describing is literally just software bloat, and is the root of the problem with log4j - and many, perhaps most, other vulnerabilities.
And yes, slf4j would be a proper solution, if it were the default.
Why is this so hard? It should be very easy to fix this. Set the correct version in the pom.xml. Commit and push to master and deploy. right? easy. It should be a half an hour thing. But at my employer, we still have dozens of teams struggling. Two reasons: - Branching hell.- Many teams don't do continuous integration. They have branches over branches over branches. There are many changes that are not in prod. Contin…
You're worried about patching the system that you're developing and releasing. Most people aren't doing that. Most people are patching systems they bought from some other guy. Indeed, they're scanning and patching dozens of systems they bought from a dozen other guys, each of whom sourced libraries from other guys, who sourced things from still other guys. Somewhere way down at the bottom of the vendor chain is Log4j…
Plus, older systems may have multiple applications deployed to the same Servlet container (e.g., Tomcat server), even if only one app uses log4j, upgrading it may require updates to transitive shared dependencies that can break "non-affected" apps. Given the prevalence of such Java apps, fixing this is likely to take a long time. Mitigating with firewall rules is a good first step for now.
In cases like these, I'm a strong proponent of turning it off and seeing who yells.
In an org that named their servers after planets, we turned off "Mars" (which was actually completely and utterly undocumented) and discovered it was the bridge between the intranet and the internet. However, upon turning it back on... Nothing came up again. There were no logs to try and work out which processes needed to launch for it to do its job, causing several days of website downtime (not a simple website - do…
future reference: next time just firewall the network and see what blows up rofl.
I have a feeling this vulnerability is going to be with us for years. Shameless plug: I built a tool that assists in detecting whether you're vulnerable to this or the previous CVE: https://log4shell.tools . Just enter the JNDI URI it gives you anywhere you suspect it ends up causing a message lookup in log4j. If log4j does so much as a DNS lookup, this tool will tell you about it.
Thank you for this tool. Super useful for testing e2e.
(Maybe) Unpopular opinion: this whole ordeal is also due to the JRE being a clusterfuck of legacy and poor ideas. I understand it was the 90s but allowing to download arbitrary .class files from a server is _insane_, no matter how you spin it around.
Maybe your opinion is unpopular for a reason. C and C++ has always suffered from the ability to corrupt some memory (like overrun a buffer) and jump into and start executing some user-provided arbitrary data. Perl/Python/Ruby/PHP and friends all have eval() which is even easier to exploit. Rust and maybe Go are much in this respect (because in most cases you need to deliberately mark a piece of code as unsafe before…
But we're not talking about memory corruption bugs. We're talking about intentional features.
> restart everything if they need a plugin Yes. Hopefully ensures that only people authorized to actually restart the service can add arbitrary code.
Have a look at the forced restarts of Windows due to updates having become a well-hated meme to see how lucky you'll be in explaining that to the users.
Zero-downtime service restarts have been a thing for a very long time. It is a different story for operating systems.
I have a feeling this vulnerability is going to be with us for years. Shameless plug: I built a tool that assists in detecting whether you're vulnerable to this or the previous CVE: https://log4shell.tools . Just enter the JNDI URI it gives you anywhere you suspect it ends up causing a message lookup in log4j. If log4j does so much as a DNS lookup, this tool will tell you about it.
Thank you for this tool. Super useful for testing e2e.
If there's no way to build secure software that tallies digits then why are we even here?
If there was no requirement for vote secrecy, it would be easy. The conflicting requirements between verifiability of results and secrecy of the vote is what makes it hard. I wrote more about this here: https://www.attejuvonen.fi/thesis/
I laughed out loud (and was pleasantly surprised) when I found out how much you understated your expertise. I have only read a small bit of your dissertation, but so far it is informative and interesting.