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

141–150 of 578 posts

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

#141

Post by Dylan16807 »

Lammy wrote: post #116
BeetleB wrote: post #113

Earlier quoted context omitted.

So if I found a vulnerability that lets hackers withdraw withdraw all the money in your account without a trail on where the money went, you'd be fine with them disclosing it to the public at the same time as the bank learns about it? Even when there is no known use case of the attack (other than the security researcher's)? > The vulnerability exists for me either way, and I'd rather have the chance to know about it…

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

Seeing your other (rightfully flagged) reply I want to tell you as a neutral party that yes this is missing the point of the analogy. You're basically saying "I would simply hit the brakes on the trolley". It's not that they're so hubristic they think it's impossible to legitimately disagree with their argument, it's that mentioning insurance is sidestepping their argument entirely. You're not addressing the general idea of getting hacked and suffering the consequences of the hack.

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

#142

Post by baggy_trough »

seanhunter wrote: post #124
baggy_trough wrote: post #87

Earlier quoted context omitted.

Seems a little crazy. Somebody should evaluate blast radius and do appropriate distro notifications in a case like this (I presume the impact was part of the disclosure, so not much extra work).

You know the linux kernel is a free software project right? If you think “somebody should” do a thing but you aren’t prepared to do it yourself then you should maybe ask for a full refund.

Thank you very much, seanhunter. You hit the nail on the head there.

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

#143

Post by dboreham »

froh wrote: post #60
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…

it's trivial to find out how to report a security issue like this to Linux distros. Google search: https://share.google/aimode/eihDKXZJy94Z5lC1p and it's beyond me to not think about doing this and instead exposing everyone and their neighbor to this exploit up front. I'm certain this is even a felony in some legislations, rightfully so.

Agree it's not a good look for these folks, notwithstanding that disclosure is mostly theater.

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

#144

Post by ryan_n »

stonogo wrote: post #134
ryan_n wrote: post #125

Earlier quoted context omitted.

You're missing the point (not sure if you're just being dense on purpose...). If you're bank would just return the money then its not a good analogy. If someone gains root access to your machine, presumably they can do damage that can't be undone. In other words, to continue the bank analogy, they would take all your money and you would have no way of getting it back. Presumably, you would not be ok with this. And ev…

Respectfully, I don't think they're missing the point. Banking, as an institution, has its flaws, but deposit insurance isn't one of them. These vulnerabilities exist whether or not they follow specific disclosure rituals, and systems should be deployed with defense-in-depth so that one privilege-escalation flaw is a recoverable event. Inventing tortured counterfactual analogies doesn't change the basic thrust of the…

My point specifically is that some damage isn't recoverable if there's a vulnerability that gives someone root access. This makes the bank analogy inadequate in the first place. Im not trying to argue about whether deposit insurance is good or bad. Saying they would get the money back assumes the damage done to ones machine would be recoverable, which may not be the case.

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

#145

Post by Modified3019 »

stonogo wrote: post #134
ryan_n wrote: post #125

Earlier quoted context omitted.

You're missing the point (not sure if you're just being dense on purpose...). If you're bank would just return the money then its not a good analogy. If someone gains root access to your machine, presumably they can do damage that can't be undone. In other words, to continue the bank analogy, they would take all your money and you would have no way of getting it back. Presumably, you would not be ok with this. And ev…

Respectfully, I don't think they're missing the point. Banking, as an institution, has its flaws, but deposit insurance isn't one of them. These vulnerabilities exist whether or not they follow specific disclosure rituals, and systems should be deployed with defense-in-depth so that one privilege-escalation flaw is a recoverable event. Inventing tortured counterfactual analogies doesn't change the basic thrust of the…

My understanding is that FDIC deposit insurance only protects against bank failure, not fraudulent activity. Getting your account drained by an attacker may or may not be covered by a patchwork of other laws at various levels, and you could very well end up shit out of luck.

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

#146

Post by ddtaylor »

999900000999 wrote: post #47
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…

Counterpoint. End users have a right to mitigate this issue on their systems. It is a really really bad look for Linux, puts a bit of water on all hype around switching from Windows.

What happens if someone does the exploit in WSL?

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

#147

Post by akdev1l »

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…

Without read permissions you cannot execute the binary, that would not make any sense.

To execute the binary it needs to be read from disk and loaded into memory.

In fact if you have read permissions but not executable permissions on a specific binary then you can still execute it by calling the linker directly /bin/ld.so.1 /path/to/binary (the linker will read and load the binary and then jump to the entry point without an exec() call)

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

#148

Post by akdev1l »

jayofdoom wrote: post #6
ectospheno wrote: post #3

The Bleeping Computer link below mentions a potential remedy until a patch is ready. https://www.bleepingcomputer.com/news/security/new-linux-cop...

This workaround only applies to kernels with the impacted code compiled as a module. RHEL, Fedora, and Gentoo (we use a modified Fedora config) all are configured to build this in directly. Without a patch or config change (as Sam from Gentoo was alluding to), those distributions remain vulnerable.

F44 is safe as the kernel is greater than 6.18.22

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

#149

Post by [deleted] »

deng wrote: post #37
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…

> It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Yes, this was clearly a marketing stunt to promote Xint code. I, for one, will never use Xint code and will advise everyone to never use it. To anyone working there: enjoy your 15 minutes, I hope this backfires right in your face.

[deleted]

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

#150

Post by Plagman »

akdev1l wrote: post #147
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…

Without read permissions you cannot execute the binary, that would not make any sense. To execute the binary it needs to be read from disk and loaded into memory. In fact if you have read permissions but not executable permissions on a specific binary then you can still execute it by calling the linker directly /bin/ld.so.1 /path/to/binary (the linker will read and load the binary and then jump to the entry point wit…

loader
Post reply on HN