Live data from Hacker News

Log4j 2.15.0 – Previously suggested mitigations may not be enough

isc.sans.edu

101–103 of 103 posts

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

#101
post #11

Earlier quoted context omitted.

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

I only skimmed it but couldn't find any references to log4j.

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

#103
post #81

Earlier quoted context omitted.

There isn't one. This method of development inherently leads to these kinds of problems. Software engineering is still in its infancy and has yet to truly develop a universal best practice development cycle. Eventually these things will be codified.

> Eventually these things will be codified. Is there actually evidence for this? The 30 year arc of the industry to date that I am familiar with so far shows little sign of engineering standards in software codifying around anything. If we are in the infancy stage in 2020, we are one very large infant. More likely to me is that in the future, software will change so much again that what we do today is unrecognisable;…

Regulations are written in blood. Eventually enough people will die from bad software that it will be regulated like engineering. The more we depend on computers the more likely this is to happen.
Post reply on HN