page info allows untrusted content to run as chrome

VERIFIED FIXED in mozilla0.9.3


18 years ago
7 years ago


(Reporter: bbaetz, Assigned: jruderman)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: pdt+)


(4 attachments)



18 years ago
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

18 years ago
Created attachment 40417 [details]

Comment 2

18 years ago
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.
methinks Mr Kritzer might be the more appropriate QA person for this. [chris,
punt as needed.]
QA Contact: sairuh → ckritzer
thx, bradley --my eye utterly skipped over the nscp conf droplist selection.
time for me to go to bed. :)

Comment 5

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

Comment 6

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

Comment 7

18 years ago

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

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

Comment 8

18 years ago
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
OS: Linux → All
Hardware: PC → All

Comment 9

18 years ago
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

18 years ago
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.


Comment 11

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

Comment 12

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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.
Assignee: blake → jesse
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3


18 years ago
Keywords: nsBranch

Comment 16

18 years ago
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

18 years ago
Created attachment 41517 [details] [diff] [review]
fix v1

Comment 18

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

Comment 20

17 years ago


17 years ago
Whiteboard: pdt+

Comment 21

17 years ago
Created attachment 41722 [details] [diff] [review]
fix v2 (just fixing a merge conflict)
Checked in on trunk and branch.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 23

17 years ago
-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

14 years ago
Does this bug still need to be Netscape (!) confidential?
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.
Group: netscapeconfidential → security
Group: security
Product: Core → Mozilla Application Suite


10 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.