388784 - (CVE-2007-3511) Firefox file input focus stealing vulnerability

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Josh Bressers]

Attachment: Proof of concept HTML

Initially a mostly vague flaw was reported to full-disclosure here:
http://archives.neohapsis.com/archives/fulldisclosure/2007-06/0646.html

It wasn't clear in the initial thread if this vulnerability could be used to actually do anything useful other than steal everything that a user types.  I did some investigation into this flaw and came up with a PoC that is able to selectively steal user keypresses.  I'm attaching the PoC.

I verified this with Firefox 2.0.0.5

Comment 1

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

This looks pretty similar to bug 370092. See also bug 56236.

I can't reproduce on the trunk, due to the fix for bug 258875.

Comment 2

[Gregory Fleischer]

I've created an online demo that shows more clearly how this security
vulnerability can be exploited.  User keystrokes are redirected from
the textarea to the file input element by associating a label with the
file input and capturing appropriate keydown, keyup and keypress events.

You can view the online demo here: http://pseudo-flaw.net/firefox-focus-bug

The following list of user agents were tested and found to be vulnerable:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.7pre) Gecko/20070917 BonEcho/2.0.0.7pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7pre) Gecko/20070917 BonEcho/2.0.0.7pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.7pre) Gecko/20070917 BonEcho/2.0.0.7pre
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)

Comment 3

[Daniel Veditz [:dveditz]]

Assigning to Smaug since he fixed similar bug 370092, but maybe it should be roc based on current trunk work?

Comment 4

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

Attachment: some more tests

Comment 5

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

Attachment: possible patch

This is a bit ugly, but should work. Basically relies on the fix for bug 370092.

Comment 6

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

Comment on attachment 282448 [details] [diff] [review]
possible patch

this would actually change the behavior when there is a <label> for <input type="file"> and user clicks <label>. I'll make a better patch.

Comment 7

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

Attachment: test also <label> for <input type="file">

Test clicking button and also clicking label.

Comment 8

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

Attachment: proposed patch

This is better. text field is still focused when user clicks the <label> for
<input type="file">, but if .focus() of the <label> is called, the 'browse...'
button of the <input type="file"> is focused.
Using NS_IMETHOD/nsresult in the method because those same are used in 
nsGenericHTMLElement.

Comment 9

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

Comment on attachment 282455 [details] [diff] [review]
proposed patch

For this kinds of bugs I'd really like to see separate r and sr, just to minimize risk for regressions.

Comment 10

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

Comment on attachment 282455 [details] [diff] [review]
proposed patch

Ideally I would like to go with as simple a solution as possible and always focus the browse-button. But this is ok too.

Comment 11

[Daniel Veditz [:dveditz]]

Comment on attachment 282455 [details] [diff] [review]
proposed patch

approved for 1.8.1.8, a=dveditz for release-drivers

Comment 12

[Daniel Veditz [:dveditz]]

verified 1.8.1.8

The testcase now triggers Quick-search when the user types '/'. I think this is OK since the attack script is creating key-events and directing them outside the text area. It's not a problem in normal pages, and if the user focuses on a random button and types '/' that's expected behavior.

Comment 13

[Daniel Veditz [:dveditz]]

(In reply to comment #0)
> Initially a mostly vague flaw was reported to full-disclosure here:

That f-d post was a poor echo of the original disclosure at
http://sla.ckers.org/forum/read.php?3,13142

> It wasn't clear in the initial thread if this vulnerability could be used to
> actually do anything useful other than steal everything that a user types.

The sla.ckers.org post was explicitly describing a way to work around the fix we put in place for bug 370092 in Firefox 2.0.0.4

Comment 14

[tha featurizer]

It's still possible:

http://www.0x000000.com/index.php?i=479

<form>
<label>
<input type="file" name="foo" />
<br>
<input type="text" name="bar"  />
</label>
</form>


Try to type in the textfield.

Comment 15

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

(In reply to comment #14)
> It's still possible:
> 
> http://www.0x000000.com/index.php?i=479
> 

Could you file a new bug for this new problem?

Comment 16

[tha featurizer]

Okay sorry, it's my first post here, I have to learn the "rules" and stuff, a bit confusing actually. So while it has to do with this bug, I still need to fill a new bug? I kinda have to get used to that though...

Comment 17

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

Well, it is not exactly the same bug.
And having separate bugs helps QA when verifying them fixed.
And btw, a minimal testcase attached using "Add an attachment" would be
great.

Comment 18

[Alexander Sack]

Comment on attachment 282455 [details] [diff] [review]
proposed patch

a=asac for 1.8.0.15

(this patch baked in distros for quite some time)

Comment 19

[Christopher Aillon (sabbatical, not receiving bugmail)]

Fix committed to 1.8.0