292774 - "View Image" context menu allows chrome access

Status: RESOLVED FIXED

(Firefox :: Menus, defect)

Description

[Michael Krax]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

The context menu option "View Image" does not validate the src of the image. The
image source URL is directly opened without checking if this may result in
chrome access. By using absolute positioning and the moz-opacity filter an
attacker can easily fool the user to think he is going to view a valid image.

While this isn't exploitable without being combined with other flaws, it can be
a significant stepstone for attacks. Beside cross site scripting exploits that
use the chrome page as the entry point for privilege elevation attacks, there
might be scripts in chrome that can be tricked into evaluating parts of the
calling url string. chrome://mozapps/content/extensions/extensions.xul is an
example for a page that uses location.search as part of their scripts - even
though i wasn't able to leverage this. 

Reproducible: Always

Steps to Reproduce:
1. Open http://bugzilla:[e-mail]/fireimaging/
2. Follow instructions

Comment 1

[Daniel Veditz [:dveditz]]

It'd be an easy fix since the fix for bug 69070 explicitly allows <img> to
reference chrome urls:
http://lxr.mozilla.org/mozilla/source/content/base/src/nsContentUtils.cpp#1821

We might want to disable View-image for broken images. In any case the
view-image code should do another checkLoadURI regardless of what we do with the
bug 69070 fix. Paranoia can't hurt and in this case is justified.

Comment 2

[Daniel Veditz [:dveditz]]

Changing the 69070 fix won't help: even if the load is denied the user can "View
Image" on the empty space. See with the blocked "file" image with the following
data url

data:text/html,<a%20href="chrome://browser/content/browser.xul">link</a><img%20src="chrome://browser/skin/Throbber.gif"><img%20src="file://c|/tmp/mozilla-16.png"><img%20src="http:/www.biiid.com/c|/tmp/mozilla-16.png">

Comment 3

[Boris Zbarsky [:bzbarsky]]

Changing the check in content utils would actually break various stuff (like
broken-image icons in webpages).

I think doing a checkLoadURI in the "view image" code is the way to go.  Also do
the same in "view only this frame" and any similar options we have in the
context menu.

Comment 4

[[e-mail]]

Attachment: xpfe view [background] image patch (checked in)

I don't (yet) think that "view only this frame" is similar - the frame and all
of its scripts etc. will already have been loaded.

Comment 5

[Michael Krax]

The demo page got updated to proof that this bug can actually be exploitet to
run arbitrary code in combination with popups and a cross site scripting bug.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 182566 [details] [diff] [review]
xpfe view [background] image patch (checked in)

Hmm.. I guess if a frame load is blocked by security the target.ownerDocument
will be about:blank, so viewing the frame will show nothing...

r=bzbarsky (note that this is seamonkey-only and should land on 1.7.8; Firefox
also needs a patch here...)

Comment 7

[Mike Connor [:mconnor]]

Attachment: firefox version of seamonkey patch (checked in)

should be sufficient, per bz's comment

Comment 8

[Johnny Stenback (:jst)]

Comment on attachment 186443 [details] [diff] [review]
firefox version of seamonkey patch (checked in)

sr=jst

Comment 9

[Daniel Veditz [:dveditz]]

Comment on attachment 182566 [details] [diff] [review]
xpfe view [background] image patch (checked in)

sr=dveditz
a=dveditz for aviary1.0.1 and moz1.7 branches and trunk

Comment 10

[Daniel Veditz [:dveditz]]

Comment on attachment 186443 [details] [diff] [review]
firefox version of seamonkey patch (checked in)

r=dveditz
a=dveditz for branches and trunk

Comment 11

[Mike Connor [:mconnor]]

Comment on attachment 182566 [details] [diff] [review]
xpfe view [background] image patch (checked in)

landed on trunk and 1.7.9 branch

Comment 12

[Mike Connor [:mconnor]]

Comment on attachment 186443 [details] [diff] [review]
firefox version of seamonkey patch (checked in)

landed on aviary 1.0.1 branch and trunk

Comment 13

[[e-mail]]

Damn, I forgot the trailing semicolons. How annoying :-[

Comment 14

[Jay Patel [:jay]]

v.fixed on aviary with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9)
Gecko/20050706 Firefox/1.0.5 using the mikx testcase.  If I enable popups, I
still get a small window, but nothing bad happens.  With popups disabled,
everything seems fine.

Comment 15

[Daniel Veditz [:dveditz]]

(In reply to comment #14)
> v.fixed on aviary with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9)
> Gecko/20050706 Firefox/1.0.5 using the mikx testcase.  If I enable popups, I
> still get a small window, but nothing bad happens.  With popups disabled,
> everything seems fine.

This testcase relies on view-source:javascript:eval(). The eval() part was only
useful starting in 1.0.3, and the view-source:javascript part was disabled in
1.0.4 by the fix for bug 290982.

Comment 16

[Daniel Veditz [:dveditz]]

Adding distributors

Comment 17

[Daniel Veditz [:dveditz]]

FF1.0.5 advisories published

Comment 18

[Lloyd D Budd]

Is this a particular MFSA ?

Comment 19

[Daniel Veditz [:dveditz]]

(In reply to comment #18)
> Is this a particular MFSA ?

We did not issue an advisory because the exploit was blocked by a fix in an
earlier version (which did get an advisory). What was ultimately fixed here was
the potential stepping stone to an exploit should another XSS bug be found.