Re:This shouldn't have happened: A vulnerability postmortem
by saurik on Thursday December 02, 2021 @12:06AM
(#29412738)
More strongly: the idea that "fuzzing" is "doing all the right things" is insane and disappointing of a narrative. The code snippets I am seeing here are ridiculous with manual, flag-based error handling? There is a use of something like memcpy that isn't hidden behind some range abstraction that manages all of the bounds?! This code probably is riddled with bugs, because they are doing all the wrong things, and fuzzing the result counts for nothing. C++ sucks, but it is way better than this.
[ Parent
| on HN ]
Re:This shouldn't have happened: A vulnerability postmortem
by ehsankia on Thursday December 02, 2021 @02:47AM
(#29413562)
I don't think anyone is under the illusion that "fuzzing is doing all the things" or that it is a replacement for actual unit, integration and E2E tests.
It still is true that fuzzing has managed to find a whole slew of bugs that were otherwise not found, and it is generally easier to automate and add without requiring a ton of engineer time. It is meant to be an addition on top, not a replacement for other techniques.
Re:This shouldn't have happened: A vulnerability postmortem
by lrem on Thursday December 02, 2021 @05:01AM
(#29414343)
"All the right things" included, according to the actual narrative in the post:
- Extensive non-fuzzing testing.
- Regular static analysis.
- Being actively maintained and overseen by a competent security team, with a bug bounty program on top.
I believe I've also seen mentions of independent security audits outside the post.
Edit: emphasis is on the fuzzing, because that is how the bug was finally discovered.