1228880 - Firefox started via runas on Windows will not run Adobe Flash

Status: RESOLVED WONTFIX

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

Description

[garrona]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20150814030208

Steps to reproduce:

Following situation:
I use W7x64 and a second user account with limited rights that is only for firefox. 
Now I run firefox via runas from my main account: 
C:\Windows\System32\runas.exe /user:firefox /savecred "C:\Program Files\Aurora-Nightly\firefox.exe"





Actual results:

This worked perfectly fine up to (including) Firefox nightly 43. I now updated to the newest nightly 45 (but also tested v44 with the same problem) and flash no longer gets loaded. There is simply nothing happening when going on a site with flash - the field for the flash container stays empty.
If I log into this windows user account and then run firefox, it works fine though.

Tested with a new FF profile and ProtectedMode=0 for flash and dom.ipc.plugins.sandbox-level.flash set to 0 - nothing works.

Comment 1

[Masatoshi Kimura [:emk]]

(In reply to garrona from comment #0)
> Tested with a new FF profile and ProtectedMode=0 for flash and
> dom.ipc.plugins.sandbox-level.flash set to 0 - nothing works.

The "dom.ipc.plugins.sandbox-level.flash" pref can't lower the sandbox level unless you define the "MOZ_ALLOW_WEAKER_SANDBOX" environment variable.

Comment 2

[garrona]

Thank you. Setting the environment variable in Windows worked fine. Now the sandbox is disabled and the plugin-container.exe process starts as expected and flash works. Tested three times - removed the env variable: flash did not work, added it again: flash worked.
I also tested it with nightly 43 - setting the "dom.ipc.plugins.sandbox-level.flash" to 2 (default is 0 there) and flash stopped working.

I found this bug regarding the sandbox: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1185532
Am I allowed to link my bug there or how does this work?

Comment 3

[Bob Owen (:bobowen)]

I'll look into it.

Comment 4

[Bob Owen (:bobowen)]

The problem here seems to be that the runas command assigns a new job object to the process.
Presumably to enforce some sort of separation from the calling process.

To enforce some of the restrictions the sandbox also uses a new job object.
Prior to Windows 8 you couldn't have nested jobs, so it has to set a CREATE_BREAKAWAY_FROM_JOB flag to do this.
It seems that this fails for the process created through runas.
It also doesn't appear to be a permissions thing, because even if you runas for the current user it fails.

On Nightly with e10s enabled, where we have a sandbox on the content process, that fails to start and you can't do anything.
If you try the same trick with Chrome, as expected, it also fails.

It works on Win8+ (I tried on Windows 10), because nested jobs are allowed.

I'm not sure what we can do about this, but once we are shipping a decent sandbox, hopefully you won't want to do this anyway.
Do you know if this sort of thing is a widespread practice?


I also guess that you are currently turning off Protected Mode for flash?
It uses an old version of the chromium sandbox and so runs into the same problem from my testing.
I'm not sure how advisable that is, even given the fact that you are running under a limited profile for solely this purpose.
If this is the case then running with an env var of MOZ_DISABLE_NPAPI_SANDBOX=1 set, does the same job (you don't have to mess with prefs with this env var).
But again I'm not sure that is a wise thing to do.

I'm a bit surprised that you said it worked up until Nightly 43 - perhaps this was for 32-bit, we only enable the sandbox for 64-bit flash, because 32-bit has Protected Mode.

Comment 5

[garrona]

Good to know what causes this error.

> On Nightly with e10s enabled, where we have a sandbox on the content process, that fails to start and you can't do anything.
I do/did not have e10 enabled.

> I'm not sure what we can do about this, but once we are shipping a decent sandbox, hopefully you won't want to do this anyway.
Having the browser under a separate user? Well I do it to have more protection - a Windows privilege escalation is less likely than a sandbox escape I think (seeing that there are Chrome sandbox bugs from time to time).
> Do you know if this sort of thing is a widespread practice?
Don't think so, but I always suggest people doing it. For example all those crypto drive-by  malware will not be able to do anything (providing it does not use expensive Windows privilege escalation exploits).

> I also guess that you are currently turning off Protected Mode for flash?
> I'm a bit surprised that you said it worked up until Nightly 43 - perhaps this was for 32-bit, we only enable the sandbox for 64-bit flash, because 32-bit has Protected Mode.
I used 64-bit nightly 43 (and several 64-bit versions versions before) without any problems (never e10).
Yes I disabled Protected Mode from Flash. When they introduced it I had similar problems with runas (although I don't know if I used 32-bit FF back then (but likely I did)). 
The about:plugin page for the 64-bit nightly 45 says it uses "C:\Windows\system32\Macromed\Flash\NPSWF64_19_0_0_245.dll" (although the folder name, this should be the 64-bit version I think) - there is another copy in \syswow64\macromed\ (this one should be the 32-bit plugin if I'm correct).
I'm not quite sure if I had the mms.cfg file with "ProtectedMode=0" in the syswow64 or in the system32 folder though (changed it for testing before opening this bugreport) - and if that affected the 64-bit plugin at all.

Comment 6

[Bob Owen (:bobowen)]

(In reply to garrona from comment #5)

> > I'm not sure what we can do about this, but once we are shipping a decent sandbox, hopefully you won't want to do this anyway.
> Having the browser under a separate user? Well I do it to have more
> protection - a Windows privilege escalation is less likely than a sandbox
> escape I think (seeing that there are Chrome sandbox bugs from time to time).

Right, I do appreciate why you are doing this and it does not seem like an unreasonable thing to do.
I just don't know whether a Windows privilege escalation is less likely that a sandbox escape.

I'll talk this over with some colleagues, it may be reasonable to add an environment variable to allow no jobs to be used for the sandbox, when it is already in one that doesn't allow breakaway.
I've looked at Chromium's code and it appears that they have a command line switch for something similar, so it should be fairly straight forward to implement.

That way you should be able to runas the more limited user, but still get all the benefits of the sandboxes on the child processes apart from the restrictions provided through using a separate job.

> > I'm a bit surprised that you said it worked up until Nightly 43 - perhaps this was for 32-bit, we only enable the sandbox for 64-bit flash, because 32-bit has Protected Mode.
> I used 64-bit nightly 43 (and several 64-bit versions versions before)
> without any problems (never e10).

Ah, right my mistake, I landed the sandbox for 64-bit during the 43 cycle, so you must have had a version before this.

Comment 7

[Bob Owen (:bobowen)]

I spoke to a couple of people last week and there was general agreement that adding an environment variable to stop using just the job related parts of the sandbox when not allowed, would be OK.
So, then you could use that instead of turning the sandbox off altogether.

This is not right at the top of my priorities at the moment, but I'll leave the neddinfo to nag me, so hopefully I'll get round to it fairly soon.

Comment 8

[Chris Peterson [:cpeterson]]

Bob, does this runas problem only affect Windows XP/Vista/7, as per your comment about nested jobs on Windows 8 in comment 9?

Comment 9

[Bob Owen (:bobowen)]

(In reply to Chris Peterson [:cpeterson] from comment #8)
> Bob, does this runas problem only affect Windows XP/Vista/7, as per your
> comment about nested jobs on Windows 8 in comment 9?

I believe so.
I'm not totally clear in comment 4 but I assume I was talking about Firefox not Chrome with the win 8+ comment.

I'll confirm when I'm back.

Comment 10

[Bob Owen (:bobowen)]

(In reply to Chris Peterson [:cpeterson] from comment #8)
> Bob, does this runas problem only affect Windows XP/Vista/7, as per your
> comment about nested jobs on Windows 8 in comment 9?

Yes, looks like this doesn't affect Windows 8+.

Comment 11

[Jim Mathies [:jimm]]

Hey bob, would you consider this a blocker for 64-bit flash sandboxing work? This currently isn't in the tracking list.

Comment 12

[Bob Owen (:bobowen)]

(In reply to Jim Mathies [:jimm] from comment #11)
> Hey bob, would you consider this a blocker for 64-bit flash sandboxing work?
> This currently isn't in the tracking list.

It's difficult to say how many people might want to run Firefox like this, but I suspect it is fairly low.
I would have thought that it shouldn't block, but we can discuss on Thursday.

I think we can pull in some code from chromium for this check, so it probably won't be too painful to implement once we get round to it.