Suggestion for additional checks on Tor browser bundle startup script
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
Trac:
Username: ronvandaal_