Conversation

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.

Replying to

To better understand your efforts I would like to know the following:

Replying to

and

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?

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.

github.com

hardened_malloc/README.md at main · GrapheneOS/hardened_malloc

Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-base...

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

9:37 PM · Dec 22, 2018Twitter Web Client

Replying to

and

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.

Replying to

and

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.

Show replies