hardened-malloc is now available from Whonix testers repository. Will move to stable-proposed-updates and stable repository over time.
It installs its file to
hardened-malloc will be installed by default in Whonix but not used by default for anything in Whonix (yet) since installation by default simplifies things but does not break things.
Moved to its own homepage.
And available from all Whonix repositories.
Notified upstream about the fork.
From Tom’s reply I understand that the attacker needs to be in a privileged position on your system to fingerprint the allocator, one similar to fingerprinting the CPU and RAM behavior. An attacker with that much power can do much more damage than merely fingerprint. This doesn’t apply to run of he mill websites anyone visits.
Fingerprint non issues aside, switching up allocators is non-trivial and requires changes to the browser code base to take full advantages of its defenses. Slapping LDPRELOAD as a prefix is not enough. The allocator used in TBB has achieved defense parity with hardened_malloc so the effort needed is not justified.
I now want to focus on firejail/apparmor consequences and having a sustainable maintenance plan with upstream.
I didn’t reach the same conclusion.
Fingerprinting: It is most likely possible to be creative enough to fingerprint what memory allocator is used.
Does not state what local exploitation is a prerequisite. If this matters, please quote the passages which lead to the conclusion and/or ask him to clarify this very point.
LD_PRELOAD=’/path/to/libhardened_malloc.so’ /path/to/program will do
nothing or approximately nothing.
Reason enough to disable hardened malloc for Tor Browser when using
tb_hardening=true. Will work on that.
harden_malloc definitely has more bells and whistles than mozjemalloc.
But the benefit gained by slapping in an LD_PRELOAD and calling it a
day is small to zero. Probably negative because you’ll not utilize
partitions by default.
More reason to do so.
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.
It looks like what Tom said was a bunch of misinformation and a subtle attack on Daniel’s work.
Daniel Micay responded https://lists.torproject.org/pipermail/tor-dev/2019-August/013990.html
It seems like the only true thing Tom said was that the allocator can’t be changed by a simple LD_PRELOAD change.
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
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 https://trac.torproject.org/projects/tor/ticket/31440 for it.
Speak: compile time option / require recompilation / build compiled by someone other than upstream?