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.
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.
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.
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.
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.