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

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[Gregory Fleischer]

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

Comment 1

[Gregory Fleischer]

Attachment: Example of dynamic positioning of file input element

Comment 2

[Gregory Fleischer]

Attachment: Demo of how actual attack could be constructed

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.

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This doesn't work in Firefox 3 as key input is disabled for file controls.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

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?

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

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.)

Comment 8

[Gregory Fleischer]

Attachment: Example of dynamic position using extremely small file element

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.

Comment 9

[Gregory Fleischer]

(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. 

Comment 10

[Gregory Fleischer]

The fix in bug 413135 addresses this issue as well.

Comment 11

[Gregory Fleischer]

Attachment: Example attack using disabled property to selectively cancel keystrokes

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].

Comment 12

[Daniel Veditz [:dveditz]]

attachment 299567 [details] [diff] [review] in bug 413135 catches this one too. Branch only, so "fixed" unless I'm missing something.