Torbrowser crashes on start when using MS EMET 5.x
Trying to start the Tor Browser on Win7 x64 SP1 with MS EMET 5.1 installed and firefox.exe added to it leads to the following crash of firefox.exe:
EMET detected SimExecFlow mitigation and will close the application: firefox.exe
SimExecFlow check failed: Application : D:\Tor Browser\Browser\firefox.exe User Name : XYZ\XYZ Session ID : 1 PID : 0x1280 (4736) TID : 0x12C8 (4808) CodeAddress : 0x62B5EEF2 CodeStackPtr : 0x3CF190 CalledAddress : 0x77324AFF API name : kernel32.VirtualProtectEx StackPtr : 0x003CF130 FramePtr : 0x763298
IMHO it should be possible or even best practise to use Tor Browser together with EMET. Perhas a core developer can take a look at this. If you need more information, let me know.
Trac:
Username: Diapolo
Activity
Do you mean Tor Browser 4.0.2? Does it work with older versions, see: https://archive.torproject.org/tor-package-archive/torbrowser/? Might be good to EMET folks what their software is doing here.
I was indeed trying the 4.0.1 version, as I didn't see 4.0.2 was released. I'm currently downloading the new version and will report back.
Also it is good to know that normal Firefox 34 (and former versions) are working fine with MS EMET 5.1. If you want I can also try current Alpha of Tor Browser.
Trac:
Username: Diapolo-
With 4.0.2 same error:
EMET detected SimExecFlow mitigation and will close the application: firefox.exe
SimExecFlow check failed: Application : D:\Tor Browser\Browser\firefox.exe User Name : XYZ\XYZ Session ID : 1 PID : 0xA84 (2692) TID : 0x7A0 (1952) CodeAddress : 0x60A9EEF2 CodeStackPtr : 0x42F6B0 CalledAddress : 0x77324AFF API name : kernel32.VirtualProtectEx StackPtr : 0x0042F650 FramePtr : 0x8432B8
Trac:
Username: Diapolo -
Trac:
Username: Diapolo
Summary: Torbrowser 4.0.1_de crashes on start when using MS EMET 5.1 to Torbrowser 4.0.X crashes on start when using MS EMET 5.1
Cc: N/A to phil.kaufmann@t-online.de 
I just spent a few minutes learning a little bit about EMET, but there is a lot to learn. The following issue report (which I found via an Internet search) might be helpful:
https://trac.videolan.org/vlc/ticket/10583
Some thoughts after reading that ticket:
-
It might take a lot of effort for Tor developers to determine why EMET detects a problem. It might be a real problem, or just an incompatibility between Tor Browser and EMET's checks.
-
It sounds like VLC is also built with MinGW-w64, which probably explains why Mozilla's Firefox is not affected by this problem.
-
Since the Tor Browser executable has the same name as Firefox's (firefox.exe), I wonder if the rules that Microsoft applies to Firefox are also applied to Tor Browser (not necessarily a good thing since we cross compile and Mozilla uses MSVC). Of course I do not know if Microsoft has special rules for Firefox, but it sounds like they do for VLC so it is certainly possible.
Trac:
Cc: phil.kaufmann@t-online.de to phil.kaufmann@t-online.de, mcs-
-
The default protection profile for firefox.exe (which is also used for the Tor Browser) is this here:
mozjs.dll;xul.dllThis lists the SimExecFlow mitigation technique, which is one from different ROP (return oriented programming) techniques in EMET, which Microsoft describes as: "Without EMET in place, attackers can take advantage of a predictable mapping of those dlls and could use them in order to bypass DEP through a known technique called return oriented programming (ROP)."
Some details are listed here: http://blogs.technet.com/b/srd/archive/2012/07/24/emet-3-5-tech-preview-leverages-security-mitigations-from-the-bluehat-prize.aspx
Trac:
Username: Diapolo -
Replying to Diapolo:
Also it seems that SimExecFlow is only active for x86 versions of executables. Is there a 64 bit binary for Windows of the Tor Browser available!?
No. Mozilla does not yet ship a supported 64-bit release of Firefox, although they are working on it. I suspect that Microsoft has just not finished implementing SimExecFlow and some of the other mitigation techniques for 64-bit executables.
-
The same thing now happened for plugin-container.exe :-/.
EMET detected SimExecFlow mitigation and will close the application: plugin-container.exe
SimExecFlow check failed: Application : D:\Tor Browser\Browser\plugin-container.exe User Name : XYZ\XYZ Session ID : 1 PID : 0x1264 (4708) TID : 0x814 (2068) CodeAddress : 0x5E679214 CodeStackPtr : 0x3AECF0 CalledAddress : 0x76A64AFF API name : kernel32.VirtualProtectEx StackPtr : 0x003AEC90 FramePtr : 0xD945A0
Trac:
Username: Diapolo -
#15898 (moved) is a duplicate.
Trac:
Summary: Torbrowser 4.X.Y crashes on start when using MS EMET 5.1 to Torbrowser 4.X.Y crashes on start when using MS EMET 5.x
Keywords: EMET deleted, tbb-usability-stoppoint-app added -
API name : kernel32.VirtualProtectEx Firefox calling it directly by WindowsDllInterceptor used by IOInterposer. Interposer, interceptor, hooks, -- sound scary, isn't? Yes, it wasn't designed to be running by release code, but due to Bug1233208 it is.
Trac:
Username: cypherpunks_backup -
Neither the patch in comment:20 nor the hint in comment:16 work for me (I tested with EMET 5.2). So I started trying to find the first Tor Browser version that is not affected by this problem and to my surprise I landed at Tor Browser 3.0a4. While I tested I never had any issue with this one but Tor Browser 3.0b1 is already not starting for me. One of the things that changed from a4 to b1 and that caught my eye is the fix for #9084 (closed). I'll try to create 5.0.7-ish build without that fix to see if that solves the problem.
Trac:
Summary: Torbrowser 4.X.Y crashes on start when using MS EMET 5.x to Torbrowser 3.0b1 crashes on start when using MS EMET 5.x
Status: needs_review to needs_revision So I started trying to find the first Tor Browser version that is not affected by this problem and to my surprise I landed at Tor Browser 3.0a4. While I tested I never had any issue with this one but Tor Browser 3.0b1 is already not starting for me. Did you check what mingw runtime used for them? What API triggers EMET protection for them? Still kernel32.VirtualProtectEx?
One of the things that changed from a4 to b1 and that caught my eye is the fix for #9084 (closed).
Btw, yet #9114 (closed). Are you sure your EMET rules affected firefox.exe from directory structure of 3.0a4?
Not every EMET crash is about the same code, not every VirtualProtectEx is about VirtualProtect, etc.
-
Replying to cypherpunks:
One of the things that changed from a4 to b1 and that caught my eye is the fix for #9084 (closed).
Btw, yet #9114 (closed). Are you sure your EMET rules affected firefox.exe from directory structure of 3.0a4?
Good point, it turns out they did not affect firefox.exe due to #9144 (moved). Adjusting the paths made EMET preventing earlier Tor Browser versions, too, from starting.
Not every EMET crash is about the same code, not every VirtualProtectEx is about VirtualProtect, etc.
Good point as well. I need to look deeper at this but lack the time currently. :( Btw: The build with the patch for comment:20 is at
https://people.torproject.org/~gk/testbuilds/torbrowser-install-tbb-nightly_ALL_old.exe https://people.torproject.org/~gk/testbuilds/torbrowser-install-tbb-nightly_ALL_old.exe.asc
Trac:
Summary: Torbrowser 3.0b1 crashes on start when using MS EMET 5.x to Torbrowser crashes on start when using MS EMET 5.x Sorry for spam, but Mozilla fixed its bug, stated in comment:16, in FF 44b and later: https://hg.mozilla.org/releases/mozilla-beta/rev/71d087ecddc0 So, disabling IOInterposer was the right solution. But, as stated in comment:19, AvailableMemoryTracker is another bad stuff from Mozilla and can be disabled too - proof: Only two craps from all the FF code use WindowsDllInterceptor, which is an interceptor (by the name too :) that means "hacking" technique is used. This is unacceptable by any security mitigation tool. EMET closes Tor Browser when detects security hole in it that can be exploited by SimExecFlow technique. So, it is not a crash, but a security vulnerability. Usability of Tor Browser = zero in secured environments (protected by EMET or else), so severity is set to blocker (because EMET blocks insecure TBB, and this blocks TBB from using).
Trac:
Keywords: tbb-usability-stoppoint-app, tbb-crash deleted, tbb-security added
Severity: Normal to Blocker-
Replying to bugzilla:
Sorry for spam, but Mozilla fixed its bug, stated in comment:16, in FF 44b and later: https://hg.mozilla.org/releases/mozilla-beta/rev/71d087ecddc0 So, disabling IOInterposer was right solution.
Not sure what you mean but compiling Tor Browser with
--disable-optimizeseems to work even with the code in comment:16. So, EMET just does not like the optimized code mingw-w64 generates.This is no blocker, FWIW. If you are in the business of raising the severity of bugs, bumping it to 'Major' would have done the trick.
Hmm, does release version of the product have --disable-optimize enabled? EMET works fine, and mingw-w64 generates code as it asked to, but IOInterposer and AvailableMemoryTracker use unsafe technique (for Mozilla profiler, leaked from debug). Not "EMET doesn't like", but Tor Browser is vulnerable. In comment:31 mentioned that severity was set to Blocker, because this bug blocks Tor Browser from running in secured environments, but not in all envs - so, severity is Critical in all of them. You've always fired crash bugs with Critical, it is just copied. But there is no crash: EMET closes unsec app immediately that looks like crash. And it is not incompatibility between 2 apps: EMET rules are set to close unsec apps by default.
There is only one month to offer Mozilla to disable
AvailableMemoryTrackeron Beta and Release (like they did with Bug 1233208: Disable IOInterposer on Beta and Release).Trac:
Parent: N/A to #12820 (moved)-
FWIW: the Mozilla bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1245470. We might be able to workaround this problem this way.
I don't think that mingw is considered an important compiler target for the Mozilla project: we're focusing much of our Windows effort on clang-cl as a free alternative to MSVC. I'm happy to leave this bug open if you're planning on fixing it, otherwise I suggest we close INCOMPLETE.
Nice, but what about headers, libs, runtime code?
Seems they said you bye-bye. Their INCOMPLETE means:
The problem is vaguely described with no steps to reproduce, or is a support request. Of course, they don't want to spend time investigating "breaks with EMET". Maybe, more strict summary will do the trick: "Firefox with AvailableMemoryTracker enabled is vulnerable (SimExecFlow) when compiled with mingw-w64" or even "Disable AvailableMemoryTracker on Release" ?
"Disable AvailableMemoryTracker on Release"
And GetWindowInfo hook. Maybe something yet? Windows?
Oh, it seems somebody in comment:19 was wrong :( And, in general, we should ask GCC team to stop generating "overoptimized" code that makes addresses predictable and thus vulnerable to SimExecFlow. There were a lot of implications after Deep Hooks had been enabled by default in EMET. And cypherpunks suspected hooks as the reason of crashes. But now EMET is constantly auditing TBB with all Global Mitigation Settings disabled (incl. Deep Hooks) and the situation hasn't changed. (Seems to be a real vulnerability) Somebody proposed to do something with too aggressive inlining. So, it can be checked with
-Ob0whether it's the reason of the issues. Also, there are a lot of posts about surprises with-O3, so, maybe,-O2will help.(EMET version 5.5.5871.31892)
- a lot of calls to:
CodeAddress : 0x61462446 CodeStackPtr : 0x36E830 CalledAddress : 0x770FF0F2 API name : kernel32.LoadLibraryW StackPtr : 0x0036E5F0 FramePtr : 0x0