On Sun, 2020-11-01 at 14:56 -0800, Russ Allbery wrote: > Utkarsh Gupta <utkarsh@debian.org> writes: > > > That said, it'd be a bit weird if they don't report these issues and ask > > for a CVE assignment against these. Anyway, the security team might > > know more about this. > > It appears to be the output of automated fuzz testing, which based on past > experience means that a large percentage of the crashes are probably not > exploitable. Oh, it's definitely the result of automated fuzzing. Their entire website is about using automated fuzzers to find code defects. Plus, I don't think any sane person would spend their time concocting test cases for crashes in 0xffff (a nokia firmware writer) without bothering to report the bugs they found in binutils (a somewhat more common package). Further, I would argue that many of the crashes might not be just unexploitable, but appropriate. If given highly unusual and bizarre input, crashing with SIGABRT might be the most sane response. > The raw data is not hugely useful in aggregate unless you enjoy fixing > edge-case buffer management bugs that no one is likely to care about (such > as in options parsing code). It can be made useful by tracking down where > the crash happens and then figuring out if that's part of an attack > surface, but that's quite a bit of work which they're clearly not > volunteering to do. That being said, I do think we should at least take a look. A ton of security bugs are just buffer overflows, and it has been shown that even tiny bugs can lead to remote code execution. I recently read googleprojectzero.blogspot.com/2014/08/the-poisoned-nul-byte-2014-edition.html which goes from writing a single null byte past the end of a linked list to full privileges, despite security features like ASLR. Even if none of their test cases can be used to exploit modern packages, we'd at least know. I agree with Daniel Leidert that Debian should take charge of this, rather than expecting each of the package maintainers to individually request the CITL data and test it. Perhaps QA could get the master copy, devise a script to find the unfixed test cases, and notify package maintainers. Thanks for taking the time to read my wall of words, Calum M
Attachment:
signature.asc
Description: This is a digitally signed message part