I've published sample releases of AOSP 9 with the next generation hardened malloc implementation and some other changes at seamlessupdate.app. It's at the domain I registered for the Updater app for the time being since I don't have a name for the OS hardening project yet.
Conversation
What makes you motivated to implement the OpenBSD pattern over extending the default google/Linux one to counter memory corruption?, is the default implement ation that bad ? Can you give a real life exploit use case?
1
Replying to
If you're talking about the hardened memory allocator, the design is explained in github.com/AndroidHardeni including a list of the security properties it provides. A traditional allocator provides essentially zero of those security properties. It's not theoretical stuff either.
1
What is it that you're not understanding? I don't know what you mean by "implement the OpenBSD pattern" or "extending the default google/Linux one". The new allocator is not a port of OpenBSD malloc. The documentation explains that it's a successor to the previous port of it.
1
You cannot bolt on security to an allocator design like dlmalloc and end up with a truly hardened allocator. You end up with a weak design with a few security features like canaries and zero filling on free sprinkled on. It doesn't provide these important security properties.
1
The reason for not just porting and substantially extending OpenBSD malloc, which is an existing hardened allocator, is given in the documentation. A clean start was required to gain security, performance and soon scalability advantages from the abundant address space on 64-bit.
1
It's also explicitly aimed at hardening in production, rather than having a mixed purpose like OpenBSD malloc split between bug discovery and hardening. Solely focusing on exploit mitigation changes the approach to various aspects of the design, and that's covered in the README.
1
Heap corruption bugs are the most common vulnerabilities in this kind of software. Those are the real world examples of the bugs it mitigates. There are some simple examples in the public test suite github.com/AndroidHardeni but that demonstrates a tiny portion of what it provides.
1
I don't know what better documentation I can provide than the list of clear cut security properties. I'll be implementing a lot more tests including more complex cases that it's designed to detect or mitigate. It's to test that the security properties are provided as intended.
Non-hardened allocators fail to properly handle even the very simple test cases of heap corruption that are already there, but these test cases are only covering a tiny aspect of the security properties. I don't know what else you expect to see beyond the documentation I wrote.
1
The offset test also demonstrates one aspect of it: github.com/AndroidHardeni, i.e. the isolated regions for each size class with high entropy random bases. It's not feasible to make reasonable tests for a lot of things though. You have to read and understand documentation / code.
1
Show replies