Get DieHarder working with Tor Browser
The DieHarder memory allocator looks like a possible hardening measure for Tor Browser. We should try to get it working, and evaluate it for performance, effectiveness and suitability.
Activity
Here's my WIP patch that bundles DieHarder with Tor Browser. Unfortunately that version of DieHarder crashes with Tor Browser and the current version of Firefox after about 30 seconds of use. The crash appears in random places in the Firefox code. So I think DieHarder probably needs an update before it will work. I have been corresponding with the DieHarder author to try to solve this issue.
https://github.com/arthuredelstein/tor-browser-bundle/tree/10281_dieharder (review not needed)
How does this compare with PartitionAlloc (Chromium's malloc) or hardened PartitionAlloc in terms of security? I mean DieHarder seems pretty experimental, whereas PartitionAlloc is designed specifically for a browser and is actively developed and constantly fuzzed by hundreds of machines. Is there an actual argument for using this over using Chromium's malloc?
The DieHarder author, Emery Berger, kindly patched DieHarder to fix the crashes I reported in comment:1. So here is a new version of the patch that uses the updated DieHarder:
https://github.com/arthuredelstein/tor-browser-bundle/commit/20957+1
The question in comment:3 is a good one. From my reading, DieHarder looks like it has stronger protections that PartitionAlloc, but I could be wrong about this and I need to study both more to make a coherent argument.
In the meantime I would be interested to hear from anyone who wants to try this patch out. It might be of interest to deploy DieHarder in one of our alpha releases as well.
A few comments:
Are you sure this is using DieHarder as the regular allocator? It's my understanding that FF will use mozjemalloc (or jemalloc4) as the allocator, and would use the system allocator to allocate space for the jemalloc allocator. Which means DieHarder would be allocating memory for jemalloc which would be doing all the individual allocations. I think.
I'll (try to) compare DieHard to PartitionAlloc/Copperhead: https://trac.torproject.org/projects/tor/ticket/10281#comment:49
Some of the features I see in DieHard (I don't think this is exhaustive):
- randomized freelist selection
- randomized allocation placement (to some degree I assume)
- random bytes written on free
I don't believe they have any partitioning support. In general, it seems DieHarder is somewhat comparable to Coppherhead's allocator. It may have or lack a few small features that the other has. The lack of partitioning is the main strike against it.
Hi all - DieHard/DieHarder author here.
Arthur pointed this ticket out to me, so I figured I would add some explanations. I'd be happy to discuss any technical details at further length.
DieHarder is quite different from DieHard. In particular, DieHarder "partitions" memory at a fine grain: every same-sized object is on a separately mapped page. Since these are randomly allocated in virtual address space, all nearby pages are virtually certain to be unmapped. Unlike PartitionAlloc, DIeHarder prevents double frees and invalid frees (since it does not use free lists), and provides higher entropy: all allocations are entirely random, both within and across pages. Differently sized objects (currently rounded up to the next power of two) are always stored separately. It would be trivial to extend it to separate objects by type; the current system provides most of this partitioning "for free".
The DieHarder paper from ACM CCS 2010 features a detailed analysis of its architecture and its security guarantees: see https://people.cs.umass.edu/~emery/pubs/ccs03-novark.pdf.
When we conducted our studies - and when Arthur tested the patch - I replaced jemalloc with DieHarder. The security guarantees it provides when it handles individual object allocations are much greater than when used to back a custom allocator. For example, it would prevent the exploits recently described by the group from VU Amsterdam: https://www.theregister.co.uk/2017/02/14/aslr_busting_javascript_hack/
Trac:
Username: emeryberger
Replying to emeryberger:
When we conducted our studies - and when Arthur tested the patch - I replaced jemalloc with DieHarder.
Did you do that like Arthur did? And if so, shouldn't you use
ac_add_options --enable-replace-mallocin your .mozconfig to have it working properly (see: https://glandium.org/blog/?p=2848 and just to echo tom's concern)?Arthur: apart from that this patch needs revision. For one: my shell is complaining about
//. Secondly, I think the bundle step is not the right one to build the library in. I think we should move that togitian-utils.yml. Thirdly, one thing to test occurred to me: in the past we had issues with exporting an env variable in our start script and our automatic updates (see: #13359 (moved)). We should make sure theLD_PRELOADapproach is still working in this scenario.Trac:
Status: new to needs_revisionReplying to tom:
I'll (try to) compare DieHard to PartitionAlloc/Copperhead: https://trac.torproject.org/projects/tor/ticket/10281#comment:49
Some of the features I see in DieHard (I don't think this is exhaustive):
- randomized freelist selection
- randomized allocation placement (to some degree I assume)
- random bytes written on free
I don't believe they have any partitioning support. In general, it seems DieHarder is somewhat comparable to Coppherhead's allocator. It may have or lack a few small features that the other has. The lack of partitioning is the main strike against it.
Perhaps someone should consult strcat (the Copperhead developer) on this subject. I have a feeling that he will be able to point out downfalls in the DieHarder approach, as well as the future plans for the Copperhead allocator (which is an improved hybrid between bionic's malloc and OpenBSD's malloc). I believe strcat will be the best person to ask, as he is very familiar with memory allocators (e.g. he's planning on upstreaming a hardened slab allocator to Linux), and he's often very willing to talk.
Memory allocator hardening is a tricky issue, subject to a lot of subtle nuances.
FWIW, here are some short instructions for testing DieHarder with Firefox: https://gist.github.com/arthuredelstein/a00899ad13fe7174a667ed9a39e3f1cf
