Inconsistent security policy in CSS file loading in local filesystem for images

RESOLVED WORKSFORME

Status

()

Core
General
RESOLVED WORKSFORME
3 years ago
4 months ago

People

(Reporter: dwighthouse, Unassigned)

Tracking

38 Branch
x86_64
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Created attachment 8610235 [details]
ExampleFilesystem.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36

Steps to reproduce:

In Firefox (no other modern browsers I can find exhibit this behavior):
1. Create and load an HTML file from local filesystem that loads a CSS file from anywhere on the hard drive.
2. Set that CSS file to load an image as background or border-background from anywhere on the hard drive.
3. Set that CSS file to load a font using @font-face from anywhere on the hard drive.
4. Load an image from anywhere on the hard drive using an img tag.

The attached file has a complete example of all relevant variations.


Actual results:

The images always display, regardless of where they sit on the hard drive.
The font files ONLY display if the font file exists in a directory at or below the directory containing the HTML file that loaded the page, otherwise, an error is printed to the console: "downloadable font: download failed".


Expected results:

Either the fonts should have loaded as normal, or the images above the HTML file's directory should not have loaded.

The ability to access arbitrary image files on a user's hard drive by the local filesystem is FAR more dangerous than font loading because image files are more personal/privacy-sensitive than fonts and image filename conventions and locations are more easily guessed.

What we have now is a false promise of security while ignoring a bigger problem.
(Reporter)

Updated

3 years ago
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64

Updated

3 years ago
Component: Untriaged → Untriaged
Product: Firefox → Core
On the web images can be loaded from anywhere, and fonts can only be loaded from same-origin (unless you have CORS headers). While images can be _loaded_ from anywhere, they cannot be accessed/inspected unless they are same origin.

For local files Firefox considers subdirectories of the file you opened to be "same-origin", but other random locations not. This is why font loading is restricted (local files don't have HTTP headers so no CORS)--simply following the rules, not because we think local fonts are particularly dangerous.

If you tried to read images from other locations on disk (such as by putting it in a canvas and then trying to read the data back out) then you will find that you are not allowed to do that. This _IS_ intentionally implemented as a security mechanism, the font stuff is just logical consequences.
Group: core-security
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 3

3 years ago
What is the functional difference between loading fonts and loading images locally? Why don't fonts load, but remain uninspectable, as images do? Or, why do images load outside the 'same-origin directories' at all, as fonts do not? What part of the spec allows for this inconsistency? I looked through the CSS3 Font spec, the CORS spec, and the CSS Font Loading Module Level 3 spec, but was not able to find the described behavior.

Comment 4

3 years ago
(In reply to dwighthouse from comment #3)
> What is the functional difference between loading fonts and loading images
> locally? Why don't fonts load, but remain uninspectable, as images do?

You can't really have fonts be "uninspectable" because of CSS. Changing what font is being used is going to change the font metrics which will change content sizes. See also the mitigations browsers had to implement for :visited reading using CSS.

> Or,
> why do images load outside the 'same-origin directories' at all, as fonts do
> not?

This would break the internet. I'm not joking; a lot of pages rely on being able to load images from everywhere. See also the relevant note in the last spec I link to, below.

> What part of the spec allows for this inconsistency? I looked through
> the CSS3 Font spec, the CORS spec, and the CSS Font Loading Module Level 3
> spec, but was not able to find the described behavior.

I'm 99% sure the specs regarding "origin" are https://html.spec.whatwg.org/multipage/browsers.html#origin and https://url.spec.whatwg.org/#origin, in particular regarding the "file" scheme:

> Unfortunate as it is, this is left as an exercise to the reader. When in doubt, return a new globally unique identifier.

Note that the former spec explicitly talks about image data and font origins. The definition of the algorithm to load images seems to be here: https://html.spec.whatwg.org/multipage/embedded-content.html#update-the-image-data . I expect the font specs have a similar definition of how to load a font.
(Reporter)

Comment 5

3 years ago
(In reply to :Gijs Kruitbosch from comment #4)
> You can't really have fonts be "uninspectable" because of CSS. Changing what
> font is being used is going to change the font metrics which will change
> content sizes. See also the mitigations browsers had to implement for
> :visited reading using CSS.

I understand that security concern, but that exact concern applies to images as well. Images have implicit size that can shift surrounding content, so at least the existence of the image on the local filesystem can be detected.

> This would break the internet. I'm not joking; a lot of pages rely on being
> able to load images from everywhere. See also the relevant note in the last
> spec I link to, below.

I could make a similar case for fonts, but that is irrelevant. We're talking about the local filesystem (file://) context only, not the larger internet. Relative urls to the user's filesystem only work when the HTML file is loaded from the user's hard drive. The problem is that the local filesystem's "origin" is the HTML file's containing directory when loading in a local filesystem context, which breaks fonts, but not images (or CSS files themselves for that matter) for some reason.

> I'm 99% sure the specs regarding "origin" are
> https://html.spec.whatwg.org/multipage/browsers.html#origin and
> https://url.spec.whatwg.org/#origin, in particular regarding the "file"
> scheme:
> 
> > Unfortunate as it is, this is left as an exercise to the reader. When in doubt, return a new globally unique identifier.

So it's Firefox's prerogative what to do in this case? Ok, let's at least be consistent with ourselves, even if we won't be consistent with other modern browsers.
Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598
Component: Untriaged → General
You need to log in before you can comment on or make changes to this bug.