Hardened Malloc - Hardened Memory Allocator

VirtualBox bug report: VirtualBox crashes with hardened memory allocator Hardened Malloc on the host

1 Like

Added: Add test against Graphene hardened malloc. · openssh/openssh-portable@b744914 · GitHub

1 Like
1 Like

Now in Whonix developers repository.

1 Like

https://gitlab.com/whonix/helper-scripts/-/blob/master/usr/bin/hardened-malloc-enabled-test

https://gitlab.com/whonix/helper-scripts/-/blob/master/usr/bin/hardened-malloc-type-test

https://gitlab.com/whonix/systemcheck/-/blob/master/usr/lib/systemcheck/check_hardened_malloc.bsh

Wondering if hardend malloc can be combined with flatpak.


On the host:

cat /proc/$$/maps | grep malloc

[…] /usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so


Run a shell for debugging purposes inside flatpak.

flatpak run --command=bash org.chromium.Chromium

See if hardend malloc Kcksecure is loaded.

cat /proc/$$/maps | grep malloc

No, it’s not.


Trying to ld preload hardened malloc Kicksecure using environment variable inside flatpak.

flatpak run --env=LD_PRELOAD=/usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so org.chromium.Chromium

ERROR: ld.so: object ‘/usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so’ from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.


Any ideas?

Not sure that makes sense for Chromium. Which allocator is more secure, Chromium’s built-in or Hardened Malloc (Kicksecure)?

But even if it doesn’t make sense for Chromium, would be useful to know generally for other applications from flatpak.

The file /usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so is likely not available from within the Flatpak sandbox.

hardened_malloc is more secure but you can’t just switch allocators with LD_PRELOAD since Chromium uses PartitionAlloc internally anyway, similar to Firefox with mozjemalloc.

1 Like

telegram desktop failing with Hardened Malloc Kicksecure (on Qubes Debian template):

fatal allocator error: invalid free

1 Like

I can’t reproduce this. At exactly which point does this happen? Immediately upon start of the app or when doing something (e.g. logging in, clicking on a chat, etc.)?

1 Like

Actually, when preloading hardened_malloc with Telegram on my host, I got a different error:

fatal allocator error: sized deallocation mismatch (large)

Edit: using a newer hardened_malloc seems to have fixed that.

1 Like

Yes. I do not see any GUI. Instantly outputs that in the terminal.

1 Like
1 Like

This was fixed upstream.

I git cherry-picked the commit and uploaded to Whonix developers repository.

chromium feature request: consider using hardened malloc
https://bugs.chromium.org/p/chromium/issues/detail?id=1204783

I don’t think Chromium will seriously consider using it. Maybe they can take some ideas from it though.

1 Like

Yes, I give that a less than 5% chance. But I suggested it for sake of completeness.

1 Like

grep alone is sufficient. No need for a pipe.

1 Like

Are these all the current blockers for enabling this globally?

  • cryptsetup slowing down due to a kernel bug.
  • Chromium dying due to a bug in the Debian patches.
  • Telegram dying due to an invalid free.
  • OpenSSH dying due to seccomp.

I can’t seem to reproduce the last two though. Can you verify that they’re still broken now?

1 Like