404391 - Firefox input and file focus stealing through label

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[tha featurizer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

It's possible to set focus on a file field if a file field and a text field are both embedded into a single label. Result is that the focus of the textfield gets transfered to the file field, which can result in uploading sensitive files from a users PC.

Reproducible: Always

Steps to Reproduce:
1. goto http://www.0x000000.com/index.php?i=479
2. copy/paste in html file
3. run, type into the text field.
Actual Results:  
focus is set on the file field.

Expected Results:  
focus remaining on the text field.

Comment 1

[tha featurizer]

Attachment: example

Comment 2

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

What's the exploit? It's already known that it's possible to manually focus the input in an <input type=file> on the branch (you don't need any fancy tricks, users can just tab to it). The previous problems were mainly related to programmatically changing focus as the user types to mislead them into typing something into the input, I'm not sure I see how this issue could be used to do that.

Comment 3

[tha featurizer]

*sigh* this does exactly the same.

of course it's possible to steal user typed data, no creative mind or what? Think about that for a while, I was kind enough not to release actual code to exploit it. I know about the previous issue, I found the same in MSIE, only differently.

Consider this the first and last post on Bugzilla with such stupid answers, waste of my time.

Comment 4

[Jesse Ruderman]

You can also obscure the "Browse..." button by covering it, making the file upload control look like a normal text field.  That's been known for a long time.  See bug 57770, for example.

There might be a bug here with how <label> interacts with multiple form fields, but it's not a security hole.

Comment 5

[Jesse Ruderman]

If you do have an exploit, please do file a new (security-sensitive) bug report with it, so we can know what you're talking about :)

Comment 6

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

(In reply to comment #3)
> *sigh* this does exactly the same.

Exactly the same as what? The previous exploits related to file inputs were based on masking the fact users were typing in filenames (e.g. by selectively changing focus, retargeting events, etc). I don't see a way to do that with this testcase; seems to me like it has the same effect as getting the user to press "tab".

You can call me stupid if you want, but my comment was a question, not an answer. I don't understand why you think this testcase is dangerous, and if you don't want to explain it to me that's up to you, I guess.

Comment 7

[Gregory Fleischer]

I couldn't tell if a sample exploit had already been submitted by the
original reporter, so I thought I would submit what I had.

Exploit example attached to bug 404451.

Comment 8

[Mike Schroepfer]

Gregory and tha featurizer - thanks for the info on this bug.  Given the data in bug 404451 I'm removing this bug from the blocking list and we'll evaluate bug 404451 separately.

Comment 9

[Daniel Veditz [:dveditz]]

Fixed on the 1.8 branch by bug 405299

Comment 10

[Samuel Sidler (old account; do not CC)]

This bug is verified by the verification in bug 404451 and bug 405299 which show sample exploits for this bug.

Also verified that this testcase now focuses the "Browse" button instead of the text field.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/2008012820 Firefox/2.0.0.12