Closed Bug 411236 Opened 13 years ago Closed 13 years ago

File upload input focus stealing: by dynamically positioning file input element, any user mouse click will set focus in file input

Categories

(Core :: Security, defect)

1.8 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: gfleischer+bugzilla, Assigned: sicking)

References

()

Details

(Keywords: fixed1.8.1.12, Whiteboard: [sg:moderate] 1.8-branch)

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

By tracking mousemove events, a file input element can be dynamically positioned so that it always is beneath the pointer.  Any user mouse click will set the focus in the file input text entry field.

Once the focus is set on the file element, any entered keystrokes can be
selectively captured and potentially used to upload arbitrary files from the
user.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.



Tested with user agents:

 - Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.11)
Gecko/20071127 Firefox/2.0.0.11
- Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.11) Gecko/20071127
Firefox/2.0.0.11
 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127
Firefox/2.0.0.11
- Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.12pre) Gecko/20080107 BonEcho/2.0.0.12pre
The file-input-floating-stealing.html file demonstrates how an actual attack could
be constructed.  On Mac OS X and Linux, "/etc/hosts" is targeted and on
Windows, "c:\boot.ini".  The JavaScript and image files are required for the
demo to function properly.

The demo is standalone by default, but the included 'upload.cgi' Perl CGI
script can be used to capture the submitted the file.
Assignee: nobody → dveditz
Product: Firefox → Core
QA Contact: firefox → toolkit
Attachment #295896 - Attachment mime type: application/zip → application/java-archive
Assignee: dveditz → jonas
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:moderate]
This doesn't work in Firefox 3 as key input is disabled for file controls.
Version: unspecified → 1.8 Branch
Whiteboard: [sg:moderate] → [sg:moderate] 1.8-branch
I don't see any way we can fix this without applying the same fix to the 1.8 branch as we have in 1.9. I.e. completely disable the ability to type a filename.

Is this attack prevented in any other browser? If so, how? I think safari for a long time has disabled the ability to type filenames.
The testcase doesn't seem to work properly with Opera, but at least some
keystrokes are 'stolen' and one can use opacity (not -moz-opacity) to hide
<input type="file">.
Does IE have similar problem too? I guess opacity doesn't work there, but
some kind of filter.

Would it be possible to force -moz-opacity:1 (and perhaps some other
css values) when input[type="file"]:focus?
I don't think we can stop anyone from hiding a file-input, there are just too many ways to do it. Two off the top of my head:

Cover up parts using positioned opaque divs
Clip away parts by placing inside a smaller div with overflow:hidden

I'm sure there are many more.
Yes, I was thinking those too, but still wondering if there was some way to force z-indexing/clipping etc.
 (Is this a dup of some other bug where all this has been discussed before.)
This example shows another possible approach of dynamically positioning the file input element.  The file input element is hidden until the mouse is over a link and is made extremely small so that it cannot be seen under the cursor.  Any mouse click will set the focus in the file input element.  The file picker button is obscured by a properly placed div.
(In reply to comment #7)
>
>  (Is this a dup of some other bug where all this has been discussed before.)
>

I don't believe this is a dupe.  

Bug 57770 and bug 258875 discuss related issues of styling file inputs to trick users into believing they are typing into a normal text box.  The premise being that the user thinks that they are typing the file path into a text box but it is really an upload control.  Although plausible, this is probably unlikely among a general audience.

This bug shows that it is possible for any user mouse click to set the focus by dynamically positioning the file input element.  The use opacity, sizing, overlays, clipping, etc. simply hides the fact the user is clicking in the file element.  The overall goal is to steal the focus.

Because once the focus has been stolen, any future text that the user enters can be selectively captured in the file input element.  If appropriate text can be captured, it can be used to steal arbitrary files.  Bug 56236, bug 290478, bug 304480, and bug 370092 (among many others) have discussions or demonstrations of this. 
The fix in bug 413135 addresses this issue as well.
Updated the example attack to use the disabled property to selectively cancel keystrokes.

This bypasses the fix for bug 413135 in attachment 298006 [details] [diff] [review].
Depends on: 413135
attachment 299567 [details] [diff] [review] in bug 413135 catches this one too. Branch only, so "fixed" unless I'm missing something.
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.12+
Keywords: fixed1.8.1.12
Resolution: --- → FIXED
Group: core-security
You need to log in before you can comment on or make changes to this bug.