Closed
Bug 88153
Opened 24 years ago
Closed 24 years ago
page info allows untrusted content to run as chrome
Categories
(SeaMonkey :: UI Design, defect, P2)
SeaMonkey
UI Design
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.3
People
(Reporter: bbaetz, Assigned: jruderman)
Details
(Whiteboard: pdt+)
Attachments
(4 files)
81 bytes,
text/html
|
Details | |
73 bytes,
text/html
|
Details | |
1.89 KB,
patch
|
Details | Diff | Splinter Review | |
1.88 KB,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 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.
Comment 3•24 years ago
|
||
methinks Mr Kritzer might be the more appropriate QA person for this. [chris,
punt as needed.]
QA Contact: sairuh → ckritzer
Comment 4•24 years ago
|
||
thx, bradley --my eye utterly skipped over the nscp conf droplist selection.
time for me to go to bed. :)
Reporter | ||
Comment 5•24 years ago
|
||
se: :) blake can't either. I sent him mail though.
Comment 7•24 years ago
|
||
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•24 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•24 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•24 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.
-Kritzer
Assignee | ||
Comment 11•24 years ago
|
||
Assignee | ||
Comment 12•24 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•24 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.
Reporter | ||
Comment 14•24 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.
Assignee | ||
Comment 15•24 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
Assignee | ||
Comment 16•24 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.
Assignee | ||
Comment 17•24 years ago
|
||
Assignee | ||
Comment 18•24 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 19•24 years ago
|
||
r=mstoltz.
Comment 20•24 years ago
|
||
sr=blake
Assignee | ||
Updated•24 years ago
|
Whiteboard: pdt+
Assignee | ||
Comment 21•24 years ago
|
||
Comment 22•24 years ago
|
||
Checked in on trunk and branch.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 23•24 years ago
|
||
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
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 24•21 years ago
|
||
Does this bug still need to be Netscape (!) confidential?
Comment 25•21 years ago
|
||
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
Updated•21 years ago
|
Group: security
Updated•21 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•