1379951 - a11y stack overflows at sandbox level 3

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect, P3)

Description

[roxleitan]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170710030203

NonVisual Desktop Access (NVDA)
Version: 2017.2
URL: http://www.nvaccess.org

[Steps to reproduce]:
1.Open NVDA
2.Run Firefox from Network Drive
3.Set security.sandbox.content.level=3 and restart the browser
4.Navigate to a web page ( e.g. facebook.com)

[Expected results]:
NVDA should read the text displayed in the Nightly window.

[Actual results]:
Nightly crashes over and over. 
https://crash-stats.mozilla.com/report/index/bp-51c4a565-2da0-4991-8bb2-c33e70170711

[Note]:
The crash is not reproducible with security.sandbox.content.level=2 (default)

Comment 1

[(No longer employed by Mozilla) Aaron Klotz]

Bob, what are our expectations re: Firefox on a network drive with level 3 sandboxing? Do we expect that to work?

Comment 2

[Bob Owen (:bobowen)]

(In reply to Aaron Klotz [:aklotz] (a11y work receiving priority right now, please send interceptor reviews to dmajor or handyman) from comment #1)
> Bob, what are our expectations re: Firefox on a network drive with level 3
> sandboxing? Do we expect that to work?

I think it should be working now.
We can't set the user's own SID to deny only, which I was doing originally for USER_LIMITED when not using restricting SIDs (restricting SIDs break running from a network drive completely).

It seems for audio (COM I think) deny only SIDs were being checked, but not restricting ones.

Originally I'd only stopped doing this for running firefox normally (not from network drive) with restricting SIDs, but I've had to stop it for network drive as well (bug 1377555).

So, I'm hopeful that this is working now assuming it was a similar problem to audio.

Roxana - would you mind re-testing with the latest Nightly.

Aaron - this does means that we're probably going to hit similar issues when we try to move to the USER_RESTRICTED access token level, which does set the user's SID to deny only. So it would be good if we can work out what's going on here, even if it's working at the moment.

Comment 3

[roxleitan]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170719030206

Hi Bob,

I tested with the latest Nightly 56.0a1 and managed to reproduce the crash.(only with security.sandbox.content.level=3)

Crash signature: https://crash-stats.mozilla.com/report/index/fa9ceeb8-4160-4a3f-b71d-df2740170720

Please see also bug 1378141

Comment 4

[Bob Owen (:bobowen)]

(In reply to [e-mail] from comment #3)
> Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101
> Firefox/56.0
> Build ID: 20170719030206
> 
> Hi Bob,
> 
> I tested with the latest Nightly 56.0a1 and managed to reproduce the
> crash.(only with security.sandbox.content.level=3)
> 
> Crash signature:
> https://crash-stats.mozilla.com/report/index/fa9ceeb8-4160-4a3f-b71d-
> df2740170720
> 
> Please see also bug 1378141

It seemed to generally be working for me, although I did get a couple of similar crash reports.
I think they only appeared after I'd restarted, so they might be shutdown crashes.

I'll dig a bit further.

Comment 5

[Bob Owen (:bobowen)]

I can't really determine what's going on here.
The stacks on crash-stats seem to be all over the place.

If I try and run with NVDA and a debug version, I get aseertions a [1] and [2] even at level 2.

[1] http://searchfox.org/mozilla-central/rev/3a3af33f513071ea829debdfbc628caebcdf6996/accessible/windows/msaa/Compatibility.cpp#101
[2] http://searchfox.org/mozilla-central/rev/3a3af33f513071ea829debdfbc628caebcdf6996/accessible/windows/msaa/AccessibleWrap.cpp#1448

Comment 6

[(No longer employed by Mozilla) Aaron Klotz]

I am removing [2] in bug 1383124.

Comment 7

[(No longer employed by Mozilla) Aaron Klotz]

As for [1], I just realized that the code in question is looking for combase.dll which doesn't exist yet on Windows 7. I'll need to fix that too.

Comment 8

[(No longer employed by Mozilla) Aaron Klotz]

(If you're trying a local build, just remove those two assertions)

Comment 9

[Bob Owen (:bobowen)]

I hit another couple of assertions at [1] and [2], but after commenting out those couldn't reproduce a crash.

Switching back to normal Nightly on a network drive, I could no longer reproduce on Win10 or Win7.

[1] http://searchfox.org/mozilla-central/rev/3a3af33f513071ea829debdfbc628caebcdf6996/ipc/mscom/Interceptor.cpp#374
[2] http://searchfox.org/mozilla-central/rev/3a3af33f513071ea829debdfbc628caebcdf6996/accessible/base/TextAttrs.cpp#86

Comment 10

[(No longer employed by Mozilla) Aaron Klotz]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f376e1ee725c5938a11b2a8e28d959afdd6bef47
Bug 1379951: Remove problematic assertion for a code path that is expected to be followed by NVDA; r=eeejay

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f376e1ee725c

Comment 12

[(No longer employed by Mozilla) Aaron Klotz]

Whoops, that patch had the wrong bug#

Comment 14

[Mihai Boldan, Desktop QA [:mboldan]]

Here are updated STR.
1. Launch Firefox.
2. Make sure that security.sandbox.content.level pref is set to 3.
3. Open NVDA.
4. Close NVDA.
5. Reopen NVDA.
6. Open a new tab in FF.

Expected:
Firefox works correctly.

Actual:
Firefox crashes after a few seconds.

Note that this issue is reproducible if the user is on junction point and also if opening Firefox from a network drive. 
Tests were performed on Firefox 56.0a1(2017-07-27), under Windows 7x64.

Please let me know if I can help any further with the investigation.

Comment 15

[Bob Owen (:bobowen)]

I can reproduce a crash (which I think is the same one) by starting-stopping-starting NVDA, but I'm having no joy working out the root cause where the sandbox is blocking.
Aaron - any chance you might be able to take a look at this?

Comment 16

[(No longer employed by Mozilla) Aaron Klotz]

It's on our triage list. That's the best I can do for the moment.

Comment 17

[(No longer employed by Mozilla) Aaron Klotz]

I need to repro this and findout what the actual HRESULT error code is.

Comment 18

[David Bolter [:davidb] (NeedInfo me for attention)]

I'm not sure if this is a P1 (need to fix on nightly) or P2... can wait a train?

Comment 19

[(No longer employed by Mozilla) Aaron Klotz]

I think I should whip up a patch to look for more specific error codes instead of just using FAILED().

Comment 20

[Jim Mathies [:jimm]]

Tracy, can you try reproing based on comment 14.

Comment 21

[Tracy Walker [:tracy]]

Sure, but I'll need help with setting up network drive or junction point.  Mihai, do you have details on doing such?

Comment 22

[Mihai Boldan, Desktop QA [:mboldan]]

(In reply to Tracy Walker [:tracy] from comment #21)
> Sure, but I'll need help with setting up network drive or junction point. 
> Mihai, do you have details on doing such?

Hello Tracy. 

Here is a guide that contains all the information needed in order to create a junction point https://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/.

Please let me know if I can help any further.

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.