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

RESOLVED DUPLICATE of bug 258875

Status

()

P3
normal
RESOLVED DUPLICATE of bug 258875
18 years ago
6 years ago

People

(Reporter: jruderman, Assigned: dveditz)

Tracking

({csectype-spoof, sec-high})

Trunk
Future
x86
Windows 98
csectype-spoof, sec-high
Points:
---
Bug Flags:
blocking1.7 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Patch in bug 258875)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
Created attachment 16863 [details]
demonstration
(Reporter)

Updated

18 years ago
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?
(Reporter)

Comment 5

18 years ago
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.

Updated

18 years ago
QA Contact: czhang → junruh

Comment 6

18 years ago
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

Comment 9

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

(Reporter)

Comment 10

15 years ago
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+
(Reporter)

Updated

15 years ago
Flags: blocking1.7?

Comment 11

15 years ago
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

Updated

15 years ago
Flags: blocking1.8a1?
(Assignee)

Updated

15 years ago
Whiteboard: [sg:fix]
(Assignee)

Comment 13

14 years ago
*** Bug 290478 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

14 years ago
Whiteboard: [sg:fix] → [sg:fix] Patch in bug 258875
(Reporter)

Comment 14

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

Comment 15

14 years ago
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?
(Reporter)

Comment 16

14 years ago
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.
(Reporter)

Updated

13 years ago
Whiteboard: [sg:fix] Patch in bug 258875 → [sg:high] Patch in bug 258875
(Reporter)

Comment 17

13 years ago
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
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
(Reporter)

Updated

12 years ago
Duplicate of this bug: 370092
(Reporter)

Updated

6 years ago
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.