Hacker News Reader

Comment by john_strinlai | Hacker News Reader

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 kernel team should have a process/channel to say "this is important! disclosure is in 30 days" that is received by distro security teams. because this is not the first or last time the kernel will have a local privilege escalation. hoping that every reporter, forever in the future, will take the onus on themselves is a recipe for disapointment.

View on HN

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.

One of the reasons this unavoidable deadline was invented, is that the alternative is that one company (or all of them) can simply decide to ignore the vuln report, and then the vulnerability will stay forever undisclosed and forever out there in the wild. And prisoner's dilemma suggests that most companies would chose "do nothing" in this scenario: they don't have to do anything, and if the vuln stays undisclosed, it probably won't be exploited anyhow. Win-win!

I'm confused. Can you explain how this applies to the current situation, where no vuln reports were submitted to the groups responsible for distributing patches?

>where no vuln reports were submitted to the groups responsible for distributing patches?

the vulnerability report was submitted to the kernel security team and appropriate kernel maintainers. those are the people responsible for patching the kernel, which they did 30 days ago.

I see, may the people who are responsible for the infrastructure you depend on be less concerned about shifting blame than you are.

imagine you use a dependency in your code. like left-pad. and some vulnerability is found in left-pad.

is the reporter of that vulnerability responsible for finding and submitting a vulnerability report to every single piece of software that uses left-pad? all ~millions of them?

or do they submit the report to left-pad, get them to fix it at the source, and trust that the people relying on left-pad will update their software like they should when they see a security-relevant update is available?

> those are the people responsible for patching the kernel, which they did 30 days ago.

They patched 2 of 7 supported kernels.

Guess the other supported kernels aren't supported enough

> the groups responsible for distributing patches?

Those groups don't exist, to my knowledge. And probably can't, realistically speaking.

`it's technically possible to pass the blame to other people` presupposes that the blame belongs to the reporter unless effort is taken to "shift" it. This is just an inaccurate worldview as many people have pointed out clearly in this discussion. If there's a vulnerability in software the blame lies with people who wrote and maintain the software, not someone who finds and discloses a vulnerability. The person who should `check in on the status of the fixes` is the person who owns the thing being fixed, which is very much the kernel and distro maintainers and not the security researcher. It is you who are willfully shifting blame to an innocent party

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.

> Gentoo has to take some blame too for not keeping all the kernels they maintain patched in a timely way.

How do you figure that? From what I could tell from the earlier post, the fix has only been backported to 6.18 and later, and as TFA indicates the distro's were not informed of the security implications of this fix. All distro's shipping a major kernel version from more than a year ago -- and that includes all LTS kernels -- are vulnerable, regardless of how "timely" their patch schedules follow upstream.

>All distro's shipping a major kernel version from more than a year ago -- and that includes all LTS kernels -- are vulnerable, regardless of how "timely" their patch schedules follow upstream

To be fair, I question the wisdom of managing kernels like that across all distros.

Reply on news.ycombinator.com