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

RESOLVED DUPLICATE of bug 258875

Status

()

defect
P3
normal
RESOLVED DUPLICATE of bug 258875
19 years ago
6 years ago

People

(Reporter: jruderman, Assigned: dveditz)

Tracking

({csectype-spoof, sec-high})

Trunk
Future
x86
Windows 98
Points:
---
Bug Flags:
blocking1.7 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Patch in bug 258875)

Attachments

(1 attachment)

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.
Posted file demonstration
Summary: possible to selectively allow chars into file upload control by disablling control onkeydown → possible to selectively allow chars into file upload control by disabling control onkeydown
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.

Status: NEW → ASSIGNED
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.
ccing some more people. Tom, do you think this is something to worry about?
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.
QA Contact: czhang → junruh
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer
Mass changing milestone to Moz1.0 - stuff targeted for late spring/early summer.
Target Milestone: --- → mozilla1.0
Less important bugs retargeted to 0.9.9
Target Milestone: mozilla1.0 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.2
Target Milestone: mozilla1.2 → Future
The testcase doesn't seem to work in Mozilla 1.2a on Linux.

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+
Flags: blocking1.7?
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?
Flags: blocking1.8a?
Flags: blocking1.7?
Flags: blocking1.7-
Reassigning to dveditz, as I suspect chofmann meant to do...
Assignee: security-bugs → dveditz
Status: ASSIGNED → NEW
Flags: blocking1.8a1?
Whiteboard: [sg:fix]
*** Bug 290478 has been marked as a duplicate of this bug. ***
Whiteboard: [sg:fix] → [sg:fix] Patch in bug 258875
*** Bug 304480 has been marked as a duplicate of this bug. ***
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?
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.
Whiteboard: [sg:fix] Patch in bug 258875 → [sg:high] Patch in bug 258875
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 ***
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Duplicate of this bug: CVE-2006-2894
Keywords: csec-spoof, sec-high
Whiteboard: [sg:high] Patch in bug 258875 → Patch in bug 258875
You need to log in before you can comment on or make changes to this bug.