[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #20957 [Applications/Tor Browser]: Get DieHarder working with Tor Browser

#20957: Get DieHarder working with Tor Browser
--------------------------------------+--------------------------
 Reporter:  arthuredelstein           |          Owner:  tbb-team
     Type:  defect                    |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-hardened              |  Actual Points:
Parent ID:  #20955                    |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (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/

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20957#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs