Bug 388784 (CVE-2007-3511)

Firefox file input focus stealing vulnerability

RESOLVED FIXED

Status

()

Core
Layout: Form Controls
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: Josh Bressers, Assigned: smaug)

Tracking

({fixed1.8.0.15, verified1.8.1.8})

1.8 Branch
x86
Linux
fixed1.8.0.15, verified1.8.1.8
Points:
---
Bug Flags:
blocking1.8.1.8 +
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:moderate], URL)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
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
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

10 years ago
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)


Updated

10 years ago
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
(Assignee)

Comment 4

10 years ago
Created attachment 282446 [details]
some more tests
(Assignee)

Comment 5

10 years ago
Created attachment 282448 [details] [diff] [review]
possible patch

This is a bit ugly, but should work. Basically relies on the fix for bug 370092.
Attachment #282448 - Flags: review?(jst)
(Assignee)

Comment 6

10 years ago
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)
(Assignee)

Comment 7

10 years ago
Created attachment 282451 [details]
test also <label> for <input type="file">

Test clicking button and also clicking label.
(Assignee)

Comment 8

10 years ago
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.
Attachment #282448 - Attachment is obsolete: true
Attachment #282455 - Flags: review?(jst)

Updated

10 years ago
Attachment #282455 - Flags: review?(jst) → review+
(Assignee)

Comment 9

10 years ago
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+
(Assignee)

Updated

10 years ago
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
(Assignee)

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 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.
Keywords: fixed1.8.1.8 → verified1.8.1.8
(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]
Depends on: 403090

Updated

10 years ago
No longer depends on: 403090

Comment 14

10 years ago
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.
(Assignee)

Comment 15

10 years ago
(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

10 years ago
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...
(Assignee)

Comment 17

10 years ago
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

10 years ago
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+
Fix committed to 1.8.0
Keywords: fixed1.8.0.15
You need to log in before you can comment on or make changes to this bug.