504255 - Disable loading plugins on file:// or jar: URIs

Status: RESOLVED DUPLICATE of bug 1335475

(Core Graveyard :: Plug-ins, defect)

Description

[Gregory Fleischer]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1pre) Gecko/20090714 Shiretoko/3.5.1pre

Local file content loaded via the jar: protocol may lead to blended threats from plugins.  

Plugins such as Flash and Java apply their own security policy based on origin.  If the origin is the local file system, different rules are applied as compared to if the plugin content is loaded from the network.  For example, Flash can read local files and directories.  Previous versions of Java allowed for socket connections to the localhost.

Because HTML parsing ignores garbage content, a locally saved ZIP file with an HTML extension will be parsed and loaded as HTML content by Firefox.  A local HTML file is restricted to the files it can load, but it can always load itself.  

A HTML loadable ZIP file can be constructed by using a "store only" option to embed the desired HTML content without any compression and then adding additional content normally.  As a result, a ZIP file with an HTML extension can load self-contained content using the jar: protocol.

If Firefox is configured as the default browser, remote HTML content served
with "Content-Disposition: attachment" will be saved locally before being
opened.  When opened, the content can load itself and reference embedded plugin content.


Reproducible: Always

Comment 1

[Gregory Fleischer]

Attachment: Example of embedded HTML in ZIP

Save file locally and open.

This example attempts to use embedded Flash content to read either C:\boot.ini or /etc/hosts.

Based on Flash version, platform and local file permissions success may vary.

Comment 2

[Gregory Fleischer]

Attachment: Example of embedded HTML in ZIP #2

Save file locally and open.

This example attempts to use embedded Flash content to read root directory of either C:\ or /.

Based on Flash version, platform and local file permissions success may vary.

Comment 3

[Jesse Ruderman]

Sounds like two issues:

1. Plugins don't follow Firefox security policies, especially for local files.  Flash allows full filesystem access (like Firefox used to before the fix for bug 230606), and Java allows connecting to localhost.

2. A single file can simultaneously work as HTML and ZIP, so exploiting #1 only requires getting a user to download one file.  (Can you use data: URLs instead?)

I think addressing (1) is sounder, but I guess it would require disabling plugins for local files or getting plugin vendors to agree to changes.  Maybe there's a way to address (2) quickly and without breaking much content.

Comment 4

[Justin Dolske [:Dolske]]

#1 from comment 3 makes sense to me.

Let's stop loading plugins for locally saved content, because plugins have broken same-origin semantics there. Might need to block on having click-to-play plugin UI if this is commonly expected to work. Though it might be good enough to just have pref to globally allow/deny it.

Comment 5

[Josh Aas]

I don't think this bug needs to be private. It isn't severe enough to warrant that status, and a wider discussion will be useful.

Do you agree, dveditz?

Comment 6

[Josh Aas]

Click to play isn't going to make tricking users much harder and disabling all plugin loads for local content is going to break things for a lot of people. Perhaps the real bug here is that Flash allows full access to the file system for local loads.

Comment 7

[Daniel Veditz [:dveditz]]

I wonder if this is really a Core:Plug-ins bug... is there some amount of junk in the file that should have tipped off the HTML parser not to load that file? We could at the very least special-case ZIP detection because we have a special-case jar: protocol.

Not sure what Dolske meant in comment 4 by "plugins for locally saved content". If the HTML is local don't load plugin content of any kind? Or don't load plugin content if the src URL is also local?

The former is going to break a lot of legit (user desired) "save-as" pages, and "Save-as complete" often doesn't work for streaming content. Maybe we can get telemetry or Test Pilot numbers on how often people save pages?

Allowing only "remote" plugin content is a seductive option, but there's no way to ensure the remote content doesn't then attempt to rifle through your local disk if it's allowed to. Some plugins might restrict that ability to same-origin with the plugin content, but some of them use the origin of the host page.

A wider discussion of policy might be useful, but this is such a simple and clever trick that I worry that it will be used in social engineering attacks once people get the idea. Users might worry about downloading "executables" (and many don't worry enough!) but just about everyone will assume "Save-as" on an HTML file is OK.

One saving grace is that Save-as doesn't actually work, we subtly rewrite the file and break it as a .zip. That would make social engineering this slightly harder, but not much.

Comment 8

[Lucas Adamski [:ladamski]]

Local Flash content has to obey http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000451.html

When SWF files are published they can have either network or filesystem access, but not both.  They also can't communicate with other Flash files in the opposite local sandbox.

Not as familiar with Java but AFAIK unsigned JARs don't have local access, while any signed JAR can have full access even if loaded over the network (and granted permission by the user).

Comment 9

[Johnny Stenback (:jst)]

Opening this up, we have nothing to gain from keeping this bug closed.

Comment 10

[Justin Dolske [:Dolske]]

(In reply to Daniel Veditz [:dveditz] from comment #7)

> Not sure what Dolske meant in comment 4 by "plugins for locally saved
> content". If the HTML is local don't load plugin content of any kind?

Yes. It's simple (to explain, at least), seems rarely used, and I'm generally pleased with clamping down on plugins wherever possible. HTML5, baby!

> The former is going to break a lot of legit (user desired) "save-as" pages,
> and "Save-as complete" often doesn't work for streaming content. Maybe we
> can get telemetry or Test Pilot numbers on how often people save pages?

Telemetry would be nice to have.

But I'm pretty sure "Save As" already don't work on the vast majority of pages. Flash and Java, in particular, generally seem to put in remote content and/or have small stub-loaders for fast page loads (ie, just about every Flash game out there... There's even a site dedicated to collecting them: http://prettyloaded.com/)