upvote

points

by ori_b16 hours ago |
comments
upvoteby john_strinlai16 hours ago|
[-]
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.

reply
upvoteby bragr15 hours ago|
parent|
next
[-]
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.

reply
upvoteby tremon13 hours ago|
parent|
next
[-]
> 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.

reply
upvoteby john_strinlai15 hours ago|
parent|
prev|
[-]
you minimize this with the curated contact list.

the baddies are looking at every patch anyways.

reply
upvoteby ori_b16 hours ago|
parent|
prev|
[-]
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.
reply
upvoteby tptacek15 hours ago|
parent|
[-]
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.
reply
upvoteby 12 hours ago|
parent|
next
[-]
deleted
reply
upvoteby ori_b15 hours ago|
parent|
prev|
[-]
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.

reply
upvoteby 9question114 hours ago|
parent|
next
[-]
`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
reply
upvoteby Joker_vD15 hours ago|
parent|
prev|
[-]
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!
reply
upvoteby ori_b14 hours ago|
parent|
[-]
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?
reply
upvoteby john_strinlai14 hours ago|
parent|
next
[-]
>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.

reply
upvoteby pseudalopex10 hours ago|
parent|
next
[-]
> those are the people responsible for patching the kernel, which they did 30 days ago.

They patched 2 of 7 supported kernels.

reply
upvoteby dwattttt6 hours ago|
parent|
[-]
Guess the other supported kernels aren't supported enough
reply
upvoteby ori_b14 hours ago|
parent|
prev|
[-]
I see, may the people who are responsible for the infrastructure you depend on be less concerned about shifting blame than you are.
reply
upvoteby john_strinlai14 hours ago|
parent|
[-]
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?

reply
upvoteby Joker_vD13 hours ago|
parent|
prev|
[-]
> the groups responsible for distributing patches?

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

reply
upvoteby 6 hours ago|
parent|
[-]
deleted
reply