Open Bug 1379951 Opened 3 years ago Updated 2 years ago

a11y stack overflows at sandbox level 3

Categories

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

57 Branch
Unspecified
Windows
defect

Tracking

()

REOPENED
mozilla56
Tracking Status
firefox56 --- unaffected
firefox57 --- affected

People

(Reporter: roxana.leitan, Unassigned)

References

Details

(Whiteboard: aes+)

Crash Data

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)
Crash Signature: @ GetProxiedAccessibleInSubtree → [@ GetProxiedAccessibleInSubtree ]
Whiteboard: aes+
Component: Security: Process Sandboxing → Disability Access APIs
Bob, what are our expectations re: Firefox on a network drive with level 3 sandboxing? Do we expect that to work?
Flags: needinfo?(bobowencode)
(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.
Flags: needinfo?(bobowencode) → needinfo?(roxana.leitan)
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
Flags: needinfo?(roxana.leitan)
(In reply to roxana.leitan@softvision.ro 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.
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
I am removing [2] in bug 1383124.
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.
(If you're trying a local build, just remove those two assertions)
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
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
https://hg.mozilla.org/mozilla-central/rev/f376e1ee725c
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Whoops, that patch had the wrong bug#
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Crash Signature: [@ GetProxiedAccessibleInSubtree ] → [@ GetProxiedAccessibleInSubtree ] [@ mozilla::a11y::AccessibleWrap::GetIAccessibleFor ]
OS: Windows 10 → Windows
Hardware: x86_64 → Unspecified
Summary: a11y crashes [@ GetProxiedAccessibleInSubtree ] → a11y stack overflows at sandbox level 3
Duplicate of this bug: 1384851
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.
Flags: needinfo?(bobowencode)
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?
Flags: needinfo?(bobowencode) → needinfo?(aklotz)
It's on our triage list. That's the best I can do for the moment.
Flags: needinfo?(aklotz)
I need to repro this and findout what the actual HRESULT error code is.
Flags: needinfo?(aklotz)
Version: 56 Branch → 57 Branch
I'm not sure if this is a P1 (need to fix on nightly) or P2... can wait a train?
I think I should whip up a patch to look for more specific error codes instead of just using FAILED().
Flags: needinfo?(aklotz)
Tracy, can you try reproing based on comment 14.
Flags: needinfo?(twalker)
Sure, but I'll need help with setting up network drive or junction point.  Mihai, do you have details on doing such?
Flags: needinfo?(twalker) → needinfo?(mihai.boldan)
(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.
Flags: needinfo?(mihai.boldan)
You need to log in before you can comment on or make changes to this bug.