Overall, uninitialized data usually isn't zero, but it being zero is common enough that there are many cases where it's actually fairly reliably zero so that software somehow develops dependencies on it being zero. The dependency is often that there's one zero byte, not all zero.
Conversation
Even after the initial usage of the stack, a fair bit of it is only used for padding or unused space in buffers so it remains zeroed. There's also a lot of code zeroing structures / arrays. It's by far the most pervasive byte. Somehow, software manages to depend on it. *shrug*
1
1
For malloc, I think it must be rare to use the final bytes of certain size classes, so code using C strings manages to depend on having zeroed padding at the end. I feel like a lot of code is written by just fixing all the obvious problems that come up until it appears to work...
1
1
The problems we run into these days are with apps and drivers. Camera and Wi-Fi drivers are both really horrifying and it's not exclusive to a specific brand of them. Atheros and Broadcom both have some really horrifying, awful code and they love uninit data and use-after-free.
1
1
If there is little trust in that code (i.e. use-after-free, use-of-unintialized-variable are likely) why trust the remaining parts of the very same code - the logic most notably?
1
Who said anything about trusting the code? Taking networking as an example it doesn't matter if network drivers of the TCP/IP attack screw up their own security. What matters is that they don't screw up the security of the rest of the system such as giving an attacker RCE.
1
1
Networks are not trusted in the first place. It has nothing to do with trusting the code. RCE is a serious problem even for heavily sandboxed code. These vulnerabilities matter for code without any trust placed in it beyond running it. These are serious problems.
1
1
Software has bugs. The frequency of bugs can be reduced through testing, code review, auditing, static/dynamic analysis tools, etc. but there will still be bugs. Many of them. In a memory unsafe language, many of the common bug classes end up being code execution vulnerabilities.
1
1
Ideally the network stack and device drivers would be written in memory safe languages and implemented in userspace processes but they aren't, and that won't change overnight. Camera drivers are heavily sandboxed and difficult to attack so that's mostly an issue of compatibility.
1
2
Would be nice to have robust camera drivers but we have higher priorities. GrapheneOS-specific branch of hardened_malloc keeps a commit with workarounds rebased on master until we get all issues fixed: github.com/GrapheneOS/har. If we supported more devices we'd need more hacks...
1
1
For example, HiKey and HiKey 960 use the Mali GPU driver which has similar memory corruption bugs and we haven't worked around it like this so GrapheneOS has a black screen with them without disabling features.
linaro.org/blog/dragonboa will be much nicer anyway: upstream drivers.
Qualcomm has actually spent years working towards using upstream kernel drivers with open source userspace libraries for many components but the work usually lands way to late for devices to actually ship with it. Hopefully this starts to change and it becomes the default stack.
1
2
Not so much because we expect the quality to actually be higher but because we don't want to deal with closed source libraries where we can't apply compiler hardening and can't cleanly fix the bugs we find ourselves. It'd too much work to switch to these open ones so late though.
2