Closed
Bug 388784
(CVE-2007-3511)
Opened 17 years ago
Closed 17 years ago
Firefox file input focus stealing vulnerability
Categories
(Core :: Layout: Form Controls, defect)
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)
1.23 KB,
text/html
|
Details | |
1.84 KB,
text/html
|
Details | |
1.98 KB,
text/html
|
Details | |
3.38 KB,
patch
|
jst
:
review+
sicking
:
superreview+
dveditz
:
approval1.8.1.8+
asac
:
approval1.8.0.next+
|
Details | Diff | Splinter Review |
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•17 years ago
|
||
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•17 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•17 years ago
|
Flags: blocking1.8.1.8?
Comment 3•17 years ago
|
||
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]
Updated•17 years ago
|
Flags: wanted1.8.1.x+
Version: unspecified → 1.8 Branch
Assignee | ||
Comment 4•17 years ago
|
||
Assignee | ||
Comment 5•17 years ago
|
||
This is a bit ugly, but should work. Basically relies on the fix for bug 370092.
Attachment #282448 -
Flags: review?(jst)
Assignee | ||
Comment 6•17 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•17 years ago
|
||
Test clicking button and also clicking label.
Assignee | ||
Comment 8•17 years ago
|
||
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•17 years ago
|
Attachment #282455 -
Flags: review?(jst) → review+
Assignee | ||
Comment 9•17 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)
Updated•17 years ago
|
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•17 years ago
|
Attachment #282455 -
Flags: approval1.8.1.8?
Comment 11•17 years ago
|
||
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+
Updated•17 years ago
|
Whiteboard: [sg:high] → [sg:high] need branch landing
Assignee | ||
Updated•17 years ago
|
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: fixed1.8.1.8
Resolution: --- → FIXED
Whiteboard: [sg:high] need branch landing → [sg:high]
Comment 12•17 years ago
|
||
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
Comment 13•17 years ago
|
||
(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
Updated•17 years ago
|
Whiteboard: [sg:high] → [sg:moderate]
Comment 14•17 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•17 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•17 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•17 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•16 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+
You need to log in
before you can comment on or make changes to this bug.
Description
•