Opened 3 years ago

Last modified 4 weeks ago

#13893 reopened defect

Torbrowser crashes on start when using MS EMET 5.x

Reported by: Diapolo Owned by: gk
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords: tbb-security, tbb-crash, tbb-usability-stoppoint-app, fuck-mingw-gcc, GeorgKoppen201609, TorBrowserTeam201610, ff52-esr
Cc: mcs, bugzilla, arthuredelstein Actual Points:
Parent ID: #12820 Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (92)

comment:1 Changed 3 years ago by gk

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.

comment:2 Changed 3 years ago by Diapolo

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.

comment:3 Changed 3 years ago by 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

comment:4 Changed 3 years ago by Diapolo

Cc: phil.kaufmann@… added
Summary: Torbrowser 4.0.1_de crashes on start when using MS EMET 5.1Torbrowser 4.0.X crashes on start when using MS EMET 5.1

comment:5 Changed 3 years ago by mcs

Cc: mcs added

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.

comment:6 Changed 3 years ago by Diapolo

The default protection profile for firefox.exe (which is also used for the Tor Browser) is this here:

<AppConfig Path="*" Executable="firefox.exe">

<Mitigation Name="DEP" Enabled="true" />
<Mitigation Name="SEHOP" Enabled="true" />
<Mitigation Name="NullPage" Enabled="true" />
<Mitigation Name="HeapSpray" Enabled="true" />
<Mitigation Name="EAF" Enabled="true" />
<Mitigation Name="EAF+" Enabled="true">

<eaf_modules>mozjs.dll;xul.dll</eaf_modules>

</Mitigation>
<Mitigation Name="MandatoryASLR" Enabled="true" />
<Mitigation Name="BottomUpASLR" Enabled="true" />
<Mitigation Name="LoadLib" Enabled="true" />
<Mitigation Name="MemProt" Enabled="true" />
<Mitigation Name="Caller" Enabled="true" />
<Mitigation Name="SimExecFlow" Enabled="true" />
<Mitigation Name="StackPivot" Enabled="true" />
<Mitigation Name="ASR" Enabled="false" />

</AppConfig>

This 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

comment:7 Changed 3 years ago by 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!?

Last edited 3 years ago by Diapolo (previous) (diff)

comment:8 in reply to:  7 Changed 3 years ago by mcs

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.

comment:9 Changed 3 years ago by Diapolo

Setting -SimExecFlow Option for firefox.exe allow starting the Tor Browser again, but best would be to know why it does NOT with that mitigation enabled :-/.

comment:10 Changed 3 years ago by Diapolo

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

comment:11 Changed 3 years ago by Diapolo

Summary: Torbrowser 4.0.X crashes on start when using MS EMET 5.1Torbrowser 4.X.Y crashes on start when using MS EMET 5.1

comment:12 Changed 3 years ago by gk

Keywords: tbb-usability-stoppoint-app added; EMET removed
Summary: Torbrowser 4.X.Y crashes on start when using MS EMET 5.1Torbrowser 4.X.Y crashes on start when using MS EMET 5.x

#15898 is a duplicate.

comment:13 Changed 2 years ago by gk

Owner: changed from tbb-team to gk
Sponsor: SponsorU
Status: newassigned

comment:14 Changed 2 years ago by gk

Keywords: TorBrowserTeam201512 GeorgKoppen201512 added
Severity: Normal

comment:15 Changed 2 years ago by cypherpunx

The same problem with EMET 5.2 on Windows 7 Sp1 x86 and Tor Browser 5.0.6/5.5a5. Firefox 43 starts without problems.

Last edited 2 years ago by cypherpunx (previous) (diff)

comment:16 Changed 2 years ago by cypherpunks_backup

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.

comment:17 Changed 2 years ago by cypherpunks_backup

Last edited 22 months ago by cypherpunks_backup (previous) (diff)

comment:18 Changed 2 years ago by cypherpunks_backup

Last edited 22 months ago by cypherpunks_backup (previous) (diff)

comment:19 Changed 2 years ago by cypherpunks_backup

Last edited 22 months ago by cypherpunks_backup (previous) (diff)

comment:20 Changed 2 years ago by cypherpunks_backup

Status: assignedneeds_review
Last edited 22 months ago by cypherpunks_backup (previous) (diff)

comment:21 Changed 2 years ago by gk

Keywords: TorBrowserTeam201601 added; TorBrowserTeam201512 removed

Tickets for Jan 2016.

comment:22 Changed 2 years ago by gk

Keywords: GeorgKoppen201601 added; GeorgKoppen201512 removed

comment:23 Changed 2 years ago by gk

Status: needs_reviewneeds_revision
Summary: Torbrowser 4.X.Y crashes on start when using MS EMET 5.xTorbrowser 3.0b1 crashes on start when using MS EMET 5.x

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. I'll try to create 5.0.7-ish build without that fix to see if that solves the problem.

comment:24 in reply to:  23 Changed 2 years ago by cypherpunks

Last edited 22 months ago by cypherpunks (previous) (diff)

comment:25 Changed 2 years ago by cypherpunks

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?

comment:26 Changed 2 years ago by cypherpunks

One of the things that changed from a4 to b1 and that caught my eye is the fix for #9084.

Btw, yet #9114. 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.

comment:27 in reply to:  26 Changed 2 years ago by gk

Summary: Torbrowser 3.0b1 crashes on start when using MS EMET 5.xTorbrowser crashes on start when using MS EMET 5.x

Replying to cypherpunks:

One of the things that changed from a4 to b1 and that caught my eye is the fix for #9084.

Btw, yet #9114. 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. 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

comment:28 Changed 2 years ago by cypherpunks

Last edited 22 months ago by cypherpunks (previous) (diff)

comment:29 Changed 2 years ago by Diapolo

OT: Who of the admins here is able to remove my old e-mail address from this thread or from the system at all? I always receive 2 notifications, one on the old, the other on the new address :-/?

comment:30 Changed 2 years ago by cypherpunks

Keywords: tbb-crash added

comment:31 Changed 2 years ago by bugzilla

Keywords: tbb-security added; tbb-crash tbb-usability-stoppoint-app removed
Severity: NormalBlocker

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).

Last edited 14 months ago by bugzilla (previous) (diff)

comment:32 in reply to:  31 Changed 2 years ago by gk

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-optimize seems 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.

comment:33 Changed 2 years ago by gk

Severity: BlockerMajor

comment:34 Changed 2 years ago by gk

Keywords: tbb-crash tbb-usability-stoppoint-app added

comment:35 Changed 2 years ago by bugzilla

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.

comment:36 Changed 2 years ago by cypherpunks

Last edited 22 months ago by cypherpunks (previous) (diff)

comment:37 Changed 23 months ago by gk

Keywords: TorBrowserTeam201602 added; TorBrowserTeam201601 removed

Putting stuff on the radar for February.

comment:38 Changed 23 months ago by bugzilla

Parent ID: #12820

There is only one month to offer Mozilla to disable AvailableMemoryTracker on Beta and Release (like they did with Bug 1233208: Disable IOInterposer on Beta and Release).

comment:39 Changed 23 months ago by gk

Keywords: GeorgKoppen201602 added; GeorgKoppen201601 removed

Updating my tickets.

comment:40 Changed 23 months ago by cypherpunks

Keywords: GCC mingw added

comment:41 Changed 23 months ago by cypherpunks

Keywords: mingw-gcc added; GCC mingw removed

comment:42 Changed 23 months ago by cypherpunks

Keywords: fuck-mingw-gcc added; mingw-gcc removed

comment:43 Changed 23 months ago by cypherpunks

Fuck windows, fuck mingw, and fuck everything near it.

comment:44 Changed 23 months ago by gk

FWIW: the Mozilla bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1245470. We might be able to workaround this problem this way.

comment:45 Changed 23 months ago by cypherpunks

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?

comment:46 Changed 22 months ago by bugzilla

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"
?

comment:47 Changed 22 months ago by cypherpunks

"Disable AvailableMemoryTracker on Release"

And GetWindowInfo hook. Maybe something yet? Windows?

comment:48 Changed 22 months ago by bugzilla

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 -Ob0 whether it's the reason of the issues.
Also, there are a lot of posts about surprises with -O3, so, maybe, -O2 will 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
Last edited 14 months ago by bugzilla (previous) (diff)

comment:49 Changed 22 months ago by cypherpunks

Oh, it seems somebody in comment:19 was wrong :(

Yep, I didn't try to use browser. But it starts just fine (was tested with EMET 5.2).

comment:50 Changed 22 months ago by cypherpunks

Also, there are a lot of posts about surprises with -O3, so, maybe, -O2 will help.

Look at about:buildconfig, for used flags:

-Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -Wno-format -fno-exceptions -fno-strict-aliasing -mms-bitfields -mstackrealign -fno-keep-inline-dllexport -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pipe -DNDEBUG -DTRIMMED -g -O -fomit-frame-pointer 

comment:51 Changed 22 months ago by bugzilla

Welcome new incompatibility with EMET (Windows 10 only) - Blocking Untrusted Fonts feature:

Untrusted fonts are any font installed outside of the %windir%/Fonts directory. Blocking untrusted fonts helps prevent both remote (web-based or email-based) and local EOP attacks that can happen during the font file-parsing process.

Replying to cypherpunks:

Look at about:buildconfig, for used flags

It was a general suggestion:

If package compilation fails and while not using -O2, try rebuilding with that option. (Gentoo)

And
Why is -fomit-frame-pointer explicit?

-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging.

Is -fno-exceptions just doubled or replacing something useful?

comment:52 Changed 22 months ago by gk

Keywords: GeorgKoppen201603 added; GeorgKoppen201602 removed

comment:53 Changed 22 months ago by gk

Keywords: TorBrowserTeam201603 added; TorBrowserTeam201602 removed

comment:54 Changed 21 months ago by gk

Keywords: GeorgKoppen201604 added; GeorgKoppen201603 removed

comment:55 Changed 21 months ago by gk

Keywords: TorBrowserTeam201604 added; TorBrowserTeam201603 removed

comment:56 Changed 20 months ago by bugzilla

Good news. TBB 6.0a5 seems to have only these four identical calls in a row:

  CodeAddress 	: 0x6A3894B6
  CodeStackPtr 	: 0x2EDC70
  CalledAddress : 0x7657F0F2
  API name 	: kernel32.LoadLibraryW
  StackPtr 	: 0x002EDA30
  FramePtr 	: 0x2EDE1C

comment:57 Changed 20 months ago by gk

Keywords: TorBrowserTeam201605 added; TorBrowserTeam201604 removed

Moving tickets

comment:58 Changed 20 months ago by gk

Keywords: GeorgKoppen201605 added; GeorgKoppen201604 removed

Moving things for me to May.

comment:59 Changed 20 months ago by gk

Cc: bugzilla added

Resolved #18935 as duplicate.

comment:60 Changed 19 months ago by gk

Keywords: GeorgKoppen201606 added; GeorgKoppen201605 removed

comment:61 Changed 19 months ago by gk

Keywords: TorBrowserTeam201606 added; TorBrowserTeam201605 removed

comment:62 Changed 18 months ago by gk

Keywords: GeorgKoppen201607 added; GeorgKoppen201606 removed

Moving my tickets

comment:63 Changed 18 months ago by gk

Keywords: TorBrowserTeam201607 added; TorBrowserTeam201606 removed

comment:64 Changed 17 months ago by gk

Keywords: TorBrowserTeam201608 added; TorBrowserTeam201607 removed

Moving items to August 2016.

comment:65 Changed 17 months ago by gk

Keywords: GeorgKoppen201608 added; GeorgKoppen201607 removed

Moving my tickets as well.

comment:66 Changed 16 months ago by gk

Getting back to this bug it seems with the switch to ESR45 the issues with VirtualProtectEx() are gone. My guess is this is due to https://bugzilla.mozilla.org/show_bug.cgi?id=1201205 (in particular due to

-    // restore protection; if this fails we can't really do anything about it
-    VirtualProtectEx(GetCurrentProcess(), aOrigFunction, nBytes, op, &op);

. Now we seem to have only issues with kernel32.LoadLibraryW (see e.g. https://blog.torproject.org/blog/tor-0287-released-important-fixes#comment-203173). Not sure yet, where this exactly is coming from but it matches my test results done with EMET and Tor Browser 5.5.5/6.0.4.

comment:67 Changed 16 months ago by gk

It seems that disabling code optimization by using --disable-optimize would solve this again.

comment:68 Changed 16 months ago by gk

Keywords: GeorgKoppen201609 added; GeorgKoppen201608 removed

Moving my tickets

comment:69 Changed 16 months ago by gk

Keywords: TorBrowserTeam201609 added; TorBrowserTeam201608 removed

Tickets for September.

comment:70 Changed 16 months ago by arthuredelstein

Cc: arthuredelstein added

comment:71 Changed 15 months ago by gk

Status: needs_revisionneeds_information

Okay, I seem to have a test build that fixes things for me. Could other EMET users that got hit by crashes test that one as well and report back whether there are still issues? It can be found on:

https://people.torproject.org/~gk/testbuilds/torbrowser-install-tbb-nightly_62_ALL.exe
https://people.torproject.org/~gk/testbuilds/torbrowser-install-tbb-nightly_62_ALL.exe.asc

It uses the latest mingw-w64 and underneath GCC 6.2.0. I got it to compile our stuff after some pain and my current hypothesis is that the optimization bug got fixed in the GCC's 6.x series. I tested that with EMET 5.51 on a Windows 7 machine.

comment:72 Changed 15 months ago by gk

Keywords: TorBrowserTeam201609R added; TorBrowserTeam201609 removed
Status: needs_informationneeds_review

I prepared branches for review. The tor-browser one is:

https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_13893_v3

which contains three fixes for GCC 6 compat. The relevant tor-browser-bundle commit is:

https://gitweb.torproject.org/user/gk/tor-browser-bundle.git/commit/?h=bug_13893_v4&id=ce775578f0dcdf79d4517c90b3c39804d1dea4e0

(Note: the latter is missing the pointer to the tor-browser bug_13893_v3 branch in my repo. That needs to get adjusted while testing).

I'd still like to hear feedback about whether my nightly build in comment:71 fixes the problem.

comment:73 Changed 15 months ago by Diapolo

@gk I verified that you were able to fix this bug, by testing your nightly on Win7 EMET 5.2 and Win8.1 EMET 5.51. 6.5a3 (based on Mozilla Firefox 45.4.0) is still suffering the bug, I cross-verified that also.

Thanks for your work :)!

comment:74 Changed 15 months ago by gk

Keywords: TorBrowserTeam201609 added; TorBrowserTeam201609R removed
Status: needs_reviewneeds_revision

\o/ and thanks for the report back. Let me produce a proper patch then...

comment:75 Changed 15 months ago by gk

Keywords: TorBrowserTeam201609R added; TorBrowserTeam201609 removed
Status: needs_revisionneeds_review

comment:76 Changed 15 months ago by gk

Keywords: TorBrowserTeam201610R added; TorBrowserTeam201609R removed

Moving review tickets to October.

comment:77 Changed 15 months ago by cypherpunx

Your nightly works also on Windows 7 32 bit with EMET 5.1.

comment:78 Changed 15 months ago by mcs

r=mcs
Both the tor-browser and tor-browser-bundle changes look okay as far as I can tell.

comment:79 Changed 15 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

I applied the tor-browser-bundle patch to master (0348263efd1cb8a9eca8737f3dc7734ef75e0966) and the tor browser ones to tor-browser-45.4.0esr-6.5-1 (ef6b1ceff3996006497ebbdbd02104031eaf64f5, e2e11538f13e7eb4aa8bd9daf8f3d89c1434c1ef, and 08136fae2fb1fb6b6713b0821c8cf6ea5666d192).

Thanks to all who followed along and helped fixing this bug!

comment:80 Changed 15 months ago by bugzilla

Do you want to see the truth?

comment:81 Changed 14 months ago by gk

Keywords: TorBrowserTeam201610 ff52-esr added; TorBrowserTeam201610R removed
Resolution: fixed
Status: closedreopened

We need to wait for switching to GCC 6 as Firefox is not ready yet. :( See #20381 for more details. We should revisit the state of GCC 6 support when we switch to Firefox 52 ESR.

comment:82 Changed 14 months ago by gk

Sponsor: SponsorU

comment:83 Changed 14 months ago by bugzilla

OK, as nobody cares, then some updates on my comments only:
AvailableMemoryTracker appeared to be a bad thing, despite the underlying bug was fixed. Moz devs wondered why they got so few report from it by their Telemetry, that's because it hangs the browser reliably after several calls.
Newer GCC is a good way to reveal bugs, not to fix, and it's not needed if nobody is going to fix them. So nothing has changed, it didn't work anyways.
It wasn't discovered by testers as

the application freezes very early in the process and does not completely start

because of ticket:18935#comment:24
About LoadLibraryW: PR_LD_LAZY
P.S. default for FF is -Os or without -g.

comment:84 in reply to:  83 ; Changed 14 months ago by gk

Replying to bugzilla:

Newer GCC is a good way to reveal bugs, not to fix, and it's not needed if nobody is going to fix them. So nothing has changed, it didn't work anyways.
It wasn't discovered by testers as

the application freezes very early in the process and does not completely start

because of ticket:18935#comment:24

I think Tor Browser started for all of them (see comment:73, comment:77 and I tested it on my machines as well) and it worked with GCC 6 while it did not without it.

Last edited 14 months ago by gk (previous) (diff)

comment:85 in reply to:  84 ; Changed 14 months ago by bugzilla

Replying to gk:

I think Tor Browser started for all of them (see comment:73, comment:75 and I tested it on my machines as well) and it worked with GCC 6 while it did not without it.

Have you seen the requirements for invoking AvailableMemoryTracker?
Have you reverted https://hg.mozilla.org/releases/mozilla-aurora/rev/7d7176ca2470 to test IOInterposer?
TBB freezes with EAF, nothing to discuss.
GCC could improve optimized code with -g, but it's not suitable for release.

comment:86 in reply to:  85 ; Changed 14 months ago by gk

Replying to bugzilla:

Replying to gk:

I think Tor Browser started for all of them (see comment:73, comment:75 and I tested it on my machines as well) and it worked with GCC 6 while it did not without it.

Have you seen the requirements for invoking AvailableMemoryTracker?

Yes. Not sure what you want to point out.

Have you reverted https://hg.mozilla.org/releases/mozilla-aurora/rev/7d7176ca2470 to test IOInterposer?

No. But what I did was compiling our latest 45.4.0esr code once with GCC < 6 and once with GCC 6 and the latter allowed me to run Tor Browser with EMET while the former not. *All* other things were equal.

TBB freezes with EAF, nothing to discuss.

You mean the nightly build I pointed you to? That worked pretty fine for me with all the EMET features enabled. Others reported that as well (and I assume they had all features enabled, too).

comment:87 in reply to:  86 ; Changed 14 months ago by bugzilla

Replying to gk:

Replying to bugzilla:

Replying to gk:

I think Tor Browser started for all of them (see comment:73, comment:75 and I tested it on my machines as well) and it worked with GCC 6 while it did not without it.

Have you reverted https://hg.mozilla.org/releases/mozilla-aurora/rev/7d7176ca2470 to test IOInterposer?

No.

Have you seen the requirements for invoking AvailableMemoryTracker?

Yes. Not sure what you want to point out.

That you didn't make the conditions to properly test for VirtualProtectEx calls.

No. But what I did was compiling our latest 45.4.0esr code once with GCC < 6 and once with GCC 6 and the latter allowed me to run Tor Browser with EMET while the former not. *All* other things were equal.

If EMET can't detect vulnerabilities at startup, it doesn't mean they are gone.

TBB freezes with EAF, nothing to discuss.

You mean the nightly build I pointed you to? That worked pretty fine for me with all the EMET features enabled. Others reported that as well (and I assume they had all features enabled, too).

It's about security, not bells and whistles with shiny checkboxes to enable them all. You can't activate some features without entering custom values.
Any app freezes with EAF, even M$ sees it (see https://support.microsoft.com/en-us/kb/3175024).
Here is your nightly (plugin-container.exe):

  CodeAddress 	: 0x5B387DC7
  CodeStackPtr 	: 0x51ECA0
  CalledAddress 	: 0x75BF0479
  API name 	: kernel32.VirtualProtectEx
  StackPtr 	: 0x0051EC20
  FramePtr 	: 0x5CCE3324

(You haven't answered why you use debug -g on Windows stable.)

comment:88 in reply to:  87 Changed 14 months ago by gk

Replying to bugzilla:

Replying to gk:

Replying to bugzilla:

Replying to gk:

I think Tor Browser started for all of them (see comment:73, comment:75 and I tested it on my machines as well) and it worked with GCC 6 while it did not without it.

Have you reverted https://hg.mozilla.org/releases/mozilla-aurora/rev/7d7176ca2470 to test IOInterposer?

No.

Have you seen the requirements for invoking AvailableMemoryTracker?

Yes. Not sure what you want to point out.

That you didn't make the conditions to properly test for VirtualProtectEx calls.

No. But what I did was compiling our latest 45.4.0esr code once with GCC < 6 and once with GCC 6 and the latter allowed me to run Tor Browser with EMET while the former not. *All* other things were equal.

If EMET can't detect vulnerabilities at startup, it doesn't mean they are gone.

Not sure what you mean. The difference I outlined is the one between a not working Tor Browser (compiled with GCC < 6) with EMET protections enabled and one that does work (compiled with GCC 6) while *all* other conditions are equal. And it is not about start-up only I tested the build while surfing for a while.

TBB freezes with EAF, nothing to discuss.

You mean the nightly build I pointed you to? That worked pretty fine for me with all the EMET features enabled. Others reported that as well (and I assume they had all features enabled, too).

It's about security, not bells and whistles with shiny checkboxes to enable them all. You can't activate some features without entering custom values.
Any app freezes with EAF, even M$ sees it (see https://support.microsoft.com/en-us/kb/3175024).
Here is your nightly (plugin-container.exe):

  CodeAddress 	: 0x5B387DC7
  CodeStackPtr 	: 0x51ECA0
  CalledAddress 	: 0x75BF0479
  API name 	: kernel32.VirtualProtectEx
  StackPtr 	: 0x0051EC20
  FramePtr 	: 0x5CCE3324

Works fine for me (I had not subjected plugin-container.exe to EMET previously) on my testing machines while the versions compiled with GCC < 6 are broken. EAF *is* enabled for what it is worth. So, maybe my machines are missing the Microsoft update that breaks EMET? But if that's the case and this is indeed affecting *any* application as you mentioned then there is nothing we can do from Tor Browser land to fix that. We can only mention it in #12820 I guess.

Last edited 14 months ago by gk (previous) (diff)

comment:89 Changed 13 months ago by Diapolo

Cc: phil.kaufmann@… removed

comment:90 Changed 8 months ago by bugzilla

Resolution: fixed
Status: reopenedclosed

WOW, something happened with gk, and he decided to build 7.0a3 with -fno-omit-frame-pointer to stop messing with CPU register, and it helped!!!
(Of course, AvailableMemoryTracker continues to be a crap, and WindowsDllInterceptor should be analyzed for creating RWX holes, but it is another story ;)

comment:91 in reply to:  90 Changed 8 months ago by gk

Replying to bugzilla:

WOW, something happened with gk, and he decided to build 7.0a3 with -fno-omit-frame-pointer to stop messing with CPU register, and it helped!!!
(Of course, AvailableMemoryTracker continues to be a crap, and WindowsDllInterceptor should be analyzed for creating RWX holes, but it is another story ;)

Mozilla did that, not I. Have a look at: https://bugzilla.mozilla.org/show_bug.cgi?id=1322735. That said it won't help with 64bit builds which we hope to get started soon.

comment:92 Changed 4 weeks ago by cypherpunks

Resolution: fixed
Status: closedreopened

Reopen then.

Note: See TracTickets for help on using tickets.