Opened 3 years ago

#20743 new enhancement

Suggestion for additional checks on Tor browser bundle startup script

Reported by: ronvandaal_ Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version: Tor: unspecified
Severity: Normal Keywords: libxul.so bundle TBB
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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

Child Tickets

Change History (0)

Note: See TracTickets for help on using tickets.