I wanted to create a thread discussing the potential for a global replacement of the default glibc malloc() implementation with a more secure implementation, liked hardened_malloc or mimalloc. It would be another shining example of our commitment to try ideas before other Linux distributions, and it would benefit the security of the project, as security should be the main focus of such an important piece of the operating system. This idea can’t be tried immediately due to a glycin issue with RLIMIT_AS for hardened_malloc, which is causing issues for GTK.
Feel free to constructively discuss the ideas merits and shortcomings, and come to your own conclusion. Cheers.
Please propose this to the glibc project, on the libc-alpha mailing list: Libc-alpha Info Page
Usually, the concerns about glibc malloc are not about security, but use of too much RAM (or at least, high reported RSS numbers).
From a security perspective, one potential outcome is that future exploits will just target the new malloc’s data structures, and the practical gains will be limited.
I agree that this will just cause hardened_malloc’s data structures to be the target of potential new exploits, although I believe that it will be harder to get a functioning exploit in because of it’s strictness regarding memory leaks, which has been significantly battle-tested. This doesn’t mean that glibc isn’t, as glibc has seen a lot more battle-testing, especially by enterprises which demand a lot more security. I want to get a few more opinions though since there is a Fedora-derived project already using hardened_malloc called secureblue. They will likely have better insight than myself.
Purely as a user who is aware of hardened malloc, I would be interested in seeing this happen, but I don’t know what downsides or tradeoffs would come with implementing this. I am aware that Secureblue does this.
The downsides at the moment are not obvious for me either outside of one issue regarding GTK applications misbehaving in KDE Plasma, due to a bug in glycin which currently has a fix waiting to be merged. There is also a library which fixes this behaviour used by secureblue in the mean time. As far as I can judge, I have had no other issues using hardened_malloc globally in Fedora, and we would likely only benefit from migrating to it.
