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

[tor-bugs] #20743 [Applications/Tor Browser]: Suggestion for additional checks on Tor browser bundle startup script

#20743: Suggestion for additional checks on Tor browser bundle startup script
------------------------------------------+--------------------------------
     Reporter:  ronvandaal_               |      Owner:  tbb-team
         Type:  enhancement               |     Status:  new
     Priority:  Medium                    |  Milestone:
    Component:  Applications/Tor Browser  |    Version:  Tor: unspecified
     Severity:  Normal                    |   Keywords:  libxul.so bundle
                                          |  TBB
Actual Points:                            |  Parent ID:
       Points:                            |   Reviewer:
      Sponsor:                            |
------------------------------------------+--------------------------------
 In addition to ticket #200100 (bug) - a new ticket for a suggestion.


 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@plt>
 1d66171: e9 9a f3 c4 fe jmpq 9b5510 <moz_xmalloc@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/20743>
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