[tor-dev] TBB Memory Allocator choice fingerprint implications

[Daniel Micay]

On Sat, Aug 17, 2019 at 09:17:40PM +0000, Tom Ritter wrote:
> On Sat, 17 Aug 2019 at 15:06, procmem at riseup.net <procmem at riseup.net> wrote:
> > Question for the Tor Browser experts. Do you know if it is possible to
> > remotely fingerprint the browser based on the memory allocator it is
> > using? (via JS or content rendering)
> 
> Fingerprint what aspect of the browser/machine?

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. The strength
of fingerprinting mitigations when JavaScript is enabled are extremely
overestimated / overvalued and in many cases don't actually hide the
information that they attempt to hide due to secondary ways of obtaining
it like careful performance measurements.

> > We are thinking of switching Tor Browser to use the minimalist and
> > security oriented hardened_malloc written by Daniel Micay. Thanks.
> 
> I wouldn't advise giving up partitioning for.... what exactly? What
> features does this allocator have that 68's jemalloc doesn't?

The hardened_malloc allocator heavily uses partitioning, and has a much
stronger implementation than the very weak approach in mozjemalloc. It
statically reserves memory regions for metadata and a dedicated region
for each arena, with each size class receiving a dedicated sub-region
within the arena. These sub-regions are placed within their own guard
region and each have a high entropy random base. It never mixes address
space between these regions or reuses the address space. This is much
different than what you call 'partitioning' in mozjemalloc which does
not really qualify. What you're talking about is mozjemalloc exposing an
API for choosing the arena from the code, which can certainly be done
with hardened_malloc too. However, in mozjemalloc, the address space for
different arenas is mixed together and reused between them. It's really
a stretch to call this partitioning, and it doesn't have the baseline
separation of size classes either.

People can read about hardened_malloc in the README:

https://github.com/GrapheneOS/hardened_malloc/blob/master/README.md#hardened-malloc

I don't know why you're making the misleading claim that people would
need to give up partitioning. It's also really a stretch to call what
Mozilla is doing in mozjemalloc partitioning in the first place, so your
claim is really quite backwards...