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

91–100 of 103 posts

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

#91

Post by Dylan16807 »

hermitdev wrote: post #86
jeltz wrote: post #80

Earlier quoted context omitted.

Not sure I agree, for me sanitation has a strong connotation with removing things. And sending data out of band from code on the other hand cannot be seen as a form of sanitation. And is my preferred method of solving this issue.

I think, generally, sanitization means protecting against potentially malicious input. Whether it takes form via escaping or removal or some other remediation is beside the point.

I'd say sanitization implies that there's something wrong with the data and you need to clean/fix it. But the former isn't true and the latter sounds like removing or irreversibly remapping characters.

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

#92

Post by gunnarmorling »

mrclark411 wrote: post #84
yawaramin wrote: post #54

Earlier quoted context omitted.

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

logback is *gpl, I think that scares folks away.

Logback is dual-licensed under EPL v1.0 and the LGPL 2.1, as per the licensee's choosing [1]. In particular, it is not licensed under the GPL.

[1] http://logback.qos.ch/license.html

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

#93

Post by regularfry »

zootm wrote: post #20
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…

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…

That's my observation. My favourites are the projects where the last commit was 5 years ago with a copy-pasted log4j stanza that must have been 4 years old at that point, which now can't practically be upgraded at all because of the bitrot and loss of organisational knowledge. I've seen one that needed somewhat special measures just to regain access to the source code...

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

#94

Post by regularfry »

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…

"A bit obsolete" is underselling a 9-year-old release that's been EOL for 6...

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

#95

Post by omegalulw »

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…

> 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.

How are they different?

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

#96

Post by jet390 »

The recent log4j vulnerability really piqued my interest, and I've spent the last few evenings working on a proof of concept Java agent that could mitigate similar vulnerabilities in the future, for applications that are able to completely forego platform features like JNDI, serialization or native process execution.

Link to the project: https://github.com/gredler/aegis4j

It's not a lot of code, but it uses parts of the platform that I think are a bit unusual for most devs, so it was quite interesting to implement. Happy to discuss details, ideas, and concerns.

One idea for a possible improvement is to make the feature block list adaptive, i.e. watch what the application uses in the first few minutes of execution, and then shut down all unused "dangerous" features for the remaining lifetime of the VM. Not sure how reliable this would be though, especially for services which have background jobs that might only run once a day.

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

#97

Post by archi42 »

Sebb767 wrote: post #34
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 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.

Yes, absolutely. log4shell is a pwn fest that makes the recent Exchange debacle look rather innocent (and that was already quite bad). But I can envision scenarios like unencrypted rsyslog on a LAN being relevant during pentests, or misconfigured (read: attacker readable) log files.

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

#98

Post by ishjoh »

anyonecancode wrote: post #57
raesene9 wrote: post #18

Earlier quoted context omitted.

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…

Shaded dependencies are a nightmare, and it's a particular bone I have to pick with using Elastic products that they think this practice is ok.

I prefer to package all my projects into a single fat jar, since it makes distribution so easy and clean, but if I was creating jar files with the expectation that other projects would use them I would make sure to package everything separately.

In this case using fat jars made things really easy to check for the effected classes and luckily for me I also didn't have any log4j-core classes in my fat jars.

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

#99

Post by yawaramin »

mrclark411 wrote: post #84
yawaramin wrote: post #54

Earlier quoted context omitted.

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

logback is *gpl, I think that scares folks away.

It scares away people who see 'GPL' and refuse to read further, perhaps. Not only is it dual licensed, but both licenses (EPL and LGPL) freely allow linking with proprietary software.
Post reply on HN