Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log4j 2.15.0 – Previously suggested mitigations may not be enough

isc.sans.edu

Post reply on HN
Print view View original

51–60 of 103 posts

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#51

Post by twic »

tie_ wrote: post #43
archi42 wrote: post #26

In 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…

Please stop suggesting that SQL Injections are a sanitization problem. They are a problem of escaping in the application constructing the query, not a problem with whatever the user has typed in. The log4j vulnerability shares some common traits, but it's completely different at the core. It's not a problem of sanitization, and I'd argue it's not a problem of escaping either (though escaping could fix it). It's a pro…

Part of the problem is (AIUI) that expansion of ${} type constructs is carried out after parameters are inserted into the log message's format string. I don't believe the use case requires that, i think it was just easier to implement. If that expansion was done on the format string, before parameters were inserted, this attack would not be possible. Injecting dodgy strings into log messages as archi42 suggests would also not be a problem if the insertion was done safely.

Agreed that this is not a sanitisation attack, but i think that means it is a format string attack:

https://owasp.org/www-community/attacks/Format_string_attack

It requires a couple of other loopholes, related to JNDI, to work, but that is the first step which goes wrong.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#52

Post by sumtechguy »

guidedlight wrote: post #9

This vulnerability will likely turn out to follow the trajectory of the Meltdown and Spectre vulnerabilities from...(checks google)... 2018. I speculate will be a cluster of newly discovered vulnerabilities that follow a similar pattern, possibility across a number of familiar Java libraries.

What I have been pondering again in the past few days is dependency management. For many projects this is a open pom file pop in the new version, recompile, deploy and bobs your uncle you are good.

But some projects are little more interesting in that they include libs like this, or include libs that include it. It is part of their foundation/framework. So you can still put in override and ignore what the lib wants.

But now when it comes time to upgrade that top lib maybe there are 6 newer versions of the one problematic lib you were concerned about today, but now it is a year later and you forgot about it. What is the mental context to say 'oh yeah go back and check that'. You may have got used to ignoring the 'hey you are overriding that jar file'. Are you going to do that for all of the libs/jars this top level framework drags in?

It is not just java that has this sort of issue. NPM (though you can float the versions at least), nuget, rust, C++ containers, etc. A lot of projects out there have taken on this maven central style building. Which is a huge productivity boon. But in many ways has not helped us with dependency hell, and in some cases has made it wildly worse. I see simple projects pulling in 150+ items in some cases. What is the mental context of actually managing that? And have real fun if your project depends on a 'dead' project where there are little to no updates.

This one is at least high profile enough that many people are revisiting old build chains that have long ago been forgotten and updating them. That will kill out many other vulins that have been lurking. But many will just do that one jar set and call it a day. But you are probably right we are going to get see a few of these style of attacks.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#53

Post by tfigment »

ethanbond wrote: post #38
xorcist wrote: post #35

Earlier quoted context omitted.

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.

What i discovered was all of my applications that use log4j do not use version 2. They have out of date dependencies or use slf4j. I'm not sure how i feel but mostly happy im not scrambling. I wonder what adoption rate v2 actually has.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#54

Post by yawaramin »

tfigment wrote: post #53
ethanbond wrote: post #38

Earlier quoted context omitted.

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.

What i discovered was all of my applications that use log4j do not use version 2. They have out of date dependencies or use slf4j. I'm not sure how i feel but mostly happy im not scrambling. I wonder what adoption rate v2 actually has.

I think adoption has mostly gone towards slf4j+logback now.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#56

Post by tgflynn »

archi42 wrote: post #26

In 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…

Are you saying that log4j is also used for analyzing logs that have already been generated ? My understanding was that it was intended for use inside an application for generating log messages and processing them before they are sent out to a file or syslog.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#57

Post by anyonecancode »

raesene9 wrote: post #18
stickfigure wrote: post #8

I 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…

The major risk here probably isn't in-house developed code but versions of log4j used in a vast array of packaged software and systems. https://github.com/cisagov/log4j-affected-db <-- that's a (probably incomplete) list of possibly affected vendors and applications, and in many cases the vendor can't even say yet whether they're vulnerable.

Yup. Here's a concrete example -- my team owns a couple of java services. They're spring boot with slf4j as our logging wrapper, using the default logging implementation of logback -- we didn't opt for log4j. So we're good, right? Well, let's do a `gradle dependencies` and see if we're pulling it in transitively -- still good. See some `log4j-api`, but no `log4j-core`. We're not actually doing any logging with log4j -- the "api" is from spring to allow you to use log4j if you want. Again, we're not, so we're fine.

Oh, but it does turn out that we do have the elastic apm agent, and it has log4j as a shaded dependency. So not as free and clear as we thought, and damn hard to detect that.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#58

Post by twic »

xorcist wrote: post #37
stickfigure wrote: post #8

I 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 comp…

Is there a list of successful hacks anywhere? Most of what i've seen on Twitter is someone posting an attack string to a website, then showing a record of a DNS lookup, which is some distance from actually being a successful exploit.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#59

Post by zootm »

jillesvangurp wrote: post #27
zootm wrote: post #20

Earlier quoted context omitted.

Using logging facades means that libraries don't need to update -- which is great -- but libraries were never directly vulnerable anyway. log4j is, to my knowledge, still by far the most common actual implementation of logging in the Java ecosystem. The assertion that it's not popular for logging only holds if you assume that logging facades are logging implementations, which they are not. My completely-unverified gu…

Most people using e.g. spring boot or quarkus would end up using the defaults that come with those frameworks. For spring boot, the default is actually logback. However, you can switch it to log4j2. https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-s... Log4j2 never quite got the same status that v1 had. V1 should be considered a bit obsolete at this point. It still works of course but it has some performanc…

> For spring boot, the default is actually logback.

I did not know this, thanks for letting me know!

> I update aggressively on my own projects to stay on top of changes and keep the effort related to mitigating compatibility issues at a minimum. A nice side effect is that you get all the latest security, performance, and other fixes. In my experience, updates get harder the further you fall behind.

This is absolutely a best practice, though I think people struggle with it for all sorts of reasons. In general one of the downsides of maintaining a diverse codebase is that this constant update cycle becomes more and more difficult, and it's one of the things that I find drives towards more consistent tooling within a team.

> I work with a lot of customers running ancient versions of whatever for no other reason than that they seem a combination of fearful, ignorant, and indifferent about what will break because they can't be bothered to even try.

While I agree this is something people need to get over, we have to take some blame for this as an industry. A lot of people have bad experiences with upstream Shiny Object Syndrome.

Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough

#60

Post by NtGuy25 »

archi42 wrote: post #26

In 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 actually literally a problem call SSTI, which is REALLY common. It's better to use the correct term instead of SQL injection.
Post reply on HN