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