Live data from Hacker News

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

openwall.com

31–40 of 578 posts

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

#31

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…

The disclosure was more about marketing than security. From the disclosure page:

> Is your software AI-era safe?

> Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem. [...]

> [Try Xint Code]

More chaos makes their product seem even more attractive.

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

#32
post #31

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…

The disclosure was more about marketing than security. From the disclosure page: > Is your software AI-era safe? > Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem. [...] > [Try Xint Code] More chaos makes their product seem even more attractive.

Your advertising for them on HN would help them too, I bet.

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

#33
post #4

Earlier quoted context omitted.

Expecting people to do the right thing is a fundamental issue here. Why would you ever expect for all of vulnerabilities to be disclosed privately? There's very little actual incentive to do this. I'm honestly unaware of what systems could be put in place to prevent this but expecting people to always do the right thing is fantasy level thinking. I mean I bet the disclosers thought they were doing the right thing, he…

I can accept (and welcome) disclosure before there are patches. But publishing a working exploit together with the disclosure before patches are available is really really irresponsible, maybe even criminal. And no, the proposed mitigations don't help with half of the distributions out there...

AIUI the exploit was fairly low-effort once you knew the vulnerability. So publishing one probably didn't change the landscape much.

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

#34

Earlier quoted context omitted.

The reporter took time to check and mention on their website specific distributions Ubuntu/RHEL/SUSE. One would have thought reporting to security teams of at least those would be responsible.

“One” would have thought? Can you point to a written policy that says that’s how it should be?

No, nor can I point to a written policy that states one should cover one’s mouth when they cough.

Everyone involved here failed to do the right thing, and hiding behind the lack of written words is weak sauce.

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

#35

Earlier quoted context omitted.

“One” would have thought? Can you point to a written policy that says that’s how it should be?

The tenets of decency don’t need to be written down.

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 distros were in a good place to patch before they published the exploit. That's a kindness you can wish for, but don't disparage them for not going that extra mile. It's a bonus.

It's also possible that it simply didn't occur to them to do so this time. There's certainly lessons to be learned either way. I don't know that the right lessons will emerge from hostility.

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

#36
post #26
post #18

Earlier quoted context omitted.

When the exploit is an advertisement for an exploit detection company, not doing the right thing is a bad look

The worst thing would be to exploit or sell it for profit. Instead of that, publicizing the exploit is closer to neutral–good in my books, that did trigger a really quick reaction from the different actors to patch their kernels and systems

Imagine how much quicker the distros would have reacted if they were given a heads up a month ago. But, sure, I guess kudos to this company for not being actively criminal, and merely bumblingly incompetent and overly eager to get their marketing pitch out the door.

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

#37

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.

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

#38

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.

This worked as a mitigation on distros with the module compiled into the kernel: https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464d...

Basically: sudo grubby --update-kernel=ALL --args=initcall_blacklist=algif_aead_init

sudo reboot

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

#39

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 attackers had found this vulnerability and had already been using it prior to this research finding it?

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

#40
post #17

Earlier quoted context omitted.

Basic care would involve making sure the patches had made it into the wild before ending the embargo, and nagging the relevant parties if not. Edit: As of this writing, most distros including Redhat, Fedora, Debian Stable, do not have patches available in the package repos, though they're being actively worked on.

“Made it into the wild?” Patches landed a month ago. Should they also wait until my linksys router from 2018 has a patch ready?

It's a local vulnerability at least. How many people do you let log in to your router?

With the way linux is used these days, I'd guess the number of systems with untrusted local users is pretty limited. Even with shared hosting, you generally have root in your VM or container anyway. Unless this enables an escape from that?

Still the risk that people who run "curl | bash" without care could get bitten, but usually its "curl | sudo bash" anyway...

Post reply on HN