News for hackers. Stuff that matters.
[dead]
Re:Third High Severity CVE in Log4j Is Published by alanfranz on Saturday December 18, 2021 @12:24PM (#29606336)
This attitude should stop. They're volunteers. It's open source. Users are required to use such piece of software at their own will and risk. Log4j didn't ever get a single penny from most (all?) of their users, and now they should take all the blame. Why?

The disclosure process was terrible, they clearly had no time to perform a thorough validation of the hotfixes, and this is the result. Why didn't anybody else step up to help them? Did any of the large companies using log4j pour some thousand dollars into the Apache foundation to let a couple of security-oriented engineers take a complete review of the patches?

But then, it's log4j developers and Apache that should be blamed. Bah. That's SO pretentious.

Re:Third High Severity CVE in Log4j Is Published by laumars on Saturday December 18, 2021 @03:56PM (#29608425)
> The disclosure process was terrible, they clearly had no time to perform a thorough validation of the hotfixes, and this is the result.

Even with proper disclosure, patching can be harder than it seems at face value. Take shellshock (the bash RCE from 2014) for example, the first patch was released a week after discovery and publication happened after the patch was released. Yet there were still a flurry of further CVEs found and further emergency patches required as a result.

The problem is once a major vulnerability is discovered, you then have a the worldwide attention focused on that specific vulnerability looking for other ways to break it. So it’s not really a surprise that you find multiple CVEs for most major vulnerabilities.

Re:Third High Severity CVE in Log4j Is Published by wbl on Saturday December 18, 2021 @12:36PM (#29606487)
Log4J is bigger than all of V7 Unix. What do you need all that for?
Re:Third High Severity CVE in Log4j Is Published by kabdib on Saturday December 18, 2021 @01:32PM (#29607087)
Because the only unsolved problem in logging libraries is: "When do I stop adding features?"

Decent logging is surprisingly complicated, but it's not "We need an arrrchitecturreee! for infinitely configurable logging or we are utterly doomed" complicated.

[dead]
Re:Third High Severity CVE in Log4j Is Published by alanfranz on Saturday December 18, 2021 @12:53PM (#29606660)
If you don’t use the code, you’re not vulnerable

> who should get the blame? The users?

If you leverage a ton of open source deps, shit is going to happen. You should not blame anyone.

But if you must, yes: blame the users that choose such piss-poor software.

Re:Third High Severity CVE in Log4j Is Published by dylan604 on Saturday December 18, 2021 @02:08PM (#29607509)
Just because someone releases code with AS IS/NO WARRANTY/BLAH BLAH BLAH doesn't mean they should not get called out for introducing such a vuln. Yes, you chose the code, failed to evaluate it's security, etc, but at the end of they day, the Log4* devs made a very very bad decision. Sadly, because of it's deep use in so many projects, it has kind of become too big to fail. I doubt %1 of users will swap out the logging package for something else. They will all wait for the Log4 devs to keep releasing updates.

People keep singing the praises of FOSS, but yet whenever this kind of shit happens, it's always the user's fault for choosing poorly which packages are being used. I'm saying that the original devs are criminals, but they did the original sin here. The fault ultimately lies at their feet. Why is this such a unrespected point of view?

Re:Third High Severity CVE in Log4j Is Published by alanfranz on Saturday December 18, 2021 @02:48PM (#29607891)
Discussion is ok. Disrespect is not.

What original sin? What fault? You’re basically saying that log4j developers lured you into temptation, otherwise you would have coded your own logging library, which, for sure, would have been better.

I haven’t seen 1/100 of this hatred for Apple iMessage vuln that led to NSO zero-click exploits, and I don’t get why.

Re:Third High Severity CVE in Log4j Is Published by filmgirlcw on Saturday December 18, 2021 @03:29PM (#29608217)
> I haven’t seen 1/100 of this hatred for Apple iMessage vuln that led to NSO zero-click exploits, and I don’t get why.

I think there are a few reasons for this, and most of them aren’t based on logic, but emotion.

First, as bad as the NSO zero-click exploits are, they aren’t things that developers were potentially injecting into their own projects. So there is an easier force to “blame” — Apple (for making the mistakes in the first place — and to be clear, all software can have bugs) and NSO Group (for being pieces of shit) — whereas if you either chose Log4j for your own project, or more likely, chose a project/product that chose to use Log4j, the “who to blame” question becomes a lot less comfortable to answer.

At least with the NSO thing, there is a face of who the bad guy is. So it’s easy to sort of not hate Apple, provided Apple patched exploits as soon as they found them. That doesn’t mean that Apple, a company that has used its “better” security relative to its competitors one of its marketing messages, gets off easy. It’s a black mark for them for sure and will make it harder for the company to argue that it is so much more secure than x, y, z service or platform.

With Log4j, similar to OpenSSL, people have to grapple with the reality that they don’t really know a lot about a lot of the code they run — and even worse, acknowledge that they aren’t capable of understanding or auditing that code themselves. I certainly don’t understand a lot of the code and libraries I rely on for things I build. And if I really stop to think about that, that’s scary. Fortunately, my own projects are personal and aren’t taking data from others. But facing that reality can be a difficult pill to swallow. And Log4j is even worse than OpenSSL in a way, because one could be forgiven for having trust in a well-respected cryptographic library, and for not having a deep understanding of how that library works. But having an insecure logging library? That almost feels avoidable — even if it isn’t.

So people want to blame someone. And when it looks like the code — made by volunteers or not — wasn’t the best written, that’s an easy thing to go to. Rather than self-reflecting about all the libraries we use every day that we don’t think about the security or code quality of.

It doesn’t help that the disclosure, for a host of reasons, wasn’t good. That isn’t me blaming the Log4j team, it just is what it is. Disclosure wasn’t great and the fury to patch made some mistakes and now that there is outsized attention on the library, even more vulnerabilities have been found. Which is all understandable and indicative of what often happens in high stress situations.

Ultimately, we should all accept that mistakes happen and that this wasn’t done out of malice. We all have some level of culpability for what we choose to use in our projects. But mistakes happen.

And as you say, discussion is OK but disrespect isn’t. But I think we see lashing out because people want to find someone to blame.

Re:Third High Severity CVE in Log4j Is Published by jjav on Saturday December 18, 2021 @05:23PM (#29609158)
It's actually fairly similar to the Apple bug, in that it was also a library with unnecessarily complex functionality that wasn't needed for the use case but just came along for the ride and ended up exploitable.
Re:Third High Severity CVE in Log4j Is Published by dylan604 on Saturday December 18, 2021 @04:53PM (#29608913)
Disrespect for calling a spade a spade? Where have we found ourselves?

No, I would never use a logging library, so there was no luring. If you want to call those that did use it lured, then you're already coming at it that the original software devs were coniving.

Re:Third High Severity CVE in Log4j Is Published by 5e92cb50239222b on Saturday December 18, 2021 @02:27PM (#29607692)
Would it be any better if this library was a proprietary product, the vulnerability would have been discovered by NSA and exploited until the end of time?

Come to think of it, they wouldn't even have to search for any exploits. Just ask devs nicely to put the backdoor in and be done with it.

Re:Third High Severity CVE in Log4j Is Published by kafkaIncarnate on Saturday December 18, 2021 @04:10PM (#29608538)
Who said anything about 'nicely'? Or 'ask'?
Re:Third High Severity CVE in Log4j Is Published by TedDoesntTalk on Saturday December 18, 2021 @03:51PM (#29608384)
> I'm saying that the original devs are criminals

That’s an unbelievable stretch. I wonder how your mind works.

Re:Third High Severity CVE in Log4j Is Published by dylan604 on Saturday December 18, 2021 @05:19PM (#29609123)
Sorry, I absolutely meant to include NOT in that sentence. No, I do not believe they are criminals. I am guilty of not double checking my post to make sure it says what I meant to say.
Re:Third High Severity CVE in Log4j Is Published by samhw on Saturday December 18, 2021 @02:13PM (#29607561)
This comment isn't even consistent with itself. First you say:

> Who should get the blame then, the users? Duh, no.

And then you say:

> I don't use the code, so why in the world should I be expected to fix the code? Do you use the code? Why didn't YOU fix it?

Just take a step back, stop trying to throw shade at anyone and everyone, and look at the situation analytically.

I don't really see the point of these comments. The people who make a contribution to the world are the people who see a problem and take practical steps to fix it and improve the situation, rather than the people who see a problem and immediately descend into finger-pointing and shouting.

Re:Third High Severity CVE in Log4j Is Published by thowaway202107 on Saturday December 18, 2021 @01:23PM (#29606991)
> Um, yeah. They wrote the idiotic code that allowed this to happen.

And released it with NO WARRANTY. And no mega corp thought it’d be a good idea to try and buy one.

> To me, this is the pretentious part. I didn't write the code, I don't use the code, so why in the world should I be expected to fix the code? Do you use the code? Why didn't YOU fix it?

If you don’t use it, then noone’s expecting you to fix anything. But those out there using it for free, complaining that it’s broken, and not doing anything to help? They should hush their hush holes. Or open pull requests. But mostly hush their hush holes.

Re:Third High Severity CVE in Log4j Is Published by grafs50 on Saturday December 18, 2021 @12:57PM (#29606687)
I don't understand what the problem is if you don't use the code. Why does it matter to you if it gets fixed?
Re:Third High Severity CVE in Log4j Is Published by thowaway202107 on Saturday December 18, 2021 @01:24PM (#29607007)
Not approving of what OP said, I’d point out that everyone has an interest in it being fixed, because it’s a wide spread and severe CVE that impacts lots of software that we all probably use daily without knowing it.
Re:Third High Severity CVE in Log4j Is Published by dylan604 on Saturday December 18, 2021 @01:50PM (#29607311)
I use services that do use that code though, so I am affected when it goes down
Re:Third High Severity CVE in Log4j Is Published by yawaramin on Saturday December 18, 2021 @05:47PM (#29609378)
Then you should blame the people who provide those services for going down. Not the open source libraries that they chose to use.
Re:Third High Severity CVE in Log4j Is Published by klyrs on Saturday December 18, 2021 @12:37PM (#29606488)
Having worked with security-minded institutions in the past, I've endured and participated in year(s)-long audits of three different open source software projects. The thing that amazes me is that nobody using this software ever did their due diligence. You literally get what you pay for. Kindly step on your own legos and be happy this didn't happen in early April.
Re:Third High Severity CVE in Log4j Is Published by bob1029 on Saturday December 18, 2021 @01:17PM (#29606925)
> The thing that amazes me is that nobody using this software ever did their due diligence.

How could they be expected to? Reviewing all of the source code for log4j is not a walk in the park. Even if you thoroughly reviewed all the source code, would this specific exploit have crossed your mind?

The game theory and assumptions around a "logging" library probably led a lot of organizations to not even consider it a potential threat and focus their efforts elsewhere.

There is also the transitive dependency angle which turns this into more of a plague than a blame assignment session.

Re:Third High Severity CVE in Log4j Is Published by jjav on Saturday December 18, 2021 @05:31PM (#29609229)
> How could they be expected to? Reviewing all of the source code for log4j is not a walk in the park. Even if you thoroughly reviewed all the source code, would this specific exploit have crossed your mind?

Back a long time ago, companies were extremely wary of including any open source library (let alone thousands!) into their product. It took a very long time with audits, lawyers, etc to get a single library approved.

Yes, it was kind of a pain.

So the world has swung into the other extreme these days. Just pull in a couple thousand libraries from the internet, nobody knows what they even are or what's in them. All in the name of speed. So it has its benefits.

But the fundamental concerns of long ago are still there. Bringing in unreviewed third party code is a vector for vulnerabilities, supply chain attacks and all that joy.

Re:Third High Severity CVE in Log4j Is Published by klyrs on Saturday December 18, 2021 @01:41PM (#29607198)
I don't expect every user to audit code. But one of the audits I was privvy to was a part of the federal government and had really stringent requirements for the code that they run -- which, of course, includes tracking down all the dependencies, and, yes, is expensive. The fact that this extremely widely-used project never hit such an audit is a curiosity. And a bit of a tragedy of the commons -- many millions of dollars of commerce has depended on this project, and now folks are up in arms because every individual decided that it wasn't their problem to investigate.
Re:Third High Severity CVE in Log4j Is Published by TedDoesntTalk on Saturday December 18, 2021 @03:53PM (#29608397)
Even with an audit and 100% unit test coverage, and static code analysis, vulnerabilities slip through. Software is not perfect and you do not have a silver bullet.
Re:Third High Severity CVE in Log4j Is Published by klyrs on Saturday December 18, 2021 @03:58PM (#29608436)
I'd agree if this was the first CVE. But that got some attention to log4j, which quickly exposed two more CVEs. There's no such thing as perfect, but these problems almost certainly would have been caught by a competent security audit.
Re:Third High Severity CVE in Log4j Is Published by TedDoesntTalk on Saturday December 18, 2021 @04:25PM (#29608669)
Has any of your software been through a security audit? Mine has. It’s 99.9% OWASP coverage with some automated fuzzing with almost no imagination applied by the auditors. You’re assigning far too much ability to auditors.
Re:Third High Severity CVE in Log4j Is Published by klyrs on Saturday December 18, 2021 @04:33PM (#29608738)
Upthread, I mentioned that I've been party to it three times. And yes, auditor skill and methods vary.
Re:Third High Severity CVE in Log4j Is Published by jacquesm on Saturday December 18, 2021 @02:03PM (#29607440)
Indeed. Every Node.js/npm installation, ever.
Re:Third High Severity CVE in Log4j Is Published by tekknik on Sunday December 19, 2021 @08:11AM (#29613637)
> Reviewing all of the source code for log4j is not a walk in the park.

Traditionally if something is too large to audit then you shouldn’t use it, which few exceptions (like Linux). Maybe this should be a red flag in the future, especially for a logging library that can almost be replaced with a call to stdout and a log collector.

Re:Third High Severity CVE in Log4j Is Published by humanistbot on Saturday December 18, 2021 @12:40PM (#29606528)
On behalf of open source software developers, go pay for commercial software yourself.
Re:Third High Severity CVE in Log4j Is Published by renewiltord on Sunday December 19, 2021 @05:22AM (#29612776)
Surely it has to be a joke. An infosec guy who only tells you something is insecure after you know from the news is kind of useless.

The point is to keep you secure, not be a slow news relay. In that regard, GP is just really bad at his job.