Hardened Malloc - Hardened Memory Allocator

Development
142

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

1 Like
143
1 Like
144

Now in Whonix developers repository.

1 Like
145
146

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

147

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.

148

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
149

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

fatal allocator error: invalid free

1 Like
150

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
151

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
152

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

1 Like
153
1 Like
154
155

This was fixed upstream.

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

156

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

157

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

1 Like
158

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

1 Like
159

grep alone is sufficient. No need for a pipe.

1 Like
160

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
161

I’ve discussed with Daniel and some others about how to workaround these.

We can patch hardened_malloc and build in a different malloc implementation (e.g. musl’s) that will be used as a fallback for specific apps. Or, we can change the file permissions of /etc/ld.so.preload so that an application cannot read it (and we don’t need to use bwrap). We can use ACLs for this:

addgroup --system disable-hardened-malloc
setfacl -m g:disable-hardened-malloc:- /etc/ld.so.preload
sudo -g disable-hardened-malloc cat /proc/self/maps
sudo -g disable-hardened-malloc chromium

To enable this by default, we could do something similar to hide-hardware-info and change the executable’s group and make it setgid. However, for some reason, Chromium errors out:

Running as root without --no-sandbox is not supported. See https://crbug.com/638180.

even though it’s not actually running as root. cryptsetup at boot also wouldn’t work with this since it runs as root and can bypass ACLs anyway.

Daniel also pointed out another glaring security issue in the Debian package that I’ll add to the wiki (it’s not a production build of Chromium so sandboxing, ASLR, etc. are crippled).

2 Likes