We turned on pattern initialization so that we will actually find the bugs, but zero initialization would have probably have been less stressful on a personal level.
Conversation
Pattern is nice because of you see it in a crash log then you kinda have a smoking gun.
2
2
Pattern initialization is great for debug builds. We've encountered multiple real world bugs in the Android Open Source Project and device support code where non-zero turns an inert bug into a potentially exploitable vulnerability. It's often not caught by running test suites.
2
2
8
Got any patches or bug reports for me? I work on AOSP, and while we did fix everything we found in aosp/master, perhaps there's still more lurking.
1
We've historically reported a bunch of these bugs to Google and Qualcomm, often through other developers because we lacked the time to follow up on each of our discoveries. I've also submitted patches to various projects myself when I had time. Most of these are already fixed.
1
1
I don't have any backlog of issues uncovered by the compiler-based filling on initialization. However, there are still a bunch of issues uncovered by either pattern filling on allocation or pattern filling on free with malloc. Most of these are in Qualcomm's proprietary code.
2
1
Thanks for the heads-up. There is some investigation coming for automatic heap initialization (probably zero-based for that) for Android. I'll let the folks doing that work know about this so that they'll be ready to see some fireworks.
1
In GrapheneOS, we use github.com/GrapheneOS/har as malloc. Small (slab) allocations have zero-on-free and verification that data is zeroed on allocation along with quarantines to delay reuse. Large allocations are replaced with fresh PROT_NONE mappings on free and quarantined.
1
1
Over the years, this has caught a lot of bugs. In the past, we used to use non-zero pattern initialization, but we found that uncovered too many bugs and it proved to be far more risky. We have even hit cases where heap canaries uncovered scary bugs and we had to change those.
1
1
We used to use fully random heap canaries. We encountered a scary set of bugs in the Android media frameworks where canaries would fill all of the padding from size class rounding in the allocation for a C string, and the code relied on that padding to provide the NUL terminator.
1
1
3
These days, we zero the leading byte of canaries to make them a solid mitigation against C string heap overflows rather than potentially making those vulnerabilities easier to exploit:
github.com/GrapheneOS/har
github.com/GrapheneOS/pla does the same for stack canaries on 64-bit.
