[tor-bugs] #10281 [Applications/Tor Browser]: Investigate usage of alternate memory allocators and memory hardening options

[Tor Bug Tracker & Wiki]

#10281: Investigate usage of alternate memory allocators and memory hardening
options
-------------------------------------------------+-------------------------
 Reporter:  mikeperry                            |          Owner:
                                                 |  arthuredelstein
     Type:  enhancement                          |         Status:
                                                 |  needs_information
 Priority:  Very High                            |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-security, tbb-hardened,          |  Actual Points:
  TorBrowserTeam201612R                          |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  SponsorU
-------------------------------------------------+-------------------------

Comment (by arthuredelstein):

 Replying to [comment:37 gk]:
 > How did you test this? Do you have a test site showing the differences
 between the current behavior and the intended one?

 I don't have a test page, but I made a test patch that deliberately causes
 a buffer overflow. The patch is here:

 https://github.com/arthuredelstein/tor-browser/commits/10281+2_check

 In this code, I malloc a 5-byte array, but write 32 bytes:
 {{{
 +  char* test = (char*) malloc(5);
 +  for (int i = 0; i < 32; ++i) {
 +    test[i] = i;
 +    printf("test[%d] value: %d\n", i, (int) test[i]);
 +  }
 +  free(test);
 }}}

 (I arbitrarily put this code in a function that always runs on startup,
 loading of the XUL window.)

 {{{
 arthur at instance-3 ~/tor-browser (10281+2_check)> ./mach run
  0:02.27 /home/arthur/tor-browser/obj-x86_64-unknown-linux-
 gnu/dist/bin/firefox -no-remote -profile /home/arthur/tor-browser/obj-
 x86_64-unknown-linux-gnu/tmp/scratch_user
 test[0] value: 0
 test[1] value: 1
 test[2] value: 2
 test[3] value: 3
 test[4] value: 4
 test[5] value: 5
 test[6] value: 6
 test[7] value: 7
 test[8] value: 8
 test[9] value: 9
 test[10] value: 10
 test[11] value: 11
 test[12] value: 12
 test[13] value: 13
 test[14] value: 14
 test[15] value: 15
 test[16] value: 16
 test[17] value: 17
 test[18] value: 18
 test[19] value: 19
 test[20] value: 20
 test[21] value: 21
 test[22] value: 22
 test[23] value: 23
 test[24] value: 24
 test[25] value: 25
 test[26] value: 26
 test[27] value: 27
 test[28] value: 28
 test[29] value: 29
 test[30] value: 30
 test[31] value: 31
 <jemalloc>: Corrupt redzone 0 bytes after 0x7ff663ea6570 (size 8),
 byte=0x8
 <jemalloc>: Corrupt redzone 1 byte after 0x7ff663ea6570 (size 8), byte=0x9
 <jemalloc>: Corrupt redzone 2 bytes after 0x7ff663ea6570 (size 8),
 byte=0xa
 <jemalloc>: Corrupt redzone 3 bytes after 0x7ff663ea6570 (size 8),
 byte=0xb
 <jemalloc>: Corrupt redzone 4 bytes after 0x7ff663ea6570 (size 8),
 byte=0xc
 <jemalloc>: Corrupt redzone 5 bytes after 0x7ff663ea6570 (size 8),
 byte=0xd
 <jemalloc>: Corrupt redzone 6 bytes after 0x7ff663ea6570 (size 8),
 byte=0xe
 <jemalloc>: Corrupt redzone 7 bytes after 0x7ff663ea6570 (size 8),
 byte=0xf
 <jemalloc>: Corrupt redzone 8 bytes after 0x7ff663ea6570 (size 8),
 byte=0x10
 <jemalloc>: Corrupt redzone 9 bytes after 0x7ff663ea6570 (size 8),
 byte=0x11
 <jemalloc>: Corrupt redzone 10 bytes after 0x7ff663ea6570 (size 8),
 byte=0x12
 <jemalloc>: Corrupt redzone 11 bytes after 0x7ff663ea6570 (size 8),
 byte=0x13
 <jemalloc>: Corrupt redzone 12 bytes after 0x7ff663ea6570 (size 8),
 byte=0x14
 <jemalloc>: Corrupt redzone 13 bytes after 0x7ff663ea6570 (size 8),
 byte=0x15
 <jemalloc>: Corrupt redzone 14 bytes after 0x7ff663ea6570 (size 8),
 byte=0x16
 <jemalloc>: Corrupt redzone 15 bytes after 0x7ff663ea6570 (size 8),
 byte=0x17
 }}}

 So the free(...) call resulted in jemalloc detecting that a redzone had
 been overwritten. Note that 16 bytes of overwriting were detected, because
 allocation is chunked to 16 bytes here.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10281#comment:39>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online