Firefox started via runas on Windows will not run Adobe Flash

RESOLVED WONTFIX

Status

()

Core
Security: Process Sandboxing
P3
normal
RESOLVED WONTFIX
3 years ago
10 months ago

People

(Reporter: garrona, Assigned: bobowen)

Tracking

45 Branch
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sb+][win7 only])

(Reporter)

Description

3 years ago
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.
(Reporter)

Updated

3 years ago
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
(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.
(Reporter)

Comment 2

3 years ago
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?

Updated

3 years ago
Component: Untriaged → Plug-ins
Product: Firefox → Core

Updated

3 years ago
Blocks: 1185532
Component: Plug-ins → Security: Process Sandboxing
Flags: needinfo?(bobowen.code)
(Assignee)

Comment 3

3 years ago
I'll look into it.
(Assignee)

Comment 4

3 years ago
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.
Flags: needinfo?(bobowen.code) → needinfo?(garrona)
(Reporter)

Comment 5

3 years ago
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.
Flags: needinfo?(garrona)
(Assignee)

Comment 6

3 years ago
(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.
Assignee: nobody → bobowen.code
Flags: needinfo?(bobowen.code)
(Assignee)

Comment 7

3 years ago
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.
(Assignee)

Updated

2 years ago
Flags: needinfo?(bobowen.code)
Whiteboard: [sb?]

Updated

2 years ago
Whiteboard: [sb?] → sb+

Updated

2 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 1165891
Bob, does this runas problem only affect Windows XP/Vista/7, as per your comment about nested jobs on Windows 8 in comment 9?
Flags: needinfo?(bobowen.code)
Priority: -- → P3
(Assignee)

Comment 9

2 years ago
(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.
(Assignee)

Comment 10

2 years ago
(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+.
Flags: needinfo?(bobowen.code)

Comment 11

2 years ago
Hey bob, would you consider this a blocker for 64-bit flash sandboxing work? This currently isn't in the tracking list.
Flags: needinfo?(bobowen.code)
Whiteboard: sb+ → sb?
(Assignee)

Comment 12

2 years ago
(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.
Flags: needinfo?(bobowen.code)

Updated

2 years ago
Whiteboard: sb? → [sb+][win7 only]

Updated

10 months ago
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.