Network Drive file:// URLs not accessible with USER_NON_ADMIN token after chromium update

RESOLVED FIXED in Firefox 51

Status

()

Core
Security: Process Sandboxing
RESOLVED FIXED
a year ago
a year ago

People

(Reporter: bobowen, Assigned: bobowen)

Tracking

51 Branch
mozilla51
Points:
---

Firefox Tracking Flags

(firefox51 fixed)

Details

(Whiteboard: sbwc2)

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Assignee)

Description

a year ago
The details of the original problem with USER_NON_ADMIN after the chromium update can be seen in bug 1287426 comment 11 and onwards.

The work-around that I landed in patch part 8 of that bug, causes a problem because all restricted tokens appear to lose access to network drives, so file:// URLs are no longer accessible with USER_NON_ADMIN.

However, I think I've finally worked out that it is this change that is causing the problem:
https://hg.mozilla.org/mozilla-central/diff/a46f0e32289b/security/sandbox/chromium/sandbox/win/src/policy_target.cc

It seems that there is quite a lot of blocking that goes on during start-up and in the CoInitializeSecurity call.
But with this reverted, the internal ResumeImpersonate call succeeds and we're not left with an Anonymous Impersonation token.

This change was part of a change to the chromium code for the LowBox token, which we don't currently use:
https://codereview.chromium.org/937353002

So, I think we can safely revert this for the moment, although we may well want to look into calling LowerToken before CoInitializeSecurity or some other way of not blocking these things in certain circumstances.
Comment hidden (mozreview-request)
That removed code is really strange! It looks like the only purpose of that code is to validate the function call as a legit ThreadImpersonationToken call and forward anything that doesn't look normal to the real API.

If I am interpreting this correctly, presumably something passes in data to a ThreadImpersonationToken call that is somehow different from Chromium's expected input. Previously the call was forwarded, whereas now all input to that call is being unconditionally blocked.
Comment on attachment 8791960 [details]
Bug 1303325: Revert changes to policy_target.cc that cause issue with CoInitializeSecurity.

https://reviewboard.mozilla.org/r/79232/#review77826

LGTM as long as all the tokens look OK at runtime!
Attachment #8791960 - Flags: review?(aklotz) → review+

Comment 4

a year ago
Pushed by bobowencode@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/f4be1a7f9b3e
Revert changes to policy_target.cc that cause issue with CoInitializeSecurity. r=aklotz

Comment 5

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/f4be1a7f9b3e
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox51: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.