Last Comment Bug 388784 - (CVE-2007-3511) Firefox file input focus stealing vulnerability
(CVE-2007-3511)
: Firefox file input focus stealing vulnerability
Status: RESOLVED FIXED
[sg:moderate]
: fixed1.8.0.15, verified1.8.1.8
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: 1.8 Branch
: x86 Linux
: -- normal (vote)
: ---
Assigned To: Olli Pettay [:smaug]
:
: Jet Villegas (:jet)
Mentors:
http://sla.ckers.org/forum/read.php?3...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-19 07:42 PDT by Josh Bressers
Modified: 2008-03-20 11:58 PDT (History)
10 users (show)
dveditz: blocking1.8.1.8+
dveditz: wanted1.8.1.x+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Proof of concept HTML (1.23 KB, text/html)
2007-07-19 07:42 PDT, Josh Bressers
no flags Details
some more tests (1.84 KB, text/html)
2007-09-26 12:38 PDT, Olli Pettay [:smaug]
no flags Details
possible patch (1.62 KB, patch)
2007-09-26 12:42 PDT, Olli Pettay [:smaug]
no flags Details | Diff | Splinter Review
test also <label> for <input type="file"> (1.98 KB, text/html)
2007-09-26 13:19 PDT, Olli Pettay [:smaug]
no flags Details
proposed patch (3.38 KB, patch)
2007-09-26 13:30 PDT, Olli Pettay [:smaug]
jst: review+
jonas: superreview+
dveditz: approval1.8.1.8+
asac: approval1.8.0.next+
Details | Diff | Splinter Review

Description Josh Bressers 2007-07-19 07:42:39 PDT
Created attachment 272969 [details]
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: gavin@gavinsharp.com] 2007-07-19 15:36:49 PDT
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 2007-09-17 21:45:47 PDT
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] 2007-09-26 11:08:30 PDT
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] 2007-09-26 12:38:39 PDT
Created attachment 282446 [details]
some more tests
Comment 5 Olli Pettay [:smaug] 2007-09-26 12:42:03 PDT
Created attachment 282448 [details] [diff] [review]
possible patch

This is a bit ugly, but should work. Basically relies on the fix for bug 370092.
Comment 6 Olli Pettay [:smaug] 2007-09-26 12:57:58 PDT
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] 2007-09-26 13:19:37 PDT
Created attachment 282451 [details]
test also <label> for <input type="file">

Test clicking button and also clicking label.
Comment 8 Olli Pettay [:smaug] 2007-09-26 13:30:02 PDT
Created attachment 282455 [details] [diff] [review]
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] 2007-09-26 23:26:39 PDT
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 2007-10-01 16:25:06 PDT
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] 2007-10-02 10:38:33 PDT
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] 2007-10-12 15:56:15 PDT
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] 2007-10-17 10:52:17 PDT
(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 2007-11-19 09:45:24 PST
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] 2007-11-19 09:51:37 PST
(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 2007-11-19 09:54:12 PST
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] 2007-11-19 10:14:17 PST
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 2008-02-28 07:05:32 PST
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) 2008-03-20 11:58:07 PDT
Fix committed to 1.8.0

Note You need to log in before you can comment on or make changes to this bug.