Closed Bug 1303325 Opened 5 years ago Closed 5 years ago

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


(Core :: Security: Process Sandboxing, defect)

51 Branch
Not set



Tracking Status
firefox51 --- fixed


(Reporter: bobowen, Assigned: bobowen)



(Whiteboard: sbwc2)


(1 file)

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:

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:

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.
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 that cause issue with CoInitializeSecurity.

LGTM as long as all the tokens look OK at runtime!
Attachment #8791960 - Flags: review?(aklotz) → review+
Pushed by
Revert changes to that cause issue with CoInitializeSecurity. r=aklotz
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.