1321493 - NPAPI sandbox is blocking Flash RTMPS SecureSocket from using Windows certificate APIs on Win64

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect, P2)

Description

[Chris Peterson [:cpeterson]]

Adobe reports that the 64-bit NPAPI sandbox is blocking some Windows certificate APIs, including CertOpenStore and CertGetCertificateChain. Those functions fail with system error 0x05, which means "Access Denied".

Comment 1

[Jim Mathies [:jimm]]

David, this is a new 64-bit plugin sandbox bug, could you please take a look.

Comment 2

[David Parks [:handyman]]

Attachment: Plugin that tests various CertOpenStore calls

Bob,

The attachment is plugin source + debug DLL that does a number of calls to CertOpenStore to see what works and what doesn't.  For the experiment, I set plugin.load_flash_only to false and dom.ipc.plugins.sandbox-level.default to 2.

The code runs fine at sandbox level 1.  The issue with level 2 is the "low" integrity level.

I don't believe HCERTSTOREs can be shared across processes so straightforward proxying with the broker is out, even if it was limited to read-only.

Any recommendations?

Comment 3

[Bob Owen (:bobowen)]

(In reply to David Parks [:handyman] from comment #2)
> Created attachment 8818764 [details]
> Plugin that tests various CertOpenStore calls
> 
> Bob,
> 
> The attachment is plugin source + debug DLL that does a number of calls to
> CertOpenStore to see what works and what doesn't.  For the experiment, I set
> plugin.load_flash_only to false and dom.ipc.plugins.sandbox-level.default to
> 2.
> 
> The code runs fine at sandbox level 1.  The issue with level 2 is the "low"
> integrity level.

Is it definitely the low integrity that is blocking this.
When Prezi had an issue related to this, I thought it was the USER_INTERACTIVE access token level.
More specifically (from what I remember) it was the removal of WinAuthenticatedUserSid that caused the issues there.
i.e. it isn't in the restricted token list:
http://searchfox.org/mozilla-central/rev/36bfd0a8da5490274ca49c100957244253845e52/security/sandbox/chromium/sandbox/win/src/restricted_token_utils.cc#64
 
> I don't believe HCERTSTOREs can be shared across processes so
> straightforward proxying with the broker is out, even if it was limited to
> read-only.
> 
> Any recommendations?

Sounds like this would be much more work to proxy then and presumably we'd need more details from Flash over what they need.
I'm guessing they must know this as they'll have to be proxying this themselves for their protected mode.

From emails it sounds like we're unsure as to how much this API is actually used in the wild, there is some thought that it might be more used in enterprise, but then they could always use ESR (which won't have the 64-bit installer by default yet).

My feeling is that if we eventually decide to allow it, the simplest way may be to add a parameter to 
SetTokenLevel that allows you to pass a list of SID exceptions (similar to the UI exceptions you can pass to SetJobLevel).
It would mean more changes to the chromium code, but shouldn't be too big.
It would be good to know if adding |restricted_token.AddRestrictingSid(WinAuthenticatedUserSid)| in to USER_INTERACTIVE fixes the issue. Also if it still works for USER_LIMITED with that and a push_back for the deny only SID exceptions, because we'd like to start using that if we can.

I think at the moment it is still undecided as to whether we need to fix this, but it will be good to know what our options are.
I imagine the proxying option could be quite painful.

Comment 4

[Julien Cristau [:jcristau]]

Mass wontfix for bugs affecting firefox 52.

Comment 6

[Chris Peterson [:cpeterson]]

Let's track this RTMPS bug for our Win64 rollout in 54 and 55, but it might not need to block 55.

Comment 8

[Jim Mathies [:jimm]]

fixed in a parent bug.