-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I got my reports for two of my packages (I'm upstream for both too).
The first problem is I couldn't find what version of the program they found the bug in. I also looked closely at one specific example and it didn't crash at all. Unless there was some underlying problem with a previous version of atoi() I cannot actually see what sending it what it got would do anything other than what I see (effectively "meh, you sent 0 Ill exit now"). - Craig On 2020-11-01 at 23:34, calumlikesapple...@gmail.com wrote: > On Sun, 2020-11-01 at 14:56 -0800, Russ Allbery wrote: > > Utkarsh Gupta <utka...@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 -----BEGIN PGP SIGNATURE----- Version: FlowCrypt Email Encryption 7.9.7 Comment: Seamlessly send and receive encrypted email wsFzBAEBCgAGBQJfo9SsACEJEAIhZsD/PITjFiEEXT3w9TizJ8CqeneiAiFm wP88hOP8Xg/+LJYPcP0kP57uYkeQBF9l3eHQOkdRSSWWo5trijUrcva88y8U kDjofUJUD2ok8PzHtBWgLe75zyjtBzyHdzTnjPRt7V2qXn8mlhw7mda2QJQK SRJ+4qoEcZdnHgkqcAxCzE9VFh/Q9vD08IqDxLB4gIkOrA6WCIEnXdjaQ86i N9cVST3obAWTYvgXlEdUv2m60aIxhYB0GEwxrM05ZqpZmx9K9uE2NFBNjVg0 S3aSS/9IBffLWv7wLJKaZc0xfSczB9y8S1dt/8CBOSDgxVtoI+b4cf4KiTuf oniXYGJBz/P8bS5NnzaeNCrsmfNK5ugUGu7XJvnxsgpy75kBXoZciBtaqiJF pvNYct2SLpbWyDF4+60ATFhhd6xdxCpv8eCgx8WpHvMenZ+vISCxSdVmvKna xYd9HFyu0AZCRD9taA+CUYVs6NNeDlxQL8IE6km5FJRwSXbDo0EY2s7SySrt HYEr4mFCSdHsdXTbvIRKHm0fUVmfKyVorvKPq9z3JR40HmdP9kCjtNRu2VYW nVBoWA7LoehKbH4KtFNbNmunqefQrI6KjsKiML73BJCrirn0ITK40onxOi2h Y5nG2hz6yYKD2ypSGWmcePcRxplhO/iQxHCI+2XEAQuoSGO0FHgP/pnn8L8m 6pkC/8fkJUDaXivNfr+zH4wJE6vTX54YMqw= =DoyM -----END PGP SIGNATURE-----
0x3938F96BDF50FEA5.asc
Description: application/pgp-keys
