Ages ago did p0f for passive OS fingerprinting. I guess it's just more entropy, more things that can change at runtime but they still can be included in the final model.
Conversation
I’d defer to and ... pretty much anyone who knows more about heap implementations than I do.
Opsec is too complex to make any categorical statements.
1
1
Agreed. From a JS-in-a-browser perspective, it'd be interesting to see how breaking monocultures of various low-level system components affects fingerprinting.
Does jemalloc produce different timings visible to JS than hardened_malloc? (Thinking out loud.)
1
1
Yes, definitely, see the thread I wrote at twitter.com/DanielMicay/st. Chromium uses the system allocator rather than TCMalloc on Android so Vanadium on GrapheneOS uses hardened_malloc. My assumption is that with JavaScript enabled it can be identified as Vanadium on GrapheneOS.
Quote Tweet
blog.jse.li/posts/chrome-7
This applies to many of the ongoing attempts at anti-fingerprinting across browsers. Performance testing can bypass many of the attempts at hiding information about the hardware and OS too. It can also be quite reliable. Talked about this a few days ago.
Show this thread
1
1
2
Chromium makes heavy usage of specialized allocators so someone would need to find something exposed to JavaScript that depends on the system allocator to measure it. There are other approaches though. In general, you cannot hide much about the hardware or the OS from JavaScript.
1
The Tor Browser's anti-fingerprinting can't hide much about the hardware and OS with JavaScript enabled. Users can also still be fingerprinted via things like keyboard / mouse input. They remove a lot of surface for fingerprinting but it's often unclear what is accomplished.
1
1
On a separate note, got to love the Mozilla employee in that thread not understanding the question and trying to imply that jemalloc isn't a massive security liability. Not sure why people attack a project without even reading the basic documentation like github.com/GrapheneOS/har.
1
1
They bring up partitioning and it's important to note their usage of jemalloc arenas as partitions has address space interspersed and reused between them. I see they have a project of trying to harden jemalloc by bolting on features and unfortunately that's not how this works.
2
1
You cannot sprinkle on canaries, zero-on-free, write after free checks, quarantines, etc. to an allocator like jemalloc and end up with a hardened allocator. The design is fundamentally exploitation friendly. I see this person is doing exactly that in Firefox from their tracker.
1
2
It seems that an application as complex as Firefox would already have memory management APIs such that different allocators could be used.
But that seems too logical. ;)
1
It's true that they have an extension to jemalloc for explicitly allocating certain things in a dedicated arena, but hardened_malloc also supports arenas and could support the same kind of extension. It would be far more meaningful since it actually uses isolated address space.
The hardened_malloc size class partitioning is within arenas and would still be there with an API for reserving and explicitly using arenas. Each size class region has a high entropy random base, so the arenas get that indirectly. Metadata is also entirely in a dedicated region.
1
The reason that I made it in the first place was to combine the secure fundamentals of the OpenBSD malloc design (out-of-line metadata, deterministic invalid free detection, etc.) with using modern large address spaces for strong size / type-based partitions, sparse heaps, etc.
1