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

211–220 of 578 posts

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

#211

Post by john_strinlai »

bragr wrote: post #210
john_strinlai wrote: post #177

Earlier quoted context omitted.

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…

The problem is that if you make too big of a deal about a particular patch, then someone just reverse engineers the vuln from the fix and your responsible disclosure period doesn't exist anymore. Gentoo has to take some blame too for not keeping all the kernels they maintain patched in a timely way.

you minimize this with the curated contact list.

the baddies are looking at every patch anyways.

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

#212

Post by Denvercoder9 »

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…

Two things can be true simultaneously: the Linux kernel ecosystem should have done better at communicating this to their downstreams, and publicly sharing the exploit was irresponsible.

It is not the responsibility of the initial reporter to communicate to distributions, but the fact that those responsible failed to do that, doesn't give everybody else a free pass.

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

#213

Post by staticassertion »

baggy_trough wrote: post #205
staticassertion wrote: post #200

Earlier quoted context omitted.

Greg and Linus do not believe in the entire concept of "vulnerabilities" in the Linux kernel and do not believe in the methods that distros use like cherry picking, therefor they typically are against issuing CVEs, scoring CVEs, describing vulnerabilities at all (if you use the word "vulnerability", your patch will be rejected), etc. It's fundamentally their position to not work the way that you describe.

That doesn't really seem to map onto the situation since Greg himself released a 6.12 with the patch earlier today.

I don't know what you mean at all. I'm just repeating known kernel policy here. What does 6.12 have to do with anything?

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

#215

Post by tptacek »

judemelancon wrote: post #207
tptacek wrote: post #133

Earlier quoted context omitted.

Um, yes, everyone is expected to upgrade and reboot on a moment's notice. No policy or norm you come up with will change that. (This bug does not technically require a reboot to mitigate).

I think I must misunderstand. Are you saying that you upgrade and reboot every production system that you administer to apply each commit to the kernel (branch it's using) essentially immediately? That doesn't make sense to me for a few reasons, but I struggle to find a different reading that applies "upgrade and reboot on a moment's notice" to the "slipped into mainline linux" scenario. Kindly help me to do so.

No: your posture with respect to having to cycle servers is a super complicated subject and you address it both with process and with architecture (for instance: you can be blasé about things like CopyFail if you don't allow multitenant shared-kernel in your design in the first place). But no matter what process and design you have, if you're hosting sensitive workloads, you always have to be in a position where you can metabolize having to cycle your servers.

It's a category error to talk about a disclosure event like this as something that would destabilize someone's fleet operations. The Linux kernel is fallible. So is the x64 architecture. You already have to be ready to lock things down and reboot (or mitigate) at a moment's notice.

Remember: whatever else grumpy sysadmins have to say about this, Xint are the good guys. Contrast them with the bad guys, who have vulnerabilities just as bad as CopyFail, but aren't disclosing them at all --- you only find out about them when it's discovered they're actively be exploited. There's no patch at all. There isn't even a characterization of how they work, so that you could quickly see what to seccomp. That's the actual threat environment serious Linux shops operate in.

LPEs are not rare.

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

#216

Post by john_strinlai »

Denvercoder9 wrote: post #212
john_strinlai wrote: post #157

Earlier quoted context omitted.

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…

Two things can be true simultaneously: the Linux kernel ecosystem should have done better at communicating this to their downstreams, and publicly sharing the exploit was irresponsible. It is not the responsibility of the initial reporter to communicate to distributions, but the fact that those responsible failed to do that, doesn't give everybody else a free pass.

>publicly sharing the exploit was irresponsible

they did it in the established industry standard way that probably every single security researcher you can think of follows (for good reason, i would add).

whoever did the marketing on "responsible disclosure" was a genius.

tptacek says it much better than me: ""Responsible disclosure" is an Orwellian term cooked up between @Stake and Microsoft and other large vendors to coerce researchers into synchronizing with vendor release schedules."

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

#217

Post by Denvercoder9 »

Skywalker13 wrote: post #214

I have checked all the servers (bookworm, bullseye) that I manage, and none of them have the algif_aead module loaded. Seems not fatal to all non-patched systems.

Not having the module loaded doesn't mean you're not vulnerable, the kernel loads the module on-demand when it's needed. I tried the exploit on such a system, and it worked.

However, not having the module loaded does mean that in normal operation you don't need the module, so the proposed mitigation of disabling the module is safe in the sense that it won't disrupt anything.

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

#219

Post by xorcist »

KingMachiavelli wrote: post #132

`nosuid` and probably `nodev` should IMO be the default filesystem mount options. `/dev` is already a special devtmpfs and the initrd minimal /dev can just explicitly mount the initrd tmpfs rootfs with `dev` and `suid` if necessary. Letting SUID binaries just "exist" anywhere is a stupendous security issue. What if you mount some external storage medium, how are you to verify that none of the SUID binaries on that bl…

The proof of concept exploit is just that. It is meant to demonstrate one attack vector only. There are many others. If your goal is to prevent the conceptual exploit only then there are many easier ways to accomplish that, such as blacklisting, that does not make you safer.

With this vulnerability you can manipulate the page cache. You could also manipulate ld.so to hook into arbitraty system calls, or set your uid to 0, or any of another dozen or so ways to elevate your privileges.

Mount points have nothing to do with this, even if is always a good idea to disallow suid in user writable areas and prevent reading suid files, but that's for other reasons. NixOS does nothing to fix this and is just as vulnerable as everyone else.

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

#220

Post by ori_b »

tptacek wrote: post #197
ori_b wrote: post #187

Earlier quoted context omitted.

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.

No, it's incompetence from everyone involved except the company making the disclosure , which, despite the fact that the existing norms are not in fact binding (like people downthread seem to believe), they followed.

Really? It seems very odd to not check in on the status of the fixes, even if it's technically possible to pass the blame to other people.

Even if the only purpose of looking at the status to make yourself look good in marketing materials, it's surprising that it didn't happen.

Post reply on HN