950173 - moz-icon:file:// may be accessed over HTTP, leading to directory / drive enumeration with interaction

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[Jordan Milne]

Attachment: A PoC showing the different icons that are displayed depending on the path and whether or not it exists.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

Steps to reproduce:

1) Create a page containing <img src="moz-icon:file:///" />
2) Serve the page over HTTP
3) View the page in Firefox


Actual results:

On Windows: Explorer's icon for C: is displayed
On Linux: The theme's folder icon is displayed

In most themes the icon for existing directories is distinct from the icon for unknown files, so an attacker can test for a directory's existence via user interaction.

Additionally, on Windows the <img>'s error event will trigger when referencing a non-existent drive (e.g. "moz-icon:file:///L:/" ) without user interaction, giving an attacker a list of valid drives as well as whether a drive was connected while the user was on the page.

Paths to files do not generally leak existence info, as if the file does not exist, the file extension is used to choose the icon. file: URLs with UNC paths seem to be similarly unaffected as they don't display any icon at all.


Expected results:

The broken file icon should be displayed, consistent with <img>s referencing the file scheme when served over HTTP.

Comment 1

[Jordan Milne]

Attachment: Windows Drive Enumeration PoC

Add a PoC that demonstrates abuse of <img src="moz-icon:file://DRIVELETTER/" onerror="notConnected()" /> on Windows

Comment 2

[Jordan Milne]

Attachment: A PoC that demonstrates how an attacker may abuse differing icons for existing / non-existent directories

Sets highly stretched icons as the background of squares, so only the color of the centermost pixel is visible. Then asks users to click squares that have the same color as directories under the guise of a CAPTCHA. Depends on the "unknown filetype" and "folder" icons having distinct colors in the center pixel, but it works with the Tango icon set as well as Windows 7. 

Partially inspired by http://lcamtuf.blogspot.com/2013/05/some-harmless-old-fashioned-fun-with-css.html .

Comment 3

[Boris Zbarsky [:bzbarsky]]

Can we just kill off untrusted access to moz-icon altogether?

Or make moz-icon:file:// use a different scheme with different permission bits?

Comment 4

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Boris Zbarsky [:bz] from comment #3)
> Can we just kill off untrusted access to moz-icon altogether?

+1.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I mean, we'd need to replace it with something else for file:// and especially ftp:// directory listing rendering.  But other than that, there are no valid uses I know of.

Comment 6

[Jordan Milne]

Looks like this stopped reproing in FF 43. Not sure what changed between 42 and 43, but it should be fine to mark as resolved if the vector hasn't just changed.

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

OK, let's reopen if there are indications it's still around.