Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

openwall.com

Post reply on HN
Print view View original

181–190 of 578 posts

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

#181

Post by tptacek »

sparker72678 wrote: post #12
semiquaver wrote: post #7

> Note that for Linux kernel vulnerabilities, unless the reporter chooses to bring it to the linux-distros ML, there is no heads-up to distributions. Why would they imply it is incumbent on the reporter to liaise with distributions? That seems to assume a high level of familiarity with the linux project. Vulnerability reporters shouldn’t be responsible for directly working with every downstream consumer of the linux…

Sure, maybe it's not a _requirement_, but now we're all in more pain because the reporters are more interested in Fame than Safe Remediation.

No, you're in more pain, but other defenders with different postures benefit from having faster and fuller disclosure.

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

#182

Post by saysjonathan »

CodesInChaos wrote: post #170
xeeeeeeeeeeenu wrote: post #2

For context, the author of the linked post, Sam James, is a Gentoo developer. Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this. It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. One would hope th…

> Who knows how many shared hosting providers were hacked with this. I'd consider a shared hoster which allows users to run their own (native) code and doesn't use VMs for tenant isolation extremely irresponsible in 2026.

This is probably more common than you think. VMs are expensive, both in resources and cost (if you’re using something commercial). OS-level isolation (shared kernel, cgroups, namespaces) is used pervasively

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

#183

Post by akerl_ »

holowoodman wrote: post #160
akerl_ wrote: post #42

Earlier quoted context omitted.

> maybe even criminal What’s your theory here? What crime?

Exploits are sold and used as weapons, sometimes even weapons of war. Which in many places is criminal, except under very restrictive circumstances. Also, all kinds of aiding and abetting.

What does that have to do with this comment thread?

Copying from the comment I was replying to:

> But publishing a working exploit together with the disclosure before patches are available is really really irresponsible, maybe even criminal

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

#185

Post by Lammy »

JamesStuff wrote: post #163
Lammy wrote: post #116

Earlier quoted context omitted.

Yep, I'd be fine with that. My bank has insurance, and my money would be returned.

The banks cost of insurance goes up, cost of running an account goes up, how do we correct for this? offer worse accounts to customers...

Why do you assume banks would keep on doing the same old thing but paying more because of it? The cost would make them learn not to design systems where something like this hypothetical scenario was possible.

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

#186

Post by sunshowers »

scragz wrote: post #50
tob_scott_a wrote: post #35

Earlier quoted context omitted.

If you can't write it down, why would you expect it to be universal and enforceable? Different cultures exist and have different opinions on what "decency' means, after all. A security researcher's ethical obligations are to protect users over vendors (barring any contractual agreement in place). From what has been discussed in this thread, they meet that bar. Sure, they could have gone the extra mile to ensure the d…

different cultures have different views on disclosing vulnerabilities to distros before the public?

Yes? "Different cultures" doesn't just mean different countries; there are many cultures within infosec.

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

#187

Post by ori_b »

john_strinlai wrote: post #177
ori_b wrote: post #174

Earlier quoted context omitted.

If the maintainers were unresponsive, sure -- but it seems slightly hard to buy that a responsible reporter trying to make a big splash and a good impression wouldn't first check "did this make it out to the distros?" before making sysadmin's days real shitty, even if technically they could point fingers at other parties. At which point, if they're paying paying any attention at all to what they reported, they may ha…

its an industry standard disclosure process. 90 days after reporting, or 30 days after the patch lands, the vuln is disclosed. the linux kernel team is in a 10000% better position to communicate to and coordinate their downstreams. it seems completely backwards to me to suggest that the reporter should be responsible for figuring out every possible downstream and opening up separate reports to each of them. the kerne…

Yes, it's just incompetence from everyone involved, not malice. The company making the disclosure doesn't actually care, and the kernel processes are ineffective.

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

#188

Post by ori_b »

SoftTalker wrote: post #84
dist-epoch wrote: post #75

Earlier quoted context omitted.

With this exploit it's trivial to jump from one container to another neighbor container. I've tried it and succeeded. So containers don't protect you, only a VM.

So anyone pulling a malicious dockerfile jeopardizes the host? That would be bad...

...no shit? Why do you think people care about this issue?

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

#189

Post by staticassertion »

john_strinlai wrote: post #157
xeeeeeeeeeeenu wrote: post #2

For context, the author of the linked post, Sam James, is a Gentoo developer. Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this. It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. One would hope th…

i have no problem with disclosing a vulnerability 30 days after its patched in the thing you reported to. (in fact, for those unaware, this is the same policy that google's project zero uses: "90+30" https://projectzero.google/vulnerability-disclosure-policy.h... ) the real problem is: > It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. the report…

> they are in a much better position to coordinate and communicate with the maintainers than random reporters are.

They openly refuse to do this and have been given authority by MITRE to work against any such process.

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

#190

Post by staticassertion »

watermelon0 wrote: post #96
lifis wrote: post #57

Earlier quoted context omitted.

The Linux kernel is not usable as a security boundary, so anyone who wants to do "shared hosting" and not be hacked needs to use something else, like gVisor or firecracker VMs The only important system that uses it as a security boundary is Android and there is mitigated by the fact that APKs need user approval, plus strict SELinux and seccomp policy plus the GrapheneOS hardening, and in this case the mitigations suc…

I'm quite sure there are many application hosting providers which rely on container runtime such as runC (default runtime of containerd/Docker), and a shared kernel between users.

In a just world, those companies would be held legally accountable for negligent practices. The Linux kernel upstream has made it clear for decades that security is a dirty word.

LPEs on Linux are obscenely commonplace.

Post reply on HN