Closed Bug 388784 (CVE-2007-3511) Opened 14 years ago Closed 14 years ago

Firefox file input focus stealing vulnerability

Categories

(Core :: Layout: Form Controls, defect)

1.8 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: josh, Assigned: smaug)

References

()

Details

(Keywords: fixed1.8.0.15, verified1.8.1.8, Whiteboard: [sg:moderate])

Attachments

(4 files, 1 obsolete file)

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


Flags: blocking1.8.1.8?
Assigning to Smaug since he fixed similar bug 370092, but maybe it should be roc based on current trunk work?
Assignee: nobody → Olli.Pettay
Whiteboard: [sg:high]
Flags: wanted1.8.1.x+
Version: unspecified → 1.8 Branch
Attached patch possible patch (obsolete) — Splinter Review
This is a bit ugly, but should work. Basically relies on the fix for bug 370092.
Attachment #282448 - Flags: review?(jst)
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.
Attachment #282448 - Flags: review?(jst)
Test clicking button and also clicking label.
Attached patch proposed patchSplinter Review
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.
Attachment #282448 - Attachment is obsolete: true
Attachment #282455 - Flags: review?(jst)
Attachment #282455 - Flags: review?(jst) → review+
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.
Attachment #282455 - Flags: superreview?(jonas)
Flags: blocking1.8.1.8? → blocking1.8.1.8+
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.
Attachment #282455 - Flags: superreview?(jonas) → superreview+
Attachment #282455 - Flags: approval1.8.1.8?
Comment on attachment 282455 [details] [diff] [review]
proposed patch

approved for 1.8.1.8, a=dveditz for release-drivers
Attachment #282455 - Flags: approval1.8.1.8? → approval1.8.1.8+
Whiteboard: [sg:high] → [sg:high] need branch landing
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: fixed1.8.1.8
Resolution: --- → FIXED
Whiteboard: [sg:high] need branch landing → [sg:high]
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.
(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
Whiteboard: [sg:high] → [sg:moderate]
No longer depends on: 403090
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.
(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?
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...
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 on attachment 282455 [details] [diff] [review]
proposed patch

a=asac for 1.8.0.15

(this patch baked in distros for quite some time)
Attachment #282455 - Flags: approval1.8.0.15+
You need to log in before you can comment on or make changes to this bug.