Don't have the chops to vet the paper myself; those of you who do deep CS want to comment? @LeaKissner @yonatanzunger @FioraAeterna and all my other friends.https://twitter.com/polytomous/status/1025869511004577792 …
It sounds very plausible that it does make things harder for the ones who are actually white hats or who at least prefer to disclose in less-/non-harmful ways, leading to highly funded attackers with in-house researchers finding and using the real vulns first.
-
-
im pretty sure that's how things already are
-
Indeed, but further in that direction. Driving up the cost of finding vulns, rather than fixing and avoiding creating them, seems really unhealthy and ultimately harmful for the people who rely on the software that's vulnerable...
-
there will always be more vulnerabilities, for every ten you fix there's a thousand you don't, and somebody else looking for vulns is finding a different ten
-
That's certainly not the case for OpenSSH, even though it's written in C. Software where vulns are rare and effectively finite is possible. The problem is nobody wants to spend resources on doing that rather than on superlinearly ballooning features and bug-surface.
-
It might be nice for something less-examined than OpenSSH that runs on the command line.... if the chaff bugs were indistinguishable to automated analysis and not too expensive to inject.
-
The injection would be in the revision history (or the binary if just binary level) and therefore anyone looking to find/fix real bugs would just build with them removed.
-
I think this principle actually applies to proprietary binaryware too - a smart attacker will review not just the latest revision but do advanced analysis of change history, and could identify all the chaff relatively easily.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.