561–570 of 578 posts
Earlier quoted context omitted.
This is such a 1996 argument. It really was a big deal back then whether you had compilers on your multiuser SunOS boxes, because attackers would then use them to compile exploit.c. The whole thread, really bringing me back to comp.security.unix. I'm not complaining! I miss comp.security.unix.
[flagged]
Earlier quoted context omitted.
Seems like a classification you just made up to navigate a message board debate: the category that equates commercial vulnerability research for security products and people who sell zero-day vulnerabilities to bad guys.
People who sell zero-day vulnerabilities currently sell to both good guys and bad guys, they’re a third thing (mercenaries). However, that third thing is also bad, just a different kind of bad than what you’re calling “bad guys.” The people selling weapons to the Taliban aren’t bad in the same way the Taliban are; one is bad for ideological reasons, the other is bad for enabling bad actors, even if they also sell to…
Earlier quoted context omitted.
I'm suggesting that less information about the vulnerability could be circulated than the current process, not more, due to distro maintainers being able to trust just "version X contains a fix for a high-impact security vulnerability" coming from a kernel maintainer - whereas they'll need some information/proof of that claim when coming from an outsider.
The information exposed in the current process was: code changes in the git commits and a commit message that did not mention the vulnerability. In the current model, attackers are actively looking at all commits as potential vulnerabilities, regardless of what anybody says or doesn’t say about them. You can’t make the commits not exist, or not be visible, because that’s a core part of how the kernel is developed and…
Idea with the current process is for the researcher to email distro maintainers about the vulnerability - that's the part I believe could make more sense to be done by a kernel maintainer so that less information about the vulnerability has to be shared around (distro maintainers can just trust the word of the kernel maintainer that a vulnerability exists and is serious, without further evidence).
> [...] existence of a vuln, or a nudge to patch with no context, or whatever, is totally irrelevant and does not change the calculus: the moment the fix is committed, bad actors who were not already aware notice it
I'd claim this is too much binary thinking - not every vulnerability will be immediately found by every bad actor just from a well-disguised commit (like here). There are many more commits refactoring parts of code or removing complexity that don't hide a known vulnerability. More information available about the vulnerability will expedite its discovery and exploitation, so it makes sense to minimize that information where it's not necessary.
Earlier quoted context omitted.
The information exposed in the current process was: code changes in the git commits and a commit message that did not mention the vulnerability. In the current model, attackers are actively looking at all commits as potential vulnerabilities, regardless of what anybody says or doesn’t say about them. You can’t make the commits not exist, or not be visible, because that’s a core part of how the kernel is developed and…
> The information exposed in the current process was: code changes in the git commits and a commit message that did not mention the vulnerability. Idea with the current process is for the researcher to email distro maintainers about the vulnerability - that's the part I believe could make more sense to be done by a kernel maintainer so that less information about the vulnerability has to be shared around (distro main…
A proposal where there is an unmarked commit and then anybody tells anybody anything about the fix including a security remediation is strictly more information being disclosed into the world.
Also you’re just wrong about the ability of bad actors to identify vuln remediations (and consequently vulns) by looking at commits to major projects. I don’t know what else to say here other than that this is happening, and is easily attainable via the current combination of human expertise and automated tools.
Earlier quoted context omitted.
> The information exposed in the current process was: code changes in the git commits and a commit message that did not mention the vulnerability. Idea with the current process is for the researcher to email distro maintainers about the vulnerability - that's the part I believe could make more sense to be done by a kernel maintainer so that less information about the vulnerability has to be shared around (distro main…
Again, the current flow was that the researchers only reported the vuln to kernel devs, who then committed a fix with no flag that it was a security fix. A proposal where there is an unmarked commit and then anybody tells anybody anything about the fix including a security remediation is strictly more information being disclosed into the world. Also you’re just wrong about the ability of bad actors to identify vuln r…
That's what happened in this case, but the current idea/expectation (according to what was linked in the comment chain I replied to) seems to be that the researcher would email the distro maintainers with information:
> > Notify security@kernel.org, linux-distros@vs.openwall.org and relevant maintainers of the vulnerability; establishing details, embargo period, CVE request and possible fix
This is the process I'm suggesting could make more sense if it was instead the kernel maintainers alerting distro maintainers (with no more detail than necessary) after a fix has made it in. Should also be less fallible than relying on the researcher to do so.
> Also you’re just wrong about the ability of bad actors to identify vuln remediations (and consequently vulns) by looking at commits to major projects. I don’t know what else to say here other than that this is happening, and is easily attainable via the current combination of human expertise and automated tools
I don't deny that bad actors can figure out vulnerabilities from tracking commits, but removing or refactoring some subsystem does not immediately give all bad actors a full list of vulnerabilities with the old version. Developing an abusable exploit chain (as may be shown by the researcher to justify high priority patching) is also not necessarily trivial even if they do figure out an issue that was fixed.
it’s abhorrent to see that they didn’t even wait for an update to release in the first place.
Earlier quoted context omitted.
People who sell zero-day vulnerabilities currently sell to both good guys and bad guys, they’re a third thing (mercenaries). However, that third thing is also bad, just a different kind of bad than what you’re calling “bad guys.” The people selling weapons to the Taliban aren’t bad in the same way the Taliban are; one is bad for ideological reasons, the other is bad for enabling bad actors, even if they also sell to…
Whatever the entity you're thinking of that sells exploits/"CNE enablement packages", they're not in the same bucket as entities that find and disclose vulnerabilities.
Earlier quoted context omitted.
Whatever the entity you're thinking of that sells exploits/"CNE enablement packages", they're not in the same bucket as entities that find and disclose vulnerabilities.
Sounds like bounties are unnecessary then. The argument I’ve always seen for them is that if they don’t exist and aren’t substantial enough, the research will still happen but the results will go to the highest bidder.
Earlier quoted context omitted.
Sounds like bounties are unnecessary then. The argument I’ve always seen for them is that if they don’t exist and aren’t substantial enough, the research will still happen but the results will go to the highest bidder.
You've never seen me argue that bounties are necessary.
Earlier quoted context omitted.
I think it's an extension of the premise that you should just be taking the whole stable tree with all its patches constantly, whether they're labeled as security fixes or not, because you can never really know for sure some bugs weren't security bugs. I don't agree with the premise, but I do think it's a sincerely held one.
I dunno, if you think about it for more than a few seconds you can see the obvious holes in it, like it's definitely true that some bugs are " may allow RCE", but you also can do a LOT better than not even trying. And even if you do say "we're not putting the effort in to backport security fixes" (which is fine), that doesn't entail "security bugs are just bugs". These are smart people. If it wasn't about their own p…
People can earnestly believe illogical or inconsistent things. Arguably those are even easier to get stuck believing, as you already had to accept some friction in the inconsistencies earlier in your internalizing them, so now you're even further into sunk costs around it.