81 bytes, text/html
73 bytes, text/html
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.
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. :)
se: :) blake can't either. I sent him mail though.
mstoltz: what do you think of this bug as a security rtm stopper?
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
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
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.
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
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.
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
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.
I didn't intend to remove the blank line at the end of pageInfo.js. I'll fix that before I check in.
Checked in on trunk and branch.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
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
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
You need to log in before you can comment on or make changes to this bug.