Hi Steve, On Fri, 2022-01-21 at 13:04 -0500, Steve Grubb wrote: > This is a continuation of the discussion from F36 Change: GNU > Toolchain Update. > > Uninitialized variables are a big problem. They can be sources of information > exposure if parts of a buffer are not initialized. They can also cause > unexpected execution paths if the attacker can groom the memory to a value of > their choosing. If the variable is a pointer to heap, this can cause free to > corrupt memory under certain circumstances. If the uninitialized memory is > part of user input, this can lead to improper input validation. This is not > hypothetical. All of these come from a paper doing an emprical study of > android flaws. [1] The data used in the paper is here. [2] > > Part of the problem is that compilers and static analysis tools can't always > find them. I created a test program that has 8 uses of unintialized > variables. > Gcc 11 misses all of them. Gcc 12 finds 2. Clang 13 finds 1. cppcheck finds 2 > or > 3 - but does so much complaining you'd think it found all. Valgrind finds 2. > Flexelint, a commercial linter, finds 1. > > Since tools can't always find them, the only option we have right now is > force > initialization to something the attacker cannot control.
Although I see how having a deterministic bug (use of know bad zero value) is better than having an undeterministic bug (use of undefined value), it is still a bug. And I think you don't give the tools we have much credit. In my experience almost all such bugs will be found with a combination of gcc -fsanitize=undefined and valgrind memcheck. Your test program didn't trigger most because gcc, when optimizing, is smart enough to simply not emit unused code. Of course gcc -fsanitize=undefined cannot be used on production code. And while valgrind memcheck can be used on production code, it is often fairly slow (and arguably now it is too late, because already in production). Although I am not against trying to turn nondeterministic bugs into deterministic ones and getting rid off more undefined code, I am slightly worried it means those bugs will be harder to find in production. Also I really hope we do also encourage people to use the various tools to find those bugs before they get into production. They really aren't as bad at finding these issues as you make them out to be. Cheers, Mark _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
