56236 - possible to selectively allow chars into file upload control by disabling control onkeydown

Status: RESOLVED DUPLICATE of bug 258875

(Core :: Security, defect, P3)

Description

[Jesse Ruderman]

I can choose what characters typed into a input type="file" are accepted by 
looking at each character typed during onkeydown, and quickly disabling and re-
enabling the control if I want to reject a character.  (Mozilla is already much 
more secure than IE with these controls, btw.)

What's Mozilla's general strategy for file controls?  From what I can tell, 
it's "make it hard for css and javascript to do things to file controls".  This 
blocks most of the methods of attack I tried, but still doesn't guarantee that 
the user is aware that something is being uploaded.

Comment 1

[Jesse Ruderman]

Attachment: demonstration

Comment 2

[Mitchell Stoltz (not reading bugmail)]

I haven't really looked at the security of upload controls, other than the basic 

restriction on scripts that you mentioned, but I will give it a look.

Comment 3

[Mitchell Stoltz (not reading bugmail)]

Very clever. Looks like it would be hard to make a practical exploit, though.
Jesse, what's your feeling on how critical this is? ccing some people.

Comment 4

[Mitchell Stoltz (not reading bugmail)]

ccing some more people. Tom, do you think this is something to worry about?

Comment 5

[Jesse Ruderman]

I don't feel that this incarnation of the file upload control problem is 
critical for rtm, although I do think it could be exploited by a "porn site 
warning page".

Please examine bug 57770 for rtm, though.  My proposed fix for that bug would 
cover this bug.

Comment 6

[John Unruh]

Mass changing QA to ckritzer.

Comment 7

[Mitchell Stoltz (not reading bugmail)]

Mass changing milestone to Moz1.0 - stuff targeted for late spring/early summer.

Comment 8

[Mitchell Stoltz (not reading bugmail)]

Less important bugs retargeted to 0.9.9

Comment 9

[Tom Mraz]

The testcase doesn't seem to work in Mozilla 1.2a on Linux.

Comment 10

[Jesse Ruderman]

The testcase still demonstrates the hole using Mozilla/5.0 (Windows; U; Windows
NT 5.1; en-US; rv:1.6b) Gecko/20031108 Firebird/0.7+

Comment 11

[chris hofmann]

think we ought to go the route of restricting to the file picker and having a
pref for user turn off the read only behavior.   and try to do this for 1.8a(2).  

over to dan.

hyatt any chance of sharing what safari users think of being resticted to just a
file picker?

Comment 12

[Johnny Stenback (:jst)]

Reassigning to dveditz, as I suspect chofmann meant to do...

Comment 13

[Daniel Veditz [:dveditz]]

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

Comment 14

[Jesse Ruderman]

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

Comment 15

[Michael Krax]

Tell me your are joking. This hole is now open for almost five years?!

Despite the unquestionable low severity of this issue, this needs to be fixed 
with one of the next security releases. Since all kind of blogging and webbased 
applications are out there, entering large amounts of text into websites is a 
common behavior.

Can someone of the security team please explain while this has been kept open 
so long?

Comment 16

[Jesse Ruderman]

This will be fixed in Firefox 1.5 Beta -- see bug 258875.  Two reasons the fix
took so long are (1) other browsers are also vulnerable and (2) the only real
fix, not letting users edit the filename field directly, reduces usability in
the non-attack case.

Comment 17

[Jesse Ruderman]

I was wrong when I said "This will be fixed in Firefox 1.5 Beta".  It is fixed on trunk (for Firefox 3 at least), but it wasn't fixed in Firefox 1.5.0.0.

*** This bug has been marked as a duplicate of 258875 ***

Comment 18

[dex_sf]

This problem is currently getting publicity:

http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2006-06/msg00144.html
http://www.heise.de/newsticker/meldung/73933

Dex