Opened 2 years ago

Last modified 18 months ago

#20957 needs_revision defect

Get DieHarder working with Tor Browser

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-security
Cc: gk, mcs, tom Actual Points:
Parent ID: #20955 Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (13)

comment:1 Changed 2 years ago by arthuredelstein

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)

comment:2 Changed 2 years ago by gk

Cc: gk added
Keywords: tbb-hardened added

comment:3 Changed 2 years ago by cypherpunks

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?

comment:4 Changed 2 years ago by mcs

Cc: mcs added

comment:5 Changed 2 years ago by tom

Cc: tom added

comment:6 Changed 2 years ago by arthuredelstein

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.

Last edited 2 years ago by arthuredelstein (previous) (diff)

comment:7 Changed 2 years ago by tom

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.

comment:8 Changed 2 years ago by emeryberger

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/

comment:9 in reply to:  8 Changed 2 years ago by gk

Status: newneeds_revision

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-malloc in 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 to gitian-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). We should make sure the LD_PRELOAD approach is still working in this scenario.

comment:10 in reply to:  7 Changed 21 months ago by cypherpunks

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

comment:11 Changed 20 months ago by arthuredelstein

FWIW, here are some short instructions for testing DieHarder with Firefox:
https://gist.github.com/arthuredelstein/a00899ad13fe7174a667ed9a39e3f1cf

comment:12 Changed 18 months ago by gk

Keywords: tbb-hardened removed

Remove tbb-hardened keyword.

comment:13 Changed 18 months ago by gk

Keywords: tbb-security added
Note: See TracTickets for help on using tickets.