Closed
Bug 88153
Opened 23 years ago
Closed 23 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•23 years ago
|
||
Reporter | ||
Comment 2•23 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•23 years ago
|
||
methinks Mr Kritzer might be the more appropriate QA person for this. [chris, punt as needed.]
QA Contact: sairuh → ckritzer
Comment 4•23 years ago
|
||
thx, bradley --my eye utterly skipped over the nscp conf droplist selection. time for me to go to bed. :)
Reporter | ||
Comment 5•23 years ago
|
||
se: :) blake can't either. I sent him mail though.
Comment 7•23 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•23 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•23 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•23 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•23 years ago
|
||
Assignee | ||
Comment 12•23 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•23 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•23 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•23 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•23 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•23 years ago
|
||
Assignee | ||
Comment 18•23 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•23 years ago
|
||
r=mstoltz.
Comment 20•23 years ago
|
||
sr=blake
Assignee | ||
Updated•23 years ago
|
Whiteboard: pdt+
Assignee | ||
Comment 21•23 years ago
|
||
Comment 22•23 years ago
|
||
Checked in on trunk and branch.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 23•23 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•20 years ago
|
||
Does this bug still need to be Netscape (!) confidential?
Comment 25•20 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•20 years ago
|
Group: security
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•