Hello, 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. Kees Cook started a discussion on the llvm developers mail list a while back. He makes a very clear argument. I would be repeating his points, so please read the original discussion here (also read the replies): https://lists.llvm.org/pipermail/cfe-dev/2020-April/065221.html He talks about -ftrivial-auto-var-init=zero being used for production builds and -ftrivial-auto-var-init=<pattern> being used for debug builds. The use is not just the kernel. Consider a server that returns data across the network to a client. It could possibly leak crypto keys or passwords if the returned data structure has uninitialized memory. For more background, the creator of this technology for LLVM presented a talk about this feature at a past LLVM developer conference: https://www.youtube.com/watch?v=I-XUHPimq3o He said this would have prevented over 900 fixed CVE's in Chrome and 12% of all Android CVE's. >From deep inside the LLVM thread above, comes this nugget: --- To add in, we (Microsoft) currently use zero initialization technology in Visual Studio in a large amount of production code we ship to customers (all kernel components, a number of user-mode components). This code is both C and C++. We already have had multiple vulnerabilities killed because we shipped this technology in production. We received bug reports with repros that worked on older versions of Windows without the mitigation and new versions of Windows that do have it. The new versions don't repro, the old ones do. --- Microsoft is also digging in to uninitialized variables. They have a lengthy blog post that talks about extending this to heap memory. [3] I think this would be an important step forward to turn this on across all compilations. We could wipe out an entire class of bugs in one fell swoop. But then, what about heap allocations? Calloc has existed for a long time. It might be worthwhile to have a CFLAG that can tell glibc (or other allocators) to substitute something like calloc for malloc. Cheers, -Steve [1] - https://picture.iczhiku.com/resource/paper/shkeTWJEaFUuWCMc.pdf [2] - http://ml-papers.gitlab.io/android.vulnerabilities-2017/appendix/ MSR2017/vulnerabilitiesList.html [3] - https://msrc-blog.microsoft.com/2020/07/02/solving-uninitialized-kernel-pool-memory-on-windows/ _______________________________________________ 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
