404451 - Sample exploit for Bug 404391

Status: VERIFIED FIXED

(Core :: Security, defect)

Description

[Gregory Fleischer]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Bug #404391 describes a condition in which the focus can be set to the text portion of a File input element.

Labels are associated with an input element in one of two ways:
1) using the 'for' attribute
2) as the first child input element of the label element

The fix for #388784 added logic that set the focus to the browse button instead of the input field when the user called Focus().  That was triggered because the focus of the label element was being applied File input element.

The layout in #404391 adds a Text input element as a child of the label.  When the Text input element receives the focus, the Label in turn sets the focus to File input element.  The logic in the fix for #388784 is not tripped because Focus() is not being called in this case.

Although the bug describes typing in the Text field, a mouse click appears necessary to set the focus.  Programmatically setting the focus does not appear possible.
 
Once the File input field has the focus, selective capture of keystrokes can be used to construct a file path to upload a file without user permission.


Reproducible: Always




User agents found vulnerable:

 - Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
 - Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.10pre) Gecko/20071119 BonEcho/2.0.0.10pre
 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.10pre) Gecko/20071119 BonEcho/2.0.0.10pre

Comment 1

[Gregory Fleischer]

Attachment: Sample file stealing exploit for bug 404391

Sample file stealing exploit for bug 404391.

Comment 2

[Gregory Fleischer]

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

Comment 3

[Gregory Fleischer]

The demo is standalone.  But by unchecking the "Standalone demo?" box, it can be made to submit the file.  A suitable "upload.cgi" Perl script is included.

The sample exploit is extremely crude.  It works by placing the File input and Textarea inside of a Label.   When the user selects the Textarea, the File text entry gets the focus and never lets go.  The File element is way placed way out of the visible scree.  As the user types, keystrokes are examined and if the character is the next in the needed path it is added.  Otherwise, the keypress is canceled.  In any case, the character is added to the Textarea. 

This version contains a number of glaring deficiencies.  There is not support for the backspace, delete key or arrow keys (among others).  These keystrokes should be able to be implemented.

Also, my fake cursor is pretty lame.  But with a more stylized font and page layout that may not be as noticeable.

The selection of text, cutting and pasting of that text would be more challenging.  It basically requires implementing your own caret handling in the textarea.  By using absolute position, capture of mouse events and selection ranges this may be possible.  

But, implementing all of these may not be necessary depending on the type of application that is used as vector.  For example, in an interactive chat page most of the text is keyboard entered, forward moving and submitting via XMLHttpRequest.  The hooked File input element can wait patiently and then post once the necessary keystrokes are captured.

Comment 4

[Mike Schroepfer]

DVeditz/Jesse can you suggest blockign and priority status based on exploit severity?

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Bug 405299 has a patch which fixes this one too.

Comment 6

[Daniel Veditz [:dveditz]]

Looks like Olli patched this in bug 405299 rather than the other way around -- we'll have to test when it lands to make sure.

Comment 7

[Martijn Wargers (dead)]

It seems to me this is now fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12pre) Gecko/20071231 BonEcho/2.0.0.12pre
I don't get the "c:\boot.ini" result anymore in the green div with that build.

Comment 8

[Daniel Veditz [:dveditz]]

fixed in bug 405299

Comment 9

[Al Billings [:abillings - ex-MoCo]]

Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.12pre) Gecko/2008011803 BonEcho/2.0.0.12pre. 

Comment 10

[Al Billings [:abillings - ex-MoCo]]

This is branch only?

Comment 11

[Martijn Wargers (dead)]

Yes, because of bug 258875, this shouldn't be possible on trunk, I believe.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Right, this is branch only.

Comment 13

[Al Billings [:abillings - ex-MoCo]]

Marking verified then.