JavaScript Key Filtering Vulnerability

RESOLVED WORKSFORME

Status

()

Core
Event Handling
RESOLVED WORKSFORME
10 months ago
9 months ago

People

(Reporter: Dhiraj Mishra, Unassigned, NeedInfo)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 months ago
Created attachment 8836978 [details]
hide.html

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170213030206

Steps to reproduce:

Works for me in :
FF Nightly in windows 7 
FF Beta in Windows 7 

Steps to reproduce :
1. Open hide.html


Actual results:

Multiple web browsers are prone to a JavaScript key-filtering vulnerability because the browsers fail to securely handle keystroke input from users.
  
This issue is demonstrated to allow attackers to divert keystrokes from one input form in a webpage to a hidden file-upload dialog in the same page. This may allow remote attackers to initiate file uploads from unsuspecting users. Other attacks may also be possible.
  
Exploiting this issue requires that users manually type the full path of files that attackers wish to download. This may require substantial typing from targeted users, so attackers will likely use keyboard-based games, blogs, or other similar pages to entice users to enter the required keyboard input to exploit this issue.
Well, it seems that when focus is moved during keydown event propagation, we should mark the keydown event as consumed (then, following keypress event won't be fired).

However, it could cause some compatibility issue. For example, typing start in <body> may cause moving focus to an <input> element in some web apps like our Find As You Type. So, we should consume keydown only when it causes moving to <input type="file">?
Or, keydown event handler of <input type="file"> should set flag to following keypress events should be ignored when the keydown target was different element until next keydown event comes.  However, I've not found where is the handler of keypress event of <input type="file"> yet.
Hmm, I cannot reproduce this bug with FileReader. Additionally, even if I type full path on usual file upload form, I cannot upload the file. Do I misunderstand something your idea?

My understanding of your report is, Gecko can specify file by typing full path when an <input type="file"> has focus and the key input can be filtered with your idea.  However, I still don't confirm the first fact of these conditions. (And I don't find an event handler to make <input type="file"> work as so.)
Flags: needinfo?(mishra.dhiraj95)
(Reporter)

Comment 4

10 months ago
Okay, It failed for me as well with FileReader, however I request during the event propagation, we should mark the keydown event as consumed (then, following keypress event won't be fired). Comment1
(Reporter)

Updated

10 months ago
Flags: needinfo?(mishra.dhiraj95)
(In reply to Dhiraj Mishra from comment #4)
> Okay, It failed for me as well with FileReader, however I request during the
> event propagation, we should mark the keydown event as consumed (then,
> following keypress event won't be fired). Comment1

Yeah, but if we can type full path when an <input type="file"> has focus, attacker can set focus to hidden <input type="file"> always and emulate editor behavior with complicated script at "keydown" or "keypress". If so, comment 1's approach isn't enough to fix this bug. If so, <input type="file"> shouldn't allow to input full path from keyboard anytime or after a keypress event is consumed.
Flags: needinfo?(mishra.dhiraj95)
(Reporter)

Comment 6

10 months ago
If so, <input type="file"> shouldn't allow to input full path from keyboard anytime or after a keypress event is consumed.
My bad agreed WFM this might not be enough for the fix, however the comment 1 should have a fix.
Flags: needinfo?(mishra.dhiraj95)
So, my last question is, can you select a file with typing full path on an <input type="file"> and post it? I cannot reproduce it... For example, when I use image uploader, then,
1. Set focus to an <input type="file">
2. Type full path as Windows style on Win10.
3. Click submit button.
Then, no file will be uploaded. Can you check this?

I don't understand why this won't work like your testcase. I'll create actual testcase and upload to my web server tomorrow, though.
Flags: needinfo?(mishra.dhiraj95)
(Reporter)

Comment 8

10 months ago
Hi,by typing full path on an <input type="file"> i was not able to reproduce the issue in FF Nightly.
Yes ! it doesn't works like my test case.
Flags: needinfo?(mishra.dhiraj95)
Hmm, I still cannot reproduce this report. Here is actual testcase which reported at comment 0.
http://d-toybox.com/mozilla/test/keypress-filter-on-file-input.html
# I changed enctype of <form> and the path of victim to C:\UPLOAD.TXT.

When I test it, I see UPLOAD_ERR_NO_FILE error of PHP. Do you reproduce with this testcase? Or something different from when you found this bug?
Flags: needinfo?(mishra.dhiraj95)
(Reporter)

Comment 10

10 months ago
Apparently some how the test case is same while I to got an error.
Flags: needinfo?(mishra.dhiraj95)
Hmm, can you provide another testcase? (the php file in my server is available from outside the sever, if you need to use it, feel free to use it.)
Flags: needinfo?(mishra.dhiraj95)
(Reporter)

Comment 12

10 months ago
In this testcase after 2 3 attempts i didnt got any error while uploading a file.
http://d-toybox.com/mozilla/test/keypress-filter-on-file-input.html
Flags: needinfo?(mishra.dhiraj95)
(In reply to Dhiraj Mishra from comment #12)
> In this testcase after 2 3 attempts i didnt got any error while uploading a
> file.
> http://d-toybox.com/mozilla/test/keypress-filter-on-file-input.html

Oh, really? Hmm...

Smaug, do you know where we handle keyboard events of <input type="file"> or somebody who is familiar with around this?
Flags: needinfo?(bugs)
I don't understand the testcase.
What are the exact steps to reproduce? And when am I seeing some bug?

If we're about to upload a file, using FormData in the test should be able to tell that. Should make 
testing easier. (but I don't see how the testcase would lead to that.)
Flags: needinfo?(bugs)
(In reply to Olli Pettay [:smaug] (pto-ish for couple of days) from comment #14)
> I don't understand the testcase.
> What are the exact steps to reproduce? And when am I seeing some bug?

I understand this as <input type="file">'s value may be set by typing a full path. However, I still don't reproduce such case nor find such code in Gecko.

> If we're about to upload a file, using FormData in the test should be able
> to tell that. Should make 
> testing easier. (but I don't see how the testcase would lead to that.)

Thanks. First, I tried to check it with FileReader, but because not reproducible, I retried with the simplest case (i.e., using normal post and checking on server side). However, I still don't reproduce it yet...

Updated

10 months ago
Group: firefox-core-security → dom-core-security
Component: Untriaged → Event Handling
Product: Firefox → Core
(In reply to Masayuki Nakano [:masayuki] from comment #15)
> (In reply to Olli Pettay [:smaug] (pto-ish for couple of days) from comment
> #14)
> > I don't understand the testcase.
> > What are the exact steps to reproduce? And when am I seeing some bug?
> 
> I understand this as <input type="file">'s value may be set by typing a full
> path. However, I still don't reproduce such case nor find such code in Gecko.
Right, I thought the issue is about that, but I'm not aware of us having any code letting one to do that.
Nor can I reproduce the issue.

Reporter, we need some help here.
Could you provide exact steps to reproduce?
Flags: needinfo?(mishra.dhiraj95)
This is the same test case as: http://seclists.org/fulldisclosure/2006/Jun/140
which was reported in bug 290478.
(Reporter)

Comment 18

10 months ago
Hi andrew, Yes its the same test case as mention above was not aware its already reported 290478.
Flags: needinfo?(mishra.dhiraj95)
Dhiraj Mishra: See comment 16, please let us know exact steps to reproduce this bug.
Flags: needinfo?(mishra.dhiraj95)
(Reporter)

Comment 20

10 months ago
Hey Masayuki, 
To divert keystrokes from one input form in a webpage to a hidden file-upload dialog in the same page. This may allow remote attackers to initiate file uploads from unsuspecting users. Other attacks may also be possible.

I may not abe to explain well but its similar to Bug ID : 56236
Flags: needinfo?(mishra.dhiraj95)
So, my question is, how did you confirm the bug? We need definite steps to reproduce but we don't reproduce it with your testcase yet. Do you have another testcase or specific steps for the attached testcase?

# Although, if we find event handler which handles keyboard events like editor, we would be able to find the issue, I don't find such event handler yet.
Flags: needinfo?(mishra.dhiraj95)
(Reporter)

Comment 22

10 months ago
I am trying to make an another testcase but so far not able to make in better way, for now i request please use the above testcase however for now i don't have any specific attack scenario for this issue. 

The above testcase made by you probably worked for me there was no error in uploading the file.
Flags: needinfo?(mishra.dhiraj95)
(In reply to Dhiraj Mishra from comment #22)
> The above testcase made by you probably worked for me there was no error in
> uploading the file.

Yeah, but as you see, the HTML isn't modified except method of <form> element and the file path to steal. They shouldn't break your testcase because the former is necessary to upload files and the latter is necessary for attackers.

If you don't have any ideas to reproduce this with FileReader or on your own server, I think that we should mark this as WORKSFORME and reopen this or file another bug when you find the bug.

dveditz: What do we usually do in this case?
Flags: needinfo?(dveditz)
Group: dom-core-security
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.