Closed Bug 349769 Opened 13 years ago Closed 13 years ago

[FIX]Changes for bug 348672 make blank tabs chrome documents

Categories

(Core :: DOM: Core & HTML, defect, P1, critical)

x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla1.9alpha1

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

Details

(Keywords: qawanted, regression, Whiteboard: [sg:moderate] post 1.8)

Attachments

(2 files)

Which is not so great.  We don't want to inherit our current principal in these cases.

I'll post what I think is the right patch.
Priority: -- → P1
Target Milestone: --- → mozilla1.9alpha
Attached patch FixSplinter Review
Attachment #234995 - Flags: superreview?(jst)
Attachment #234995 - Flags: review?(jst)
Comment on attachment 234995 [details] [diff] [review]
Fix

r+sr=jst
Attachment #234995 - Flags: superreview?(jst)
Attachment #234995 - Flags: superreview+
Attachment #234995 - Flags: review?(jst)
Attachment #234995 - Flags: review+
Fixed.
Group: security
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
qawanted: please add a regression test to make sure this one stays fixed.

Boris: when you say blank tabs do you mean only tabs the user has manually opened (ctrl-t, menu), or also w=open("about:blank") when new windows are set to open in new tabs? I'm assuming not the latter because the point of bug 332182 was to make sure the principal in that case matched the opener. I think that means there's no practical danger here--an attacker would have to convince the user to paste a javascript: url into the location bar of such a tab.
Keywords: qawanted, regression
Whiteboard: [sg:moderate] post 1.8
I'm not sure how to test this. I tried a 2006081804 build which should show this bug. Using either the urlbar or Jesse's shell, I was not able to access Components.classes or to call  netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect '); without the permission dialog firing.
Flags: in-testsuite?
> Boris: when you say blank tabs do you mean only tabs the user has manually
> opened (ctrl-t, menu), or also w=open("about:blank")

The former yes.  The latter, only briefly during the actual open() call -- between when we create the tab and when we stamp the caller principal on it.  I agree that content never has access to these chrome tabs.  In addition to cut/paste, there is also drag and drop, fwiw.  But yeah, this would not have been trivial to exploit.

> I tried a 2006081804 build which should show this bug.

Actually, no.  A 2006-08-19 build should show this bug.  The bug was introduced at 2006-08-18-19:43 or so.

It should be pretty easy to test this with davel's jssh stuff; lemme know if you want me to write up such a testcase.
(In reply to comment #6)

> Actually, no.  A 2006-08-19 build should show this bug.  The bug was introduced
> at 2006-08-18-19:43 or so.

Ok, 2006081901 you can access Components.classes in a blank page easily.
> 
> It should be pretty easy to test this with davel's jssh stuff; lemme know if
> you want me to write up such a testcase.
> 
If davel has a place for it that would be fine.

Initial testing is a home page set to about:blank and new blank tabs show the issue but not window.open('') or window.open('about:blank'). Does that match what you see? I'm not clear on the d&d case.
Yeah, that matches what I see.  D&D is just a way to load a URI in a blank tab; if it's a javascript: URI it executes with the tab's current permissions.
(In reply to comment #8)

Oh, ok. The exploit part. ;-) All I need to is get Components.classes and I'm golden. It would be nice to see a jssh version though.
Looks like I was wrong about jssh; the problem is that if I actually set window.location I get the chrome principals, and the security manager and principal APIs are not scriptable enough for me to examine the sort of principal something has from script.  :(
Flags: wanted1.8.1.x-
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.