[tor-bugs] #13893 [Applications/Tor Browser]: Torbrowser crashes on start when using MS EMET 5.x
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Oct 18 17:40:42 UTC 2016
#13893: Torbrowser crashes on start when using MS EMET 5.x
-------------------------------------------------+-------------------------
Reporter: Diapolo | Owner: gk
Type: defect | Status:
| reopened
Priority: High | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Major | Resolution:
Keywords: tbb-security, tbb-crash, tbb- | Actual Points:
usability-stoppoint-app, fuck-mingw-gcc, |
GeorgKoppen201609, TorBrowserTeam201610, |
ff52-esr |
Parent ID: #12820 | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by gk):
Replying to [comment:87 bugzilla]:
> Replying to [comment:86 gk]:
> > Replying to [comment:85 bugzilla]:
> > > Replying to [comment:84 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 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.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13893#comment:88>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list