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

21–30 of 103 posts

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

#21

Post by wcoenen »

simion314 wrote: post #10
_old_dude_ wrote: post #4

Earlier quoted context omitted.

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.

>You can see the discussions on HN about Gnome removing features as a good example about how hard it is. The issue with GNOME is the insincerity of feature removal, things like "nobody uses that", "nobody needs that", "you are doing it wrong" instead of just be sincere , "file picker is a usefull feature but we can't or don't care to implement it" , "optional server side decoration is a good feature but our devs want…

I'm not familiar with the GNOME story, but removing features takes courage and is actually a form of sincerity.

A developer team can be insincere and avoid outrage by just leaving half-broken features in the software, stop testing them, and ignore all complaints about it. Low quality and inactivity doesn't make for as good a story on social media.

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

#22

Post by chromanoid »

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.

Mmh, I don't think so. Beside logging most other libraries will already sanitize user input since it is a more commonly known attack vector for those kind of libraries. I would compare the vulnerability to https://github.com/frohoff/ysoserial.

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

#23

Post by BrazzVuvuzela »

wcoenen wrote: post #21
simion314 wrote: post #10

Earlier quoted context omitted.

>You can see the discussions on HN about Gnome removing features as a good example about how hard it is. The issue with GNOME is the insincerity of feature removal, things like "nobody uses that", "nobody needs that", "you are doing it wrong" instead of just be sincere , "file picker is a usefull feature but we can't or don't care to implement it" , "optional server side decoration is a good feature but our devs want…

I'm not familiar with the GNOME story, but removing features takes courage and is actually a form of sincerity. A developer team can be insincere and avoid outrage by just leaving half-broken features in the software, stop testing them, and ignore all complaints about it. Low quality and inactivity doesn't make for as good a story on social media.

> I'm not familiar with the GNOME story, but removing features takes courage

Courage is not intrinsically admirable. Whether it's admirable or abhorrent depends on the context of what you're doing. Ditto for sincerity.

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

#24

Post by whattimeisnow »

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…

Oh sweet summer child

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

#25

Post by simion314 »

wcoenen wrote: post #21
simion314 wrote: post #10

Earlier quoted context omitted.

>You can see the discussions on HN about Gnome removing features as a good example about how hard it is. The issue with GNOME is the insincerity of feature removal, things like "nobody uses that", "nobody needs that", "you are doing it wrong" instead of just be sincere , "file picker is a usefull feature but we can't or don't care to implement it" , "optional server side decoration is a good feature but our devs want…

I'm not familiar with the GNOME story, but removing features takes courage and is actually a form of sincerity. A developer team can be insincere and avoid outrage by just leaving half-broken features in the software, stop testing them, and ignore all complaints about it. Low quality and inactivity doesn't make for as good a story on social media.

>but removing features takes courage and is actually a form of sincerity

That is false, say I remove the feature X because reason A but I tell everyone that is for reason B. So I had the courage to remove X but I did not the courage to be sincere, maybe I am not sincere with myself and the real reason A is that the code was written by somebody else in the past and I want to implement new cool shit and not read somebody else code, but I can't admit that I don't care about feedback because I might be replaced as a project leader so I invent bullshit excuses like blame the previous developers that wrote bad code, blame the user that are using it wrong or invent some bullshit UX story with no real user tests to push my egotistic vision on everyone else because I am really an Apple fan but I could only get a job to work for RedHat

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

#26

Post by archi42 »

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

(The whole discussion why a logging mechanism should support the whole JDNI stuff is still perfectly valid).

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

#27

Post by jillesvangurp »

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…

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 performance issues that both log4j2 and logback try to address.

The issue with high profile vulnerabilities like this is that there are a lot of projects where dependencies are rarely updated.

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. So, the longer you wait, the more likely you will have a lot of fallout from updates and the more likely it is that you will be exposed to pretty serious bugs that have since been addressed upstream.

If you are like me, I can recommend the excellent refreshVersions plugin for gradle. It makes staying on top of dependency updates a breeze. I run it every few weeks to spend a few minutes updating misc libraries, and verifying everything still works. Run the command, update to the suggested versions, create a pull request and merge when it works.

Occasionally there are issues with specific libraries but 95% of the updates are completely painless and the remainder are usually pretty easy to deal with. And if there are show stopper issues, I want to know about them and document them why we can't update.

I would recommend doing the same for packaged software. 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. Mostly updating them to more recent versions isn't that big of a deal and it tends to address a multitude of performance, security, and other issues.

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

#28

Post by shashashasha___ »

alenmilk wrote: post #16
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…

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 ;)

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

#29

Post by josefx »

mol4711 wrote: post #11
unbanned wrote: post #5

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

> and has been defended by some as an "useful" feature.

I would say the feature is useful but the implementation is insane. I would expect a SQL prepared statement approach, only contents of the statement / format string are resolved. Interpreting variables in user provided input just asks for SQL injection attacks and needs to be either prohibited or extremely restricted.

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

#30

Post by abhishekjha »

mol4711 wrote: post #11
unbanned wrote: post #5

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

I guess you are referring to this[0]. I am surprised if it was known that early then why did it take so long to find the issue? Or were exploits already run earlier and nobody reported?

[0]https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-...

Post reply on HN