I think using custom mallocs are slightly above the complexity that PG audience is used to. Its better to use systems that have it pre-built like secureblue and formerly kicksecure (they deprecated it now). Ultimately projects that wish to use the hardened malloc well will have to build it into the libc itself instead of using preload according to Micay (creator of hardened malloc), and its a medium priority goal for secureblue.
Divest’s brace is also a good option as @SkewedZeppelin pointed out.
I dunno much about mallocs though, so its all borrowed opinions from my end
Everything firefox-based (tor browser, thunderbird, etc) does not work with hardened_malloc. They’ll crash immediately with it loaded. FWIW I also found firefox unstable with scudo. Thunderbird seemed fine with scudo however IIRC.
Integrating it into the libc would have much better results, many apps have issues with manually replacing malloc using LD_PRELOAD.
Not sure if using patchelf to inject the library would help but probably wouldn’t.
Brace doesn’t include hardened_malloc, it is mostly just configuration files. Instead, you would have to install the divested-release repo and install Brace + hardened_malloc from there.
I’m going to say a similar thing to what I said about Electron and wlroots, which is that if we are going to proactively recommend this then I want to see proof that using a hardened memory allocator could have prevented a real-world exploit for somebody in the past.
Unlike with those two cases though, I think there might actually be evidence out there that using an alternative memory allocator could have some use in real-world scenarios, so I’m interested to see what stories/evidence you come up with.
You don’t implement security checks after getting exploited; let’s say I create my own OS, with no any security measures. My OS technically didn’t get any malware or exploited yet; does that make it any secure? Did I know that I didn’t make any effort into securing it? Yes.
Also, why bother with creating post-quantum cryptography algorithms when there have been no any evidence of real-world attack that breaks current good encryption algorithms used worldwide?
If an intruder enters your house, do you leave all your secrets in the open? Don’t you put it into account and hide anything precious/important to you?
Security is a hoax, right?
When in doubt, add to knowledge base or write a blog post.
There’s a clear difference between brand new software, and operating systems that are currently in use by millions of people every day and have been for decades…
This is the only reason hardened allocators exist? I’m not familiar with Graphene’s impl, but Scudo specifically was built to mitigate memory-related (mostly the heap) attacks/corruption (data-race, buffer overflow, double-free, deterministic addressing, use-after-free, to point out some (mirror)). It is used in Android and Chrome.
For instance, the Call Of Duty game has had a memory corruption bug, uncovered by GrapheneOS hardened_malloc. The bug could potentially have some adverse side effects, but it’s a proprietary video game, so we might not know for sure. But if a more severe issue were to exist, it will be certainly blocked, at least by this allocator.
Jonah, you already recommend that users take numerous steps that in theory should be “on the distribution/developer” to implement/enable by default and that have very minor privacy/security improvements, like switching to ZRAM (swapfile is perfectly fine if the drive is encrypted).
IMO making the Linux desktop section more comprehensive in PG can only help users, because in terms of security no distribution is good out of the box except for maybe Secureblue but it comes with usability drawbacks.
In my opinion around half of what is written here and here should make it to the knowledge base and be more frequently updated, with extra attention to the sandboxing portion because it is the biggest problem.
