Tor Browser Bundle 4.0: updater fails on Windows
Tor Browser Updates works fine on Windows 7 32-bit, but fails on Win XP sp3 32 bit
Steps to reproduce:
-
Download and install "torbrowser-install-4.0-alpha-3_es-ES.exe" or "torbrowser-install-4.0-alpha-3_en-US.exe" in a clean directory from https://archive.torproject.org/tor-package-archive/torbrowser/4.0-alpha-3/
-
Run installed Tor Browser from created shortcut
-
Go to Help ... About Tor Browser and press "Check for updates"
-
When download finishes, click on restart to apply update
Actual results:
Tor Browser won't update and also will not start anymore.
Update files are leaved on \Tor Browser\Browser\TorBrowser\Data\Browser\Caches\firefox\updates\0
Expected Results:
Tor Browser should update from 4.0-aplha-3 to 4.0 stable as it does on Windows 7
Workaround: Remove update files from "...\Tor Browser\Browser\TorBrowser\Data\Browser\Caches\firefox" to let non-updated TBB run again.
Trac:
Username: marc
Activity
Replying to cypherpunks:
Can you to grab Tor Browser\Browser\TorBrowser\Data\Browser\Caches\firefox\updates\ folder by compressor (like 7zip or something) and attach to this ticket or to share it by some file-sharing site?
uploaded here: http://rghost.net/58766364
Trac:
Username: marc-
Now I've tested this issue on a VirtualBox Windows 7 system (no sp1) and TBB update also fails on this Win 7. I have other mozilla browsers (seamonkey, firefox and pale moon) on this XP system and updater always works fine.
Edit: Removed non relevant info. about Pentium CPU's.
Trac:
Username: marc So, I changed title for this bug report to "Tor Browser Bundle 4.0: updater fails on Intel Pentium 4".
Every CPU should be affected, bug 100% reproducible.
During startup firefox checks for
updater.exeand start it if can. Problem withlibssp-0.dlldynamically linked toupdater.exe. Loader tries to search dll:C:\Documents and Settings\user\Desktop\Tor Browser\Browser\TorBrowser\Data\Browser\Caches\firefox\updates\0\libssp-0.dll NOT FOUND C:\WINDOWS\system32\libssp-0.dll NOT FOUND C:\WINDOWS\system\libssp-0.dll NOT FOUND C:\WINDOWS\libssp-0.dll NOT FOUND C:\Program Files\Mozilla Firefox\libssp-0.dll NOT FOUND ( W.T.H ??!!!) C:\WINDOWS\system32\libssp-0.dll NOT FOUND C:\WINDOWS\libssp-0.dll NOT FOUND C:\WINDOWS\System32\Wbem\libssp-0.dll NOT FOUND
But fails with every tried path, then updater terminates without any message box. Dll stored in c:\Documents and Settings\user\Desktop\Tor Browser\Browser\libssp-0.dll but loader ignores that path (it tries to load from C:\Program Files\Mozilla Firefox\libssp-0.dll instead). The same problem with dynamically linked
msvcr100.dll, loader can't handle proper path and tries to load it from C:\Program Files\Mozilla Firefox (successfully if Firefox installed).-
Replying to cypherpunks:
So, I changed title for this bug report to "Tor Browser Bundle 4.0: updater fails on Intel Pentium 4".
Every CPU should be affected, bug 100% reproducible.
Ok, title changed again. :)
During startup firefox checks for
updater.exeand start it if can. Problem withlibssp-0.dlldynamically linked toupdater.exe. Loader tries to search dll:C:\Documents and Settings\user\Desktop\Tor Browser\Browser\TorBrowser\Data\Browser\Caches\firefox\updates\0\libssp-0.dll NOT FOUND ...
This makes sense. I've found that the Win 7 machine has "libssp-0.dll" on Pidgin install folder.
The same problem with dynamically linked
msvcr100.dll, loader can't handle proper path and tries to load it from C:\Program Files\Mozilla Firefox (successfully if Firefox installed).My Win 7 has "msvcr100.dll" on System32 folder. Probably that's why TBB is updating on Win 7 machine and not the XP or Virtual Win 7 (both has no pidgin installed and no 'libssp-0.dll', also no Firefox Installed).
Thanks!
Trac:
Username: marc Firefox removing the current directory from the standard search path by calling SetDllDirectory with an empty string, and In Windows, the SetDllDirectory API affects how child processes load implicitly-linked DLLs.
Replying to mcs:
I have not tested it yet, but would copying libssp-0.dll and msvcr100.dll into the updates\0 directory (next to the copy of updater.exe) fix this problem?
Answering my own question... I did test this solution by manually copying the two needed DLLs into the updates\0 directory right before I clicked the "Restart To Update" button. It worked. The downside of this solution is that we would need to hard-code the names of those two DLLs into the browser, here:
http://mxr.mozilla.org/mozilla-esr31/source/toolkit/xre/nsUpdateDriver.cpp#338
which means that if, in the future, updater.exe depends on another DLL or if the name of one of the DLLs is changed, things will break again.
I have not looked yet, but Mozilla must link their updater.exe in a special way to avoid external dependencies. That might be the best solution, but it is probably more difficult to implement.
Replying to mcs:
Replying to mcs:
I have not tested it yet, but would copying libssp-0.dll and msvcr100.dll into the updates\0 directory (next to the copy of updater.exe) fix this problem?
Answering my own question... I did test this solution by manually copying the two needed DLLs into the updates\0 directory right before I clicked the "Restart To Update" button. It worked. The downside of this solution is that we would need to hard-code the names of those two DLLs into the browser, here:
http://mxr.mozilla.org/mozilla-esr31/source/toolkit/xre/nsUpdateDriver.cpp#338
which means that if, in the future, updater.exe depends on another DLL or if the name of one of the DLLs is changed, things will break again.
Hmm... yes that is unfortunate, indeed.
I have not looked yet, but Mozilla must link their updater.exe in a special way to avoid external dependencies. That might be the best solution, but it is probably more difficult to implement.
That is tricky, yes, as we e.g. for XP users link against msvcr100 and our hardening plays a role here, too. If I understand comment:9 and comment:12 correctly then that might be a good solution we could try.
-
Replying to gk:
That is tricky, yes, as we e.g. for XP users link against msvcr100 and our hardening plays a role here, too. If I understand comment:9 and comment:12 correctly then that might be a good solution we could try.
I did some more digging to figure out why the updater succeeds on some Windows systems. On one of our Win7 systems, when starting updater.exe, it looks like a copy of libssp-0.dll from Browser\TorBrowser\Tor\ is used. This happens because Tor Launcher has added that directory to the PATH:
https://gitweb.torproject.org/tor-launcher.git/blob/HEAD:/src/components/tl-process.js#l389
And because there is a copy of msvcr100.dll in C:\Windows\System32, updater.exe can be loaded.
My conclusion the msvcr100.dll is the real problem (I will need to test again on WinXP to be sure).
Do you know if all Win7 systems have a copy of msvcr100.dll in their system directory? If so, then probably only WinXP (and possibly Vista) users are affected by this bug.
Although comment:12 has been "deleted" I think its contents are still relevant. One potential solution would be to ensure that the PATH contains the Browser\ directory (since it contains both libssp-0.dll and msvcr100.dll). This would only need to be done when starting the updater.
-
comment:12 was:
and no ways to bypass it.
It changes PATH environment variable. What for PATH in Tor Browser? What if to change call of SanitizeEnvironmentVariables (or directly SanitizeEnvironmentVariables), to clear PATH and to fill it by:
- The directory from which Tor Browser loaded.
- The system directory. Use the GetSystemDirectory function to get the path of this directory.
- The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
It allows to protect against injected paths and fixes
updater.exewithout extra voodoo or copying of need dlls to need dir.
-
Replying to mcs:
Replying to gk: Do you know if all Win7 systems have a copy of msvcr100.dll in their system directory? If so, then probably only WinXP (and possibly Vista) users are affected by this bug.
No idea.
Although comment:12 has been "deleted" I think its contents are still relevant. One potential solution would be to ensure that the PATH contains the Browser\ directory (since it contains both libssp-0.dll and msvcr100.dll). This would only need to be done when starting the updater.
Sounds good to me.
Do you know if all Win7 systems have a copy of msvcr100.dll in their system directory? If so, then probably only WinXP (and possibly Vista) users are affected by this bug.
msvcr100.dll is part of standalone
Visual C++ redistribution package. Redistributable Package installed by Visual Studio or by a 3rd party softwares, every day used computers with windows7 usually have to install it.Except not every newer redistributable package versions contains it but Microsoft Visual C++ 2010 SP1 Redistributable Package.-
A fix is available here:
It has been tested on an old WinXP system where I reproduced the original problem. Please review. If this fix looks good to others, we should pick it up for the next 4.0.x release as well as 4.5-alpha (when we can).
Trac:
Keywords: N/A deleted, MikePerry201410R added
Status: new to assigned
Owner: tbb-team to mcs -
I have some anecdotal evidence that the directory location specified by Mozilla's firefox.exe App Path (in the Registry) "wins out" over the PATH env variable. That could cause problems, especially once the updater depends on more DLLs (see #13379 (moved))
