Added: https://github.com/openssh/openssh-portable/commit/b744914fcb76d70761f1b667de95841b3fc80a56
1 Like
1 Like
Now in Whonix developers repository.
1 Like
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
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