Closed Bug 1429032 Opened 5 years ago Closed 5 years ago

Firefox 64's sandboxing layer does not allow Adobe Air to be installed at runtime.


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

57 Branch





(Reporter: ridhjain, Assigned: handyman)



User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171206182557

Steps to reproduce:

1. Ensure no Adobe Air runtime is installed.
2. Go to page and try to install any application. All the application require Adobe Air runtime to be present on the machine. Since no runtime is installed, it tries to fetch runtime from server at install time.

Actual results:

It does not install Adobe Air runtime and application on the machine.

Expected results:

Adobe Air runtime should be installed along with the application. If we execute "set MOZ_DISABLE_NPAPI_SANDBOX=1" on the console and then launch Firefox from the console, Air Runtime and application get installed without any issues.
Component: Untriaged → Security: Process Sandboxing
Product: Firefox → Core
Flags: needinfo?(davidp99)
In API Monitor, with the sandbox off, I can see that Flash is trying to use CreateProcessW to launch airinstaller28x0.exe, a file that has been downloaded to Flash's temp folder.  That won't work with the NPAPI sandbox.  It's possible that there are more sandbox issues but this is the obvious failure.

FYI, Chrome shows an alert saying "Adobe Flash Player on wants to access your computer."  Allow/Deny.
This is _after_ the "Allow Flash?" doorhanger -- its a different permission.
Pressing Allow brings up a "starting install" message and hangs, same as Firefox.  However, if you then refresh the page (in Chrome), it works (without asking if Flash can access your computer).  I can see that they broker the CreateProcess call somehow -- its run from their ppapi-broker process, not the ppapi one.  So at least we know remoting the operation is possible.

Like bug 1411379, its not clear how to write a secure API to handle this.  If we are good with hardcoding the paths or something then its easy but that may not be a good plan.  Thoughts?
Assignee: nobody → davidp99
Flags: needinfo?(davidp99) → needinfo?(bobowencode)
(In reply to David Parks (dparks) [:handyman] from comment #1)
> Like bug 1411379, its not clear how to write a secure API to handle this. 
> If we are good with hardcoding the paths or something then its easy but that
> may not be a good plan.  Thoughts?

If the download happens in the sandboxed child, even running with hard-coded paths seems like an easy sandbox escape.

The only way that I can think of would be to have a request from the child and then a very clear "Flash Player wants to download and run/install <URL to executable>." prompt.
Chrome's message seems pretty vague and I imagine a lot of people will probably just press Allow given that they have already allowed Flash to run.

FlashRuntime_Installers - Is Flash Player often used to install Adobe Air like this or is this a special case for this demo page?

Either way we should probably get someone like dveditz (or someone else from security engineering) and UX to look at any solutions.
(The same probably goes for bug 1411379 depending on what we decide there.)
Flags: needinfo?(bobowencode) → needinfo?(ridhjain)
Are we aware of any other case where Flash runs an executable? Could we maybe hardcode those hashes or check if they have some common digital signature from Adobe?
Or maybe just don't. "Running an executable" is exactly what the sandbox is supposed to stop malware from doing. If you poke a "good" hole in the sandbox it's still a hole.

If flash needs to include Air it should install Air when the user is at the "installing software" stage. It shouldn't be trying to do it from inside the sandbox and we shouldn't allow it.
The very page linked to in comment 0 says "Note: You will need to have Adobe AIR installed in order to run the applications on this page." right at the top. That seems right: if you're writing a Java app the user needs to install Java; if you're writing an AIR app the user needs to install AIR.
I also note the link in comment 0 is to an INSECURE http:// page that lures users to download and run software -- easy prey to network attacks. The page does load if you change the scheme to https:// but the actual software links are still insecure. None of that should even be available on an insecure server. It is hard to take requests to subvert our sandbox security seriously if that's the level of security awareness we're dealing with.
I'll look into how this works on OS X and report back.
Flags: needinfo?(haftandilian)
It is not Flash Player that requests Adobe Air to be installed. There are a lot of Air Applications(whose requirement is that there should be Adobe AIR runtime installed on the machine). For all such applications(e.g.: Adobe Connect), if Adobe AIR Runtime is not installed on the machine, it is downloaded from the server and installed at runtime.
The pages which load such apps are Flash Player based pages. 
There are a lot of such pages where Adobe Air runtime is installed as a pre-requisite for such applications.
(In reply to Haik Aftandilian [:haik] from comment #7)
> I'll look into how this works on OS X and report back.

This works on Mac because the Flash plugin process isn't sandboxed. The plugin process executes ~/Library/Preferences/Macromedia/Flash Player/ directly.

The flash plugin process is launched with

/Applications/ /Library/Internet Plug-Ins/Flash Player.plugin -greomni /Applications/ -appomni /Applications/ -appdir /Applications/ -profile ~/Library/Application Support/Firefox/Profiles/gkoc7qg1.Test 70114 gecko-crash-server-pipe.70114 org.mozilla.machname.1625164097 plugin
Flags: needinfo?(haftandilian)
Flags: needinfo?(ridhjain)
Related to whether or not this should be allowed on Windows, for what it's worth, there's a precedent for not allowing it. On macOS with the Safari browser, the NPAPI plugin is used in a sandboxed process and in order to install Air, the user needs to make a change in the Safari preferences to turn off "Run in Safe Mode" for the Flash plugin. See
We've determined this is a won't fix as is, although we're discussing work arounds with Adobe back channel.
Closed: 5 years ago
Priority: -- → P3
Resolution: --- → WONTFIX
See Also: → 1433577
See Also: → 1474375
You need to log in before you can comment on or make changes to this bug.