News for hackers. Stuff that matters.
Re:Log4j 2.15.0 – Previously suggested mitigations may not b... by _old_dude_ on Thursday December 16, 2021 @04:05AM (#29576416)
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 b... by jsjohnst on Thursday December 16, 2021 @07:48AM (#29577597)
> 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.

Re:Log4j 2.15.0 – Previously suggested mitigations may not b... by simion314 on Thursday December 16, 2021 @04:37AM (#29576592)
>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.

Re:Log4j 2.15.0 – Previously suggested mitigations may not b... by wcoenen on Thursday December 16, 2021 @05:05AM (#29576746)
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 b... by simion314 on Thursday December 16, 2021 @05:49AM (#29576988)
>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 b... by silon42 on Thursday December 16, 2021 @07:54AM (#29577643)
I wish they didn't add SELECTION back... https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection

But I'll never accept client side decorations.

Re:Log4j 2.15.0 – Previously suggested mitigations may not b... by BrazzVuvuzela on Thursday December 16, 2021 @05:16AM (#29576812)
> 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 b... by unbanned on Thursday December 16, 2021 @04:06AM (#29576420)
No it isn't 20yo. This feature is about 5
Re:Log4j 2.15.0 – Previously suggested mitigations may not b... by mol4711 on Thursday December 16, 2021 @04:45AM (#29576627)
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.

Re:Log4j 2.15.0 – Previously suggested mitigations may not b... by josefx on Thursday December 16, 2021 @06:23AM (#29577160)
> 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 b... by abhishekjha on Thursday December 16, 2021 @06:24AM (#29577165)
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-...

Re:Log4j 2.15.0 – Previously suggested mitigations may not b... by joe_guy on Thursday December 16, 2021 @09:16PM (#29586918)
I only skimmed it but couldn't find any references to log4j.
Re:Log4j 2.15.0 – Previously suggested mitigations may not b... by js8 on Thursday December 16, 2021 @04:57AM (#29576690)
> nobody reacted until now when minecraft servers got hacked

That shows which part of the IT industry is really needed.. :-)

Re:Log4j 2.15.0 – Previously suggested mitigations may not b... by bombcar on Thursday December 16, 2021 @08:26AM (#29577861)
More importantly Minecraft servers are a target of convenience that both could and would be attacked by script kiddies.

The open question is did anyone exploit this quietly and targeted before?

Re:Log4j 2.15.0 – Previously suggested mitigations may not b... by jethro_tell on Thursday December 16, 2021 @11:53AM (#29580336)
Of coarse. Especially if it was known since black hat 2016.
Re:Log4j 2.15.0 – Previously suggested mitigations may not b... by selimnairb on Thursday December 16, 2021 @06:42AM (#29577240)
This whole fiasco is an argument to keep things simpler whenever possible.
Re:Log4j 2.15.0 – Previously suggested mitigations may not b... by wiseowise on Thursday December 16, 2021 @04:08AM (#29576428)
They didn't say anything about the feature?