[tor-bugs] #20100 [Applications/Tor Browser]: persistent libxul.so bug crashing TBB Linux/64 (but probably a bug in locally linked shared object)

[Tor Bug Tracker & Wiki]

#20100: persistent libxul.so bug crashing TBB Linux/64 (but probably a bug in
locally linked shared object)
--------------------------------------+--------------------------
 Reporter:  sjamaan                   |          Owner:  tbb-team
     Type:  defect                    |         Status:  new
 Priority:  High                      |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Major                     |     Resolution:
 Keywords:  tbb-crash                 |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------
Changes (by ronvandaal_):

 * priority:  Medium => High
 * severity:  Normal => Major


Comment:

 Another libxul.so oddity. Fresh system, stock Debian using TBB now. This
 one affects tor-browser-linux64-6.0.6_en-US.tar.xz

 Fresh unpack and run of TBB. Crashes after surfing to a popular website.

 Here only one byte changed:

 before crash: 1d66170 -- bytes: e800 f39a fec4 8948 48ea c389 8948 4cc7
 after crash:  1d66170 -- bytes: e900 f39a fec4 8948 48ea c389 8948 4cc7

 0xe8 turned 0xe9 (elf64-x86-64 format)

 1d66171:        e8 9a f3 c4 fe          callq  9b5510 <moz_xmalloc at plt>
 1d66171:        e9 9a f3 c4 fe          jmpq   9b5510 <moz_xmalloc at plt>


 I have to ask: is it normal for libxul.so binaries to change when run?
 (not a coder here, sorry)

 If not, maybe TBB could implement a integrity checker on the libs?

 I believe there's an issue with libxul in general, which also may affect
 the Tor Browser Bundle, Tails, etc.


 The difference here is 1 byte. It didn't expand like in other settings.
 With JMPQ there's no need for the CALL routine to return using RET, JMPQ
 discards proper control using addresses pushed on the stack. This
 behaviour could explain the segfaults in the other configurations.

 Right now TBB startup scripts don't check hashes of packaged libs. And why
 not? It's an easy feat to add to the start-tor-browser-desktop script.
 Call it an early warning system if you will. Now TBB runs REGARDLESS if a
 modded libxul.so is residing in the Browser/ directory. This is also a way
 to find users with similar problems (in case of no segfault, when TBB
 appears to "just" exit)

 Just my 2 cts

 ronvandaal

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