Why is there no environment variable to turn off parsing the messages completely?
Log4j 2.15.0 – Previously suggested mitigations may not be enough
31–40 of 103 posts
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#32Earlier quoted context omitted.
No it isn't 20yo. This feature is about 5
This JNDI "feature" is 8 years old. It was merged in 2013 from what I have seen, and has been defended by some as an "useful" feature. It has been known since at least BlackHat 2016 presentation that this is an incredibly dangerous and stupid thing to keep. cricket noises nobody reacted until now when minecraft servers got hacked.
This whole fiasco is an argument to keep things simpler whenever possible.
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#33Earlier quoted context omitted.
I have ported a Spring Boot application from log4j to logback and it was pretty easy since we used slf4j. The code was the same, the only thing I had to do is to convert the logging configuration. The features mapped one to one and it to some fidgeting to make it work, but all in all it was pretty straight forward. Would recommend.
> The features mapped one to one did they also map the jndi feature ;)
Haha, no that was missing. I mean all the features/loggers that were used in the project mapped one to one.
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#34In other news: If I can intercept the log messages (unencrypted remote syslog, or log file public accessible, log messages also shown to the user) I can still just inject stuff like "${env:DATABASE_PASSWORD:-xxx}". Lots of people are only focusing on the aspect how this can be abused to inject arbitrary code, while it is actually a similar class like SQL injections: Blindly trusting user input instead of doing proper…
This is somewhat intended, though. Also, for intercepting the logs you need _a lot_ more access than for an unauthenticated RCE and that database might not actually be accessible from the outside.
It's not cool, but far less severe than the original issue.
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#35In other news: If I can intercept the log messages (unencrypted remote syslog, or log file public accessible, log messages also shown to the user) I can still just inject stuff like "${env:DATABASE_PASSWORD:-xxx}". Lots of people are only focusing on the aspect how this can be abused to inject arbitrary code, while it is actually a similar class like SQL injections: Blindly trusting user input instead of doing proper…
People think they are safe because they don't allow for outgoing ldap, but combined with a way to do dns lookups, these kind of things can get really scary.
The java ecosystem is full of these abstractions, that are not outright security problems in themselves, but give rise to complex interactions that makes it hard to judge what the implications are.
This particular logging system has been used by millions of developers for the better part of a decade before any one single person realized the actual implications.
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#36This is starting to remind me of the coronavirus
If you mean it's turning into a grinding and repetitive groundhog day, I concur.
We don't even use log4j and yet are fielding a steady stream of requests to reassure clients that we've mitigated against it, which hasn't been an issue because we don't use it (although we do use log4net with Stackify and it's certainly a possibility that may be compromised in future), and of course are having to audit all our own suppliers.
I encourage companies to post information on their websites about this so we don't all have to keep emailing you (I'm trying to get some info up on ours detailing mitigations, for similar reasons; once it's there I can send some all company comms and hopefully never see another email in my inbox with "log4j" in the subject line).
Of course, this whole issue is crucially important to deal with, but it's also frustrating because it's an entirely non-value-adding time-vampire.
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#37I must confess to feeling that the reach of this CVE is a bit oversold. Yes, it's a terrible RCE and a major catastrophe for anyone using log4j. But log4j hasn't been the popular choice for logging implementations in a long time. Libraries typically use facades like slf4j or commons-logging, so the risk of pulling in an active log4j implementation transitively is pretty small. Your application/appserver either logs w…
My initial reaction was also tentative skepticism. Not that the package isn't popular, but that it must be hard to find real world interactions where you can successfully get a payload in, and a lot fewer still where you can actually execute it.
Yet we have seen a large number of high profile hacks already, and they keep coming. Turns out that not only are there many ancient java versions in use, the aren't very compartmentalized either.
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#38In other news: If I can intercept the log messages (unencrypted remote syslog, or log file public accessible, log messages also shown to the user) I can still just inject stuff like "${env:DATABASE_PASSWORD:-xxx}". Lots of people are only focusing on the aspect how this can be abused to inject arbitrary code, while it is actually a similar class like SQL injections: Blindly trusting user input instead of doing proper…
People think they are safe because they don't allow for outgoing ldap, but combined with a way to do dns lookups, these kind of things can get really scary. The java ecosystem is full of these abstractions, that are not outright security problems in themselves, but give rise to complex interactions that makes it hard to judge what the implications are. This particular logging system has been used by millions of devel…
Just a minor clarification that’s worth being explicit about:
It has been used by millions of developers for the better part of a decade before anyone disclosed the implications.
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#39Earlier quoted context omitted.
This JNDI "feature" is 8 years old. It was merged in 2013 from what I have seen, and has been defended by some as an "useful" feature. It has been known since at least BlackHat 2016 presentation that this is an incredibly dangerous and stupid thing to keep. cricket noises nobody reacted until now when minecraft servers got hacked.
> nobody reacted until now when minecraft servers got hacked That shows which part of the IT industry is really needed.. :-)
On average, humans spend five days of their life watching Minecraft related content.
Google recently had a banner announcing a trillion hours of Minecraft content watched; there are roughly 8 billion humans. So on average, a human has watched ~125 hours of Minecraft content.
I think it’s just InfoSec has been too busy playing secret squirrel to secure our infrastructure:
- SolarWinds
- MS Exchange
- log4j
- Minecraft
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#40So code written in a language that encourages building a gazillion indirections instead of just doing things procedurally is hard to fix? I'm shocked ;-)
More realistically, this code is 20 years old, several generations of maintainers worked on it, accumulating patches over patches over patches and nobody wanted to be the guy that say No / we should remove that feature. You can see the discussions on HN about Gnome removing features as a good example about how hard it is.
> More realistically, this code is 20 years old
Actually, it’s not. Log4j 2 is a ground up rewrite of Log4j and is less than 9 years old from when the rewrite started, 7 years for the GA release. Log4j 1.x isn’t vulnerable as it doesn’t have this “feature”.
Imho, this isn’t a “patches over patches” situation, it’s a very poorly thought out “feature” that almost nobody needed and shouldn’t have been added in the rewrite. The concept of “separation of concerns” exists for a reason. Your logging library should _just_ be concerned with logging.