88153 - page info allows untrusted content to run as chrome

Status: VERIFIED FIXED

Description

[Bradley Baetz (:bbaetz)]

To reproduce:

1. Open the attached page
2. View->Page Info->Images
3. Click on the image

This 'loads' the url, which in this case causes an alert to popup, referencing
Components.classes. This object only exists from a privilaged context,
indicating that we're running as chrome.

Comment 1

[Bradley Baetz (:bbaetz)]

Created attachment 40417 [details]
exploit

Comment 2

[Bradley Baetz (:bbaetz)]

sairuh: db48x can't see this bug, because its secure (we _so_ need to fix the
secure == nsconf assumption we make, soon)

ccing lisa and asa, which I should have done earlier. My bad.

Comment 3

[sairuh (rarely reading bugmail)]

methinks Mr Kritzer might be the more appropriate QA person for this. [chris,
punt as needed.]

Comment 4

[sairuh (rarely reading bugmail)]

thx, bradley --my eye utterly skipped over the nscp conf droplist selection.
time for me to go to bed. :)

Comment 5

[Bradley Baetz (:bbaetz)]

se: :) blake can't either. I sent him mail though.

Comment 6

[lchiang]

mstoltz: what do you think of this bug as a security rtm stopper?

Comment 7

[ckritzer (gone)]

Cool.

lchiang: mstoltz is out of the office this week.  cc'ing dbradley for some
assistance...

dbradley: could you give us your assessment with regards to Components.classes?
 The testcase for Components.classes (no privs granted) @
http://voodoolady.mcom.com/security/accept/auxp001.html would indicate that this
js popup is bad news.
se: happy to look into it

Comment 8

[ckritzer (gone)]

bbaetz, I'm upgrading the OS & Platform to ALL/ALL, as I can repro this on Win98
(and I suspect it's an xp problem) - will verify on MacOS next... If you
disagree, please notate - ckritzer

Comment 9

[David Bradley]

I suspect the image stuff is getting executed from a moz component, thus will
have access to Component.classes. (I'm still rather green at this). That's why
your test case fails, while this works. If you type the same thing in at the
URL, it doesn't execute. So this appears to be localized to this dialog or
similiar dialogs.

So bottom line, is I think how ever this img src tag is executed in this dialog,
it needs to be executed in the same way as any URL or img src tag in the HTML. I
think xpconnect and security are doing the right thing for the context this code
is executed in.

I don't feel I have enough experience to state whether this is a show stopper
for RTM or not.

Comment 10

[ckritzer (gone)]

Thanks for the info Dave!

I've checked this out on the branch bits for MacOS 2001-06-28-08-0.9.2, and it
is an XP bug.  FYI.

-Kritzer

Comment 11

[Jesse Ruderman]

Created attachment 40584 [details]
similar exploit (uses data: instead of javascript:)

Comment 12

[Jesse Ruderman]

Is it possible for chrome to create a document using data: or document.write
without giving that document chrome privileges?  If so, this bug could be fixed
by having page info create a document containing just an <img> tag pointing to
the appropriate URL.

Comment 13

[lchiang]

Comments from clayton via email to me:

The root problem is that when Chrome creates a window, that window automatically
gets full security privileges.  We should have a way to build windows from
Chrome, without giving them privileges.  In this case, the privileged window can
be loaded with unsecure JavaScript (but that JavaScript cannot be executed - yet)

So much for the root problem, the symptom is a luring attack.  That is, the user
must be lured into going to the Images tab in the Page Info dialog box and then
lured into clicking on any raw JavaScript that appears there - that triggers
execution of the untrusted code with full privileges.  In general we don't try
to fix all luring attacks - we can't!  So I wouldn't call this a stop ship, but
I think we want it during Limbo phase.  Should not be too hard to fix at the
root cause, and the "real" fix is functionality we REALLY should have!

Have emailed nisheeth for nsbranch consideration.

Comment 14

[Bradley Baetz (:bbaetz)]

lchiang/clayton - I thought about that, and I think that we should have this
ability. The problem is that most chrome pages do need to do something (like
save changes to disk), which normal pages can't do. Page Info is basically the
only exception I can think of, so while it would help this specific case, I'm
not sure how much this would give us overall. If we could mark an iframe in XUL
as sandboxed, then that would probably work, though.

As well, javascript urls in <img src='javascript:foo();'> don't currently work.
Bugzilla's being painful at the moment, so I can't find the bug, but Jesse
pointed it out to me yesterday. It will work one day though.

We could take Jesse's fix (set the src on an <img> in the iframe, rather than
the iframe directly), until then, and comment in the jsurl bug that a fix for
that should not be checked in until this bug is revisited.

Its an ugly, horrible fix which will regress unnoticed at some point, but if it
comes down to a choice between that and nothing, I think that we should take
that, provided that this bug is left open, and possibly unrestricted, for a real
fix, blocking the other bug.

Comment 15

[Jesse Ruderman]

Setting src on an img tag might hit bug 70820 (can't change src on a broken
image dynamically).  I think that can be worked around by creating a new image
tag each time using DOM2.

Once bug 61019 is fixed, this security bug will probably regress.  If I fix this
bug using the <img> hack, I'll mention on bug 61019 that fixing that bug would
regress this bug.

Comment 16

[Jesse Ruderman]

In addition to what I said I'd do earlier, I also did two more things so that 
bug 61019 is less likely to regress this bug.

Added type="content" to the iframe.  This prevents the image source from 
getting a handle on the page info window using "parent".  I think it's also 
supposed to make selections show up, but we currently don't show selected 
images as being selected (bug 74029).

Set to src to about:blank each time you click on an image, instead of just 
replacing the image node.  This should prevent exploits like:
1. An image with a js: url creates an iframe at a URL with chrome privs, such 
as about:.
2. The image also sees to it that document.documentElement refers to the inner 
frame's document rather than the document containing the original image node.
3. The next image you click (in page info) gets set as the src of an image in 
the chrome iframe.
4. The src of the second image now has chrome privs.

Comment 17

[Jesse Ruderman]

Created attachment 41517 [details] [diff] [review]
fix v1

Comment 18

[Jesse Ruderman]

I didn't intend to remove the blank line at the end of pageInfo.js.  I'll fix
that before I check in.

Comment 19

[Mitchell Stoltz (not reading bugmail)]

r=mstoltz.

Comment 20

[Blake Ross]

sr=blake

Comment 21

[Jesse Ruderman]

Created attachment 41722 [details] [diff] [review]
fix v2 (just fixing a merge conflict)

Comment 22

[Mitchell Stoltz (not reading bugmail)]

Checked in on trunk and branch.

Comment 23

[ckritzer (gone)]

Marking VERIFIED FIXED on:
-MacOS91 2001-07-11-13-0.9.2
-LinRH62 2001-07-11-05-0.9.2
-Win98SE 2001-07-11-05-0.9.2

Comment 24

[Jesse Ruderman]

Does this bug still need to be Netscape (!) confidential?

Comment 25

[Daniel Veditz [:dveditz]]

No it doesn't, clearing. I don't think there are any open netscape conf bugs,
but no one has systematically purged the many closed ones.