Live data from Hacker News

For Linux kernel vulnerabilities, there is no heads-up to distributions

openwall.com

571–578 of 578 posts

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#571

Earlier quoted context omitted.

That is just being pedantic. Why did they absolutely need to release this into the wild now? Why couldn’t they have waited? “30 days should be enough time” why? Why is 30 days a magic number? Especially in open source. Yeah it isn’t the researchers problem to tell every distributor of the kernel about the fix or verify that everyone has the fix, but fuck maybe wait until at least someone has the fix and maybe don’t d…

What number of days do you want? If nobody tells the distros it could be months or years, and while it would be nice for the researchers to monitor/notify distros it's really not their job. They might not have thought of it. And they dropped it on a Wednesday.

Yes. I misspoke. It dropped very very late on Wednesday, most of the work started on Thursday and Friday was a Mayday which is a holiday in many if not most places. So fine, on a technicality it wasn't a Friday release, but it might as well have been. They could have easily waited for Monday.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#572

Earlier quoted context omitted.

What number of days do you want? If nobody tells the distros it could be months or years, and while it would be nice for the researchers to monitor/notify distros it's really not their job. They might not have thought of it. And they dropped it on a Wednesday.

Yes. I misspoke. It dropped very very late on Wednesday, most of the work started on Thursday and Friday was a Mayday which is a holiday in many if not most places. So fine, on a technicality it wasn't a Friday release, but it might as well have been. They could have easily waited for Monday.

This is really stretching. Releasing very very late on a "Thursday" is fine. That gives you an entire day to pause everything else, set up mitigations, and see if things still seem to be working. If a whole work day isn't enough then you were probably going to have trouble no matter what day of the week they published. Late late "Thursday" doesn't have to be your favorite but it's not malicious.

Also it was evening UTC but only like noon Pacific time.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#573

Earlier quoted context omitted.

Distributions using outdated (sorry “stable”) kernels are stupid. We are not 20 years ago, the world in which it made sense doesn’t exist anymore, but the industry is slow to move on. Just pick a long term release and update it regularly.

Yes. Distros (point release distros) should use LTS kernels and keep up to date with them. Their "we'll maintain our own kernel branches" model either leads to many missed bugfixes, or duplicates Greg K-H's workload internally, for no practical benefit. If a distro is suspicious of particular patches in the -stable tree, they could maintain a blacklist of them. However, instead of doing that and accruing overhead of…

Unfortunately not all of the LTS kernels were updated with this patch before the public disclosure.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#574
post #363

Earlier quoted context omitted.

> I'd also prefer immediate disclosure wait, what? you are in another comment thread, of this very post, calling these reporters bumbling and incompetent for their disclosure. "merely bumblingly incompetent and overly eager to get their marketing pitch out the door " - that is your quote. you also said "Basic care would involve making sure the patches had made it into the wild before ending the embargo ", which is th…

Yes, if you release the vulnerability as soon as possible, that's a good choice. If you have an embargo and make sure that fixes get out to users in a timely manner before ending the embargo, that's also a reasonable choice. If you're going wait a month between landing the patch (possibly notifying attackers), but not notify the people who may get the patch to users, it seems like something was mishandled.

What if you try to go with the second option but the vendor barely puts any effort into getting the fix out to user and then it's a year later and the vulnerability is still under embargo? Maybe you decide that the next time you find a vulnerability you want to light a fire under the vendor by giving them a fixed deadline to get the fix out to users. A month seems like a reasonable deadline for that sort of thing.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#575

Whoa, what the heck!? When I read the site yesterday, I wondered why they disclosed such a critical but (root access on any shell!!!) without waiting a long while for vulnerable systems to be updated . it’s abhorrent to see that they didn’t even wait for an update to release in the first place.

It's not abhorrent. It's quite common and the correct thing to do here.

Them not disclosing doesn't make you safer. The people that want to abuse this could be actively exploiting it shortly after the commit went live. Waiting more time before the blog / marketing release is NOT the help you think it will be.

This is a very, very, old debate in the security community, just read the rest of this thread and you'll see plenty of explanation as to why.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#576

Earlier quoted context omitted.

As much as I like linux, this is stupid.

Distributions using outdated (sorry “stable”) kernels are stupid. We are not 20 years ago, the world in which it made sense doesn’t exist anymore, but the industry is slow to move on. Just pick a long term release and update it regularly.

Fair enough.

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#577
post #463

Earlier quoted context omitted.

The fact that you had to take a whole paragraph to explain the contortionist arrival at something that isn't even really super clear after you explained it (you kinda pointed the finger both at end users and at distro maintainers simultaneously) and essentially boils down to "well, you as the end user need to be following kernel CVE's and can't trust distro maintainers to do it" does in fact indicate that there is a…

> In terms of something actionable, and maybe someone more well versed in how the distros work can tell me why this is a bad idea, but shouldn't there be a documented process and channel for critical CVE's to be bubbled out to distro maintainers who then have some sort of SLA for patching them and sending them downstream to end users? Perhaps incentives are not aligned to produce this outcome. Who decides who is a tr…

I wanted to share with you that I took some time to reflect on this response and I now agree that this is correct. To ask Linux to add some central authority, no matter how good-intended it is, is antithetical to how Linux works. We must accept that this is a side effect of the purism that requires Linux to function. Can we do better? Probably. But we shouldn’t give up the point of why we are doing this in the first place - and to declare such centralized authority would be doing so, IMO

Re: For Linux kernel vulnerabilities, there is no heads-up to distributions

#578

Earlier quoted context omitted.

This is the effect of "every vulnerability is a bug" and "we can't rate the severity of any vulnerabilities". Which very clearly results in "bugfixes" (security patches) not making it everywhere in time because it's just simply ridiculous to ask for each downstream consumer to rate the severity of everything on their own. It's easy to shit on CVEs, some even put out shit CVEs, but at the same time contribute absolute…

They can't . Linux has too high a profile. Any additional "in group" that had access to embargoed critical security information would have a much higher chance of being compromised. The solution is not to tell more people that patch xxxxxx is a critical security bugfix that needs distros to roll new kernel versions immediately. Major vendors (all the cloud providers) will have security teams that can have the bug mit…

I used to be work in a group that 'managed' this information a while back. I used to work in redhat product security dealing with embargoed flaws and disclosure dates, it was non trivial to get this process managed.

I do think that its the right thing to do, if the reporter is willing to come to the party, but I also understand why if they dont want to.

> Part of the solution is each distro needs a process for > pushing critical updates (module blacklists, ebpf patches) > to address things like this without forcing all distro > users to reboot, which many won't do promptly anyway.

Almost like a 'mitigation tool' that doesn't require expertise on the users end, but on the providers end.

Post reply on HN