Remix.run Logo
Lammy 6 hours ago

> It was extremely irresponsible

As a user and admin I disagree. Makes one appreciate what a masterful bit of lexical-engineering “Responsible” Disclosure is, kinda like “Secure” (from me, not forme) Boot — “Responsible” Disclosure is 100% about reputation-management for the various corporation/foundation middleman entities sitting between me and my computer.

Those groups don't care that my individual computer is vulnerable but about nobody being able to say “RHEL is vulnerable” or “Ubuntu is vulnerable”. The vulnerability exists for me either way, and I'd rather have the chance to know about it and minimize risk than to be surprised by the fix and hope nothing bad happened in that meantime.

Immediate public disclosure is the only choice that isn't irresponsible as far as I'm concerned.

BeetleB 5 hours ago | parent | next [-]

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 and minimize risk

By the time you hear about it, the money could be gone because 1000 hackers heard about it from the researcher before you did.

> than to be surprised by the fix and hope nothing bad happened in that meantime.

Hope is not a good strategy here.

Lammy 5 hours ago | parent [-]

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

Dylan16807 5 hours ago | parent | next [-]

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.

xorcist 3 hours ago | parent | prev | next [-]

Just socialize losses and all is well.

What could possibly go wrong?

yesbut an hour ago | parent [-]

that is basically how all large companies behave anyway. socialize the losses (bailouts, layoffs, negative economic impacts in the communities they reside, etc.) and privatize the gains.

JamesStuff 4 hours ago | parent | prev | next [-]

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...

Lammy 4 hours ago | parent [-]

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.

ryan_n 5 hours ago | parent | prev | next [-]

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 even if, for some weird reason, you were ok with that, 99.9% of all other people would not be ok with it.

Lammy 5 hours ago | parent | next [-]

[flagged]

stonogo 5 hours ago | parent | prev [-]

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 poster's point: the account is insured, so getting drained by an attacker is not a fatal problem. Of course people should still take steps to prevent that from happening, but that doesn't mean prevention is (or should be) the only cure.

ryan_n 5 hours ago | parent | next [-]

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.

Modified3019 5 hours ago | parent | prev [-]

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.

estimator7292 4 hours ago | parent | prev [-]

"I, personally am not affected, and I don't care about anyone else so therefore there are no consequences"

eschaton 5 hours ago | parent | prev | next [-]

“The choice that maximizes potential damage isn’t irresponsible, because it means I can mitigate my own systems immediately.”

That’s what you’re saying here.

tptacek 5 hours ago | parent | next [-]

They're literally just restating the argument for full disclosure security. This is one of the oldest debates in information security.

0x0 5 hours ago | parent [-]

The disclosure doesn't appear very "full". Looks like this was slipped into mainline linux among dozens of other mostly-irrelevant "CVEs" with nobody highlighting the fact that it is in fact dirty-cow-on-steroids.

https://x.com/spendergrsec/status/2049566830771970483

https://lore.kernel.org/linux-cve-announce/2026042214-CVE-20...

Or is everyone expected to upgrade and reboot every 48 hours for all eternity and just deal with potential regressions all the time?

I think this reflects poorly on the original reporters. If you have a weaponized 700-byte universal local root exploit script ready to go, perhaps you should coordinate with major distros for patches to be available before unleashing it on the world. No matter how "veteran" you are.

tptacek 5 hours ago | parent [-]

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).

judemelancon 3 hours ago | parent [-]

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.

tptacek 3 hours ago | parent [-]

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.

judemelancon 3 hours ago | parent | next [-]

Oh, I thought you meant "everyone" in a sense including actual human persons and the devices on their home network.

0x0 3 hours ago | parent | prev [-]

I find it curious to call someone dropping a weaponized root exploit before major distros or even LTS kernel git branches have patches ready "good guys". This could have been handled with much more grace.

tptacek 2 hours ago | parent [-]

Again: I made the actual distinction between bad guys and good guys clear. Good guys don't become bad guys simply because kernel security is an inconvenience to you.

5 hours ago | parent | prev | next [-]
[deleted]
akerl_ 5 hours ago | parent | prev [-]

What the heck is up with people today.

Using quotes around something where you’re actually doing a strawman paraphrase of another commenter you disagree with is bad form.

tomxor 4 hours ago | parent | prev | next [-]

> Immediate public disclosure is the only choice that isn't irresponsible as far as I'm concerned.

No, it's really not.

High severity vulnerabilities are responsibly handled by quietly neutralising them with subtle patches that do not reveal the vulnerability, waiting for those patches to distribute. Then patching or removing the root cause of the vulnerability (at which point opportunists will start to notice), and finally publicly disclosing it when there are already good mitigations in place.

Example: spectre/meltdowm mitigations.

I've been asked to use this approach myself when reaching out to maintainers. Sometimes it's possible to directly fix the vulnerability as a "side effect" by making a legitimate adjacent change.

efortis 4 hours ago | parent | prev | next [-]

With immediate disclosure the provider can decide to shut down while it is fixed. Or to notify users and make it their decision. Or to be prepared with a diversified infra and switch over to a non-vulnerable path. e.g, BSDs are not affected by CopyFail

notsound 5 hours ago | parent | prev | next [-]

Those groups care about whether millions of computers are vulnerable, likely including your computer. If "immediate public disclosure" was done in all cases every vuln would be exploited and patches would be much lower quality. Shortening the disclosure timeline might be a good idea, 90 days is starting to feel long.

Lammy 5 hours ago | parent [-]

Millions of computers are still vulnerable. Not-knowing about it doesn't mean the vuln isn't there :p

pphysch 5 hours ago | parent | prev [-]

The Venn diagram of mainstream distros and individual Linux users is virtually a circle.

Ubuntu/RHEL is vulnerable and so are most Linux users by extension.