I have never understood why logging has needed such complex frameworks.
Third High Severity CVE in Log4j Is Published
281–290 of 335 posts
Re: Third High Severity CVE in Log4j Is Published
#282Earlier quoted context omitted.
Your implication that specific bad coders are responsible for bugs is dangerous. Anyone can write a bug, and thinking that you're too good to do it is cocky.
Yes, but when a coder makes a specific mistake, it's likely they made it elsewhere. Similarly, when their mistake made it past code review, it likely made it past review elsewhere. They're not the only person making that mistake, but their diffs are a great place to start looking. A big subset of mistakes people make when writing software are the result of people not having the same understanding of a concept, policy…
It really depends on the subject area of the code in specific. “Mistake” is a very broad term, in most cases when it’s used it’s not the implication that the writer didn’t know what they were doing, rather they wrote erroneous code—which ultimately everyone does at some point. What it is however indicative of, is a lack of thorough testing and review that could have potentially caught the error. Obscure errors in places such as parsers, rendering logic, complex algorithms, memory management, etc. are particularly tough areas because building a good exhaustive testing workflow can be a challenge.
Even a good writer will make mistakes, otherwise we wouldn’t need proofreaders.
Re: Third High Severity CVE in Log4j Is Published
#283Thanks to all Log4j developers. As users of your free software since ~20 years, we're sure that, if this vuln disclosure had been better and there were no sign of widespread in-the-wild exploitation, you would have done a better job at patching it, and a single release would have been enough. We won't hold a grudge against you; open source means collaboration, and you don't blame hard-working people that give away th…
I lay any blame squarely at the feet of IT security of large organisations that were entirely unprepared to update a widely used dependency that wasn't an operating system or a runtime. Windows, Linux, Java, and .NET are all commonly updated, but "modules" aren't. This wasn't just a predictable scenario, it was predicted. Or more accurately, it has occurred already repeatedly in the NPM ecosystem, but for some myster…
> I lay any blame squarely at the feet of IT security of large organisations that were entirely unprepared to update a widely used dependency that wasn't an operating system or a runtime. This wasn't just a predictable scenario, it was predicted. Or more accurately, it has occurred already repeatedly in the NPM ecosystem, but for some mysterious reason those incidents were simply ignored by security teams world wide. Instead of chilling them to the bone, they simply shrugged their shoulders and said "Well, we don't use NPM... I think. Probably?" and went on with their paper-pushing or whatever it is CISOs do these days.
I think this attitude is one of the main issues for this kind of incidents in larger organisations. I'm not sure why you would be willing to lay blame at your colleagues for this. Most of the time, development teams don't tend to like some governance over the code and the dependencies they are pulling in. Not just because they know of course what they are doing, but also because they are under pressure to deliver features. That is what matters for business. Also, convincing management that budget is needed for correct tooling to track all stuff deployed; is also not as straight forward as you seem to suggest.
In this case, the problem goes even beyond just the code of your own dev teams. This is embedded in countless software packages deployed all over your organisation. Same here, people want to buy and use whatever they want. And all processes to keep some form of control over it, are mostly seen as overhead.
And I'm sure they are lots of "security" people who are just producing documents and policies which are complete detached from reality. But developers who consider security completely as somebody else his responsibility, are a problem as well.
The only good think I see coming from this mess, is that security teams probably will get the means to try to get more control and insight over this. For the coming weeks/months at least. After that, everyone in management of dev will be forgotten about it. But something tells me the security people who are working on this right now, won't.
Re: Third High Severity CVE in Log4j Is Published
#284Thanks to all Log4j developers. As users of your free software since ~20 years, we're sure that, if this vuln disclosure had been better and there were no sign of widespread in-the-wild exploitation, you would have done a better job at patching it, and a single release would have been enough. We won't hold a grudge against you; open source means collaboration, and you don't blame hard-working people that give away th…
Wouldn't really thank them.
They found a way to make several catastrophic mistakes while writing a logging solution (one of the most trivial kinds of software) in a memory-safe language.
It's surprising they manage to breathe properly and thus survive.
Re: Third High Severity CVE in Log4j Is Published
#285So, again, why is log4j "evaluating" stuff in log strings? This is the root cause that people should be addressing Why are people still using JDNI? It is frail enough to have logs depend on a dns lookup, I can't imagine depending on a LDAP lookup. This is not such a fundamental issue as the above but it is pretty dangerous. Oh yes and of course one of the worse and least pythonic package in the Python standard librar…
> Why are people still using JDNI?
Because "java:comp/env" is the way for a J2EE web application to get values or objects from the configuration outside its container. Yes, nobody actually uses the remote parts of JNDI anymore, but the local variant (within the same process) is still in use.
And that's what led to this vulnerability: someone wanted to be able to get these local values within the logging configuration, which is a valid use case. Not realizing that this opened the door to remote values and objects.
Re: Third High Severity CVE in Log4j Is Published
#286It's amazing that this library is used by so many large enterprises yet none of them made an effort to thoroughly audit the code (actually, it looks like Alibaba reported the first one. But the point stands that the code was used for so long and by so many.)
Code auditing is extremely expensive. I recently did some napkin math and my estimate is that for our relatively small project (a company of ~10) it would cost between 2 and 12 million dollars to have our rust dependencies audited, with Rust making up ~60% of our codebase. And that's a point in time audit. To maintain that value we'd have to redo the audit periodically. It's just not gonna happen.
This is getting pretty expensive too, though.
Re: Third High Severity CVE in Log4j Is Published
#287Thanks to all Log4j developers. As users of your free software since ~20 years, we're sure that, if this vuln disclosure had been better and there were no sign of widespread in-the-wild exploitation, you would have done a better job at patching it, and a single release would have been enough. We won't hold a grudge against you; open source means collaboration, and you don't blame hard-working people that give away th…
I lay any blame squarely at the feet of IT security of large organisations that were entirely unprepared to update a widely used dependency that wasn't an operating system or a runtime. Windows, Linux, Java, and .NET are all commonly updated, but "modules" aren't. This wasn't just a predictable scenario, it was predicted. Or more accurately, it has occurred already repeatedly in the NPM ecosystem, but for some myster…
> With languages that output a single binary by default such as Rust and Go, we would have been screwed.
no, best practices include checking in your Cargo lock file
Re: Third High Severity CVE in Log4j Is Published
#288Earlier quoted context omitted.
Doing it right sometimes pays off in the long run, but cutting corners always pays off now.
Exactly. Managers and execs love pointing out the cost savings they made this year or this quarter . By the time the chicks start to hatch "in the long run", they most likely would have already moved to another enterprise so someone else has to clean up their mess. And by clean up, I mean repeat exactly the same mistakes since nobody promotes you for implementing stuff that might show its benefits in the long run.
Also one of the root problems with politics. 2035 emissions targets are the next government's problem. Rehabilitative policing pays off in 20 years, retributive buys voters now.
Re: Third High Severity CVE in Log4j Is Published
#289Hopefully this puts an end to those annoying log4j-LOTR memes.
(Unless some hobbits have 3 breakfasts?)
Re: Third High Severity CVE in Log4j Is Published
#290I have never understood why logging has needed such complex frameworks.
Because, this is how we do things in Enterprise.
Okay, more seriously... this is why I am currently staying away from Rust. Because sometimes I don't even know if the random number generation crate I imported for my banking app came from Rust team or some random dude in zanzibar.
(Sorry, I know HN loves Rust, so do I. But I currently that the cargo/crate system is a bit too easy to use and misuse).