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.
For Linux kernel vulnerabilities, there is no heads-up to distributions
571–578 of 578 posts
Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#572Earlier 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.
Also it was evening UTC but only like noon Pacific time.
Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#573Earlier 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…
Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#574Earlier 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.
Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#575Whoa, 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.
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
#576Earlier 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.
Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#577Earlier 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…
Re: For Linux kernel vulnerabilities, there is no heads-up to distributions
#578Earlier 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 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.