Re: Uninitialized variables and F37

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux