Hardened Malloc - Hardened Memory Allocator

The torbrowser script Whonix uses to start TBB does more than just start TBB. Using hardened_malloc for the whole script may give a minimal security advantage.

I’d love to see Daniel Micay’s opinion on this too.

1 Like

It looks like what Tom said was a bunch of misinformation and a subtle attack on Daniel’s work.

Daniel Micay responded [tor-dev] TBB Memory Allocator choice fingerprint implications

It seems like the only true thing Tom said was that the allocator can’t be changed by a simple LD_PRELOAD change.

1 Like

I stand corrected. Based on new information in I conclude hardened_malloc is superior in security standpoint in every way over jemalloc (the latter is general purpose). I want to enable it by default for KVM builds, fingerprinting aside. There comes a point where security trumps fingerprinting worries.

What we need to figure out is the best way to integrate it into TBB. Daniel IIRC said that disabling jemalloc is the right way to go over using LD-PRELOAD ?

I am curious how functional Whonix would be if we switch to OpenBSD’s allocator for the rest or the system (seeing that it is widely tested against a large package selection by a OS already). Then we can enable hardened-malloc for security sensitive daemons whenever possible.

I think the misunderstanding was caused by an imprecise use of language.

That would be the first time we make changes to Tor Browser which are not related to integration into a Linux distribution (Whonix). Until now, no changes affected fingerprinting of default installation vs Tor Browser on Debian. Only environment variables were changed and add Tor Browser first startup popup to ask whether security slider should be set to safest drops (opt-in) a user.js file.

The higher Whonix’s popularity, the less fingerprinting arguments would make sense. If most Tor users were Whonix users, then Whonix could take the lead in fingerprint. For now, we’d stand out.

Already created consider using Hardened Malloc for better security in TBB (#31440) · Issues · Legacy / Trac · GitLab for it.

--disable-jmalloc
Speak: compile time option / require recompilation / build compiled by someone other than upstream?

1 Like

Yes.

I’m not sure how stable a memory allocator designed for BSD would be on Linux.

Daniel Micay doesn’t see it as much of a problem as much more important information such as hardware details can be gotten via performance fingerprinting which TBB doensn’t fully protect against.

[tor-dev] TBB Memory Allocator choice fingerprint implications :

Performance-based fingerprinting of the browser can easily differentiate between using a different malloc implementation. That can already obtain a lot of fingerprinting information about the hardware and OS so this may not actually matter much, but it’s entirely possible.

Although, performance fingerprinting will probably not affect VMs as much as long as most Whonix users allocate the same amount of RAM and CPUs to the VM.

With the way that mailing list went, I don’t think they’d be too eager to implement it.

2 Likes
1 Like

If we use hardened_malloc along with AppArmor or Firejail would we need to allow access to /usr/lib/libhardened_malloc.so in the AppArmor/Firejail profile?

Can someone test if it’s needed or not?

1 Like

I wonder if this is even possible due to the recent kernel hardening. Many of the things done for kernel hardening have a performance decrease and may obfuscate the results of any performance fingerprinting.

1 Like

At this point unless outside code contrbutors add this TBB it won’t happen. The ML discussion concludes that the added benefit of it for modern exploit techniques is negligible.

1 Like

Upstream recently released version 2.
Merged into GitHub - Kicksecure/hardened_malloc: Hardened Memory Allocator for many Applications to increase Security. Debian packaging fork only. Fork Homepage: https://www.whonix.org/wiki/Hardened_Malloc Upstream original: https://github.com/GrapheneOS/hardened_malloc and into all Whonix repositories except Whonix stable repository.

1 Like

I just tested it and yes it does.

Although, the majority of profiles allow access to /usr/lib which means we don’t have to do anything,

1 Like

Good candidate for upcoming

/etc/apparmor.d/abstractions/base.d

References:

2 Likes

The base abstraction allows access to all of /usr/lib already so I don’t see why it’d be needed for hardened_malloc.

1 Like

I’m testing hardened_malloc globally and there doesn’t actually seem to be much breakage. It might be ok to enable it globally by default on Whonix.

The only thing that seems to be breaking is the Tor Browser for some reason. I’ve narrowed down the issue to .tb/tor-browser/Browser/firefox (not Whonix’s torbrowser script).

This is weird since firefox uses it’s own malloc, mozjemalloc.

2 Likes

Last time I tested it, it broke X Window System. (No GUI come up.)

Done.
RFP: hardened-malloc – hardened memory allocator

Is it worth it? Due to…

This is too early. We shouldn’t be the “only” ones using hardened malloc. Would be much better if some people using Debian testing and/or Debian sid used hardened malloc. So bugs (applications refusing to start) are spotted by others than Whonix people and reported upstream. Whonix cannot be the only ones using it, bumping into issues, working on integration by being the “only” users. “The world doesn’t know about hardened malloc.”

There are zero discussions on debian.org about hardened malloc. “google” search term:

site:debian.org "hardened malloc"

Mozilla.

site:mozilla.org hardened malloc

glibc

site:https://gnu.org hardened malloc

glibc issue tracker:

https://sourceware.org hardened malloc
2 Likes

glibc feature request - consider using Hardened Malloc

2 Likes

debian glibc feature request - consider using hardened malloc (hardened memory allocator)

1 Like

Packaging related enhancements:
Comparing 0.6-1...2.0.1-1 · Kicksecure/hardened_malloc · GitHub

  • no longer depend on genmkfile, can be build using dpkg-buildpackage -b or other standard Debian package build tools
    • therefore reset to upstream original Makefile
  • use version number by upstream 2.0
    • the last ocetot 2.0.1, 2.0.2, 2.0.3, 2.0.15 is for packaging changes.
    • the first part 2.0 will only change as upstream releases new releases
2 Likes