Overflow checking in hardened_malloc

Privacy Project Showcase
1

I’ve been working on adding buffer overflow checking to common block operation functions in hardened_malloc the past few days.

It is stable in my testing but more real world testing would be nice.
In the past I’d ask this in one of my chat rooms, but I closed those months ago.

You can either patch and compile it yourself or use my Fedora prebuilts (Arch is available if you compile yourself):

12 Likes
2

What is the goal with this one? What this would be used for?

3

To mitigate some buffer overflows.
Microsoft had some numbers when they made it:

We did some analysis of the Microsoft Security Response Center data to look at the out-of-bounds heap corruption, and found a common culprit: memcpy. Of the OOB writes that were categorised as leading to remote code execution (RCE), 1/3 of them had a block copy operation like memcpy as the initial source of corruption. This makes any mitigation to memcpy extremely high-value.

MTE can mitigate them already but not all devices have it, especially x86 which is my usecase. The slab canaries can maybe detect it but only after corrupted. This can catch them before they happen.
This isn’t something that’d be shipped in GrapheneOS, because that is better done integrated directly into bionic.

3 Likes
4

@RoyalOughtness thoughts on making this available (for testing) in Secureblue?

3 Likes
5

To generate a secureblue test build for this, it should be as simple as forking secureblue and replacing this line with your repo’s link:

Once you have that built you can just paste in a ghcr link that folks can rebase their VMs to to test. Something like:

rpm-ostree rebase ostree-unverified-registry://ghcr.io/SkewedZeppelin/silverblue-main-hardened:sometag

1 Like