Log4j 2.15.0 – Previously suggested mitigations may not be enough
1–10 of 103 posts
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#2Thread on this from yesterday: https://news.ycombinator.com/item?id=29561532
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#3So code written in a language that encourages building a gazillion indirections instead of just doing things procedurally is hard to fix?
I'm shocked ;-)
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#4So 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.
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#5So 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.
No it isn't 20yo. This feature is about 5
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#6This is starting to remind me of the coronavirus
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#7Earlier 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.
No it isn't 20yo. This feature is about 5
They didn't say anything about the feature?
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#8I 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 with log4j or not, and your developers are probably aware of this when they configured logging. You shouldn't need to pour over code to figure it out.
It would be far worse if this exploit existed in slf4j or commons-logging.
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#9This 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.
Re: Log4j 2.15.0 – Previously suggested mitigations may not be enough
#10So 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.
>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 to work on cool shit not backwards compatibility" ... if you are an open source dev, be sincere and people will not be disgusted by your community and you don't get the go to example for bad developers/community.