371–380 of 578 posts
Earlier quoted context omitted.
Does it? Now that I see their name again in this context they're blacklisted for life.
Same. I did not know who they were, but now they have been named and shamed. Not every publicity is good.
Seems silly. How many distros need to be notified? There are hundreds.
- Debian
- Ubuntu
- Arch
- Amazon/Azure
- Fedora/RHEL
Earlier quoted context omitted.
Agree, but then where does the accountability lie? Presumably with the kernel maintainers themselves, correct? SOMEONE dropped the ball here. If we can't point the finger correctly, that seems like a problem in of itself.
It looks like the expected thing happened. The kernel devs patched the kernel. The kernel devs have a pretty known, straightforward stance in how they ship fixes for anything, because anything in the kernel can be a security problem. Distro maintainers can see kernel changes. Some distros aggressively track new changes. Others backport what they feel are relevant. Others don’t do either. Users pick what distro they u…
But from what I understand they were not given enough information to know if it was relevant or not. The commit message just said it reverted a change from another commit because there was "no benefit". From the patch itself, it is not at all evident that this is a fix for a critical security bug.
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…
i have no problem with disclosing a vulnerability 30 days after its patched in the thing you reported to. (in fact, for those unaware, this is the same policy that google's project zero uses: "90+30" https://projectzero.google/vulnerability-disclosure-policy.h... ) the real problem is: > It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. the report…
Who would curate that list though? You don't need permission from the kernel team to spin up a new distro. I can go and create fork of Debian or Arch or whatever today and the kernel team would never know (and neither should they).
This is completely in the responsibility of the distros. If you don't like this model, use something like FreeBSD.
Earlier quoted context omitted.
Start a distro with your preferred upstream tracking policy.
Is that the only option here? It’s certainly being framed as such.
Not sure what the solution could/should be, but surely there could be a better, easier mechanism for kernel to advise all distro maintainers who care, and for those distro maintainers to subscribe in some way. Whether any distro maintainers do so (let alone do something about the vuln notifications) would be entirely up to them. There could also be some easier way for end users to see what the distros' policies on this are, such that they can take that into account when selecting a distro.
Earlier quoted context omitted.
The fact that you had to take a whole paragraph to explain the contortionist arrival at something that isn't even really super clear after you explained it (you kinda pointed the finger both at end users and at distro maintainers simultaneously) and essentially boils down to "well, you as the end user need to be following kernel CVE's and can't trust distro maintainers to do it" does in fact indicate that there is a…
The real advantage of Microsoft is that there is someone you can sue! Linux like every open source project is just a bunch of people who are YOLOing it. Not something you use for your fortune 500 critical mission infrastructure.
Earlier quoted context omitted.
i have no problem with disclosing a vulnerability 30 days after its patched in the thing you reported to. (in fact, for those unaware, this is the same policy that google's project zero uses: "90+30" https://projectzero.google/vulnerability-disclosure-policy.h... ) the real problem is: > It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. the report…
> a notification should have gone out from the kernel team to a curated list of distro security folk Who would curate that list though? You don't need permission from the kernel team to spin up a new distro. I can go and create fork of Debian or Arch or whatever today and the kernel team would never know (and neither should they). This is completely in the responsibility of the distros. If you don't like this model,…
You don't need anyone's permission to make a distro, that's true, but if you notify Debian, Canonical, Fedora, Red Hat and Arch you're covering a very large fraction of users; way more than today's 0%. In cases like this, perfect is the enemy of the good.
Earlier quoted context omitted.
> they are in a much better position to coordinate and communicate with the maintainers than random reporters are. They openly refuse to do this and have been given authority by MITRE to work against any such process.
right, which is why it is confusing that the animosity is aimed at the reporters rather than the kernel security team.
Earlier quoted context omitted.
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.
Millions of computers are still vulnerable. Not-knowing about it doesn't mean the vuln isn't there :p
Earlier quoted context omitted.
It is literally not the vulnerability researcher's problem to solve or address this.
Agree, but then where does the accountability lie? Presumably with the kernel maintainers themselves, correct? SOMEONE dropped the ball here. If we can't point the finger correctly, that seems like a problem in of itself.