268793 - CheckLoadURI for images prevents harmless input validation

Status: RESOLVED INVALID

(Core :: Security, defect)

Description

[Ed Resnick]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

Bug #69070 dealt with the security vulnerability of displaying file:// images in
http:// sites via the <img> tag, since the OnError and OnLoad handlers could be
used to verify whether it exists or not, and report that back to the server.

However, the fix is a bit drastic, in that a user can explicitly enter an image
path into a file input (<input type="file">), thus allowing the server to load
it, yet the client cannot load it. That's a bit backwards.

If you visit the URL I gave, using either a pre-0.10.1 version of Firefox, or
just IE, and you scroll to the Images section (and have JavaScript enabled, of
course), you can see a list of file inputs. Type in the path to an image, and
once you've entered a valid path, a thumbnail of the image will be displayed,
along with the width and height of the image (and, in IE, the file size). This
is very useful to show the user which image he entered, and let him realize if
he made a typo.

I fail to see how this is insecure, since the user has obviously explicitly
stated he wants the website to load that image. I request that local images be
allowed to be displayed if the 'src' attribute matches the path of one of the
file inputs on the page.

Technically, another work-around is to allow local images unconditionally, but
to disable the onload and onerror event handlers for them, so the script is
blind to what's happening. But in my case, that would still break my site
because I wouldn't be able to get the width and height and scale the thumbnail
accordingly (it's supposed to keep the proportions of the original image).

Reproducible: Always
Steps to Reproduce:
1. Put a file input on a page.
2. When the user enters something into it, attempt to display it in an <img> tag.
3.

Actual Results:  
It does not display.

Expected Results:  
It should either display and trigger OnLoad() or fail to load and trigger OnError().

Comment 1

[Ed Resnick]

Oh, one more thing -- probably someone might make the claim that even when
displaying images that are going to be uploaded to the server, the path can be
examined and learn, for example, the OS used, since the path is not sent when
the file is uploaded (just the name of the file itself). But you can do that
anyway, by using javascript to copy the file input's value to a hidden input. If
the file is uploaded without a problem, you can look at the hidden input's value
and know that's a valid path, or if there was an error, you can look at the
hidden value and know that's an invalid path.

So, displaying images that were entered into file inputs creates zero security
compromises.

Comment 2

[Ed Resnick]

Someone mentioned that if my suggestion were implemented, the user might still
type the wrong path and not be able to correct it before the JavaScript attempts
to load it. I'm not really sure how exactly that can be exploited, especially
since it has to be an actual image the user types in... does it matter if he
types screenshot43.jpg when he meant screenshot12.jpg?

Comment 3

[Matthias Versen [:Matti]]

And where is the problem that the user uploads the image, gets a preview from
the server and confirms that this is the right image ?

And you can't use IEs example because this is one of the general IE security
problems because IE always allows to link to local files.

And this bug is also invalid because such a discussion belongs a) in the bug
itself or better b) in the newsgroups or c) with the developer who fixed that

Comment 4

[Ed Resnick]

(In reply to comment #3)
> And where is the problem that the user uploads the image, gets a preview from
> the server and confirms that this is the right image ?

Automation. The image is instantly loaded and displayed within literally 0.1
seconds, while the user types. It's "fun". Images are often 500k or larger and
that doesn't upload to the server very quickly.
> 
> And this bug is also invalid because such a discussion belongs a) in the bug
> itself or better b) in the newsgroups or c) with the developer who fixed that

Someone suggested I post a new "bug" because posting to the other one caused
about 100 people to be e-mailed, and the bug was several years old so many of
them don't care to hear about it anymore.

Comment 5

[Jon Hall]

fwiw, I totally agree with you here Ed. Off the top of my head there are 3 or 4
much better ways to have addresses bug 69070. 

However, I came to the realization a long time ago that web applications are a
foreign concept to the decision makers at mozilla.org. Just make your web app
IE/Opera/Safari only...sooner or later some user will come along and make a bug
about the app not working in Firefox.

Comment 6

[Matthias Versen [:Matti]]

Jon: we've got alread a few bugs because Mozilla doesn't allow it to to link to
local files from http://. Theay are fast resolved as invalid.
And BTW: Opera does the same last I checked.

You can do many things with IE, that's also the reason why it's unsecure and I`m
happy that this hole in Mozilla got fixed after a very long time.

Comment 7

[Ed Resnick]

(In reply to comment #6)
> Jon: we've got alread a few bugs because Mozilla doesn't allow it to to link to
> local files from http://. Theay are fast resolved as invalid.
Yeah, by YOU. :)

> And BTW: Opera does the same last I checked.
I'm not concerned with Opera. Mozilla is better, and far more popular.

Please, Matti, give me examples where my idea can compromise security.

Comment 8

[Emil Tamas]

I am using this functionality to display preview images in a virtual tour
management system, it's a VERY important feature of the system because the user
can drag and move the panels with the preview images and then submit the virtual
tour.It's breaking the whole concept of the application and I think many apps
will have their functionality affected by this. In this case *****I'M LUCKY****
as a developer because the target users are using IE as the main browser (98%)
but for me is a critical accesibility issue as I want the app to work on the 2
main browsers :IE & FX. I'm not just an isolate example, many image gallery apps
are using this "rare used functionality".
Greetings,
Emil Tamas

Comment 9

[Matthias Versen [:Matti]]

>Please, Matti, give me examples where my idea can compromise security.

This single thing isn't itself a security hole but it could be one combined with
another security hole.
And this also leads to DOS attacks and it of course is a privacy problem.

Read all the older dupes in bug 69070 for example.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

*** Bug 269738 has been marked as a duplicate of this bug. ***