411075 - File upload input focus stealing: focus can be set on text input element and remains following change to file type

Status: VERIFIED 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

The type of an input element can be dynamically changed using JavaScript.  The input element applies special logic to prevent dynamic changes from setting the value on file types.  No additional special handling is applied to whether the element is focused or not.

By setting the focus on a text input element and then changing the type to be file, the focus remains.  This is not initially evident, but following a modal event, the focus is reset to the file element.

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




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/20080106 BonEcho/2.0.0.12pre
- Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12pre)
Gecko/20080106 BonEcho/2.0.0.12pre

Comment 1

[Gregory Fleischer]

Attachment: Example of changing type of input element after setting focus

Comment 2

[Gregory Fleischer]

Attachment: Another example of changing input type using dispatched click event

Comment 3

[Gregory Fleischer]

Attachment: Demo of how actual attack could be constructed

The type-change-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 4

[:Gavin Sharp [email: [e-mail]]]

I'm nominating this bug (and the other similar bugs Gregory has filed) not because I think it should block, but because I think it should be wanted1.8.1.x, and I can't request that flag.

Comment 5

[Daniel Veditz [:dveditz]]

Gavin: I thought I fixed the requestability of the wanted flag. give it another try sometime.

I don't notice the two examples doing anything, but the demo works as advertised even after the fix for bug 405299

Comment 6

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

Oh, you could also simply move the file input to an area of the page that is outside the main viewport. This would add scrollbars, but that's hardly something that would stop the user from typing away.

Dan, is there any reason we couldn't simply disable typing on branch? Why didn't we do that when we did it on trunk?

Comment 7

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

(In reply to comment #6)
> Dan, is there any reason we couldn't simply disable typing on branch? Why
> didn't we do that when we did it on trunk?

Would that change break some accessibility code?
Though we may need that change anyway. Fixing all these file upload bugs is hard.
Would be ofc great to know how other browsers, which allow typing, are handling or are going to handle similar problems.

Comment 8

[Daniel Veditz [:dveditz]]

The fix in bug 413135 makes this attack ineffective on branch; trunk not affected.

Comment 9

[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 10

[Al Billings [:abillings - ex-MoCo]]

I have verified that with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.12) Gecko/2008012822 Firefox/2.0.0.12, the updated attack from Gregory still exploits the browser.

Comment 11

[Al Billings [:abillings - ex-MoCo]]

My bad. The test cause is counterintuitive. 

Olli and I just conferred and this is fixed. Re-resolving and verifying.