64539 - ftp dir listing can't give about:blank permission to access it

Status: RESOLVED WORKSFORME

(Core :: Security, defect, P3)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Go to ftp://ftp.mozilla.org.
2. javascript:void(window.open("about:blank").document.write("foo")) .
3. javascript:alert(opener.document) in the new window.

Result: NS_ERROR_DOM_PROP_ACCESS_DENIED on console.
Expected result: alert with "[object HTMLDocument]" or something similar.

This breaks my proptree bookmarklet 
<http://www.cs.hmc.edu/~jruderma/mozilla/proptree/> on ftp sites.

This doesn't happen with text files (such as README) served over ftp.  I don't 
know whether it happens with html files served over ftp.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Does this code work as expected on an http:// site?  There is a known problem
with Mozilla returning unedfined as a result of document.open() ....

Comment 2

[Jesse Ruderman]

Yes, the code works fine on http:// sites (at least for html files served over 
http).

Comment 3

[Mitchell Stoltz (not reading bugmail)]

The problem is that directory listing screens are chrome documents; they
actually have the system principal rather than the site's principal. I'm
guessing the bookmarklet is being given the site's principal, which is being
refused access. Maybe we can insert the correct principal...if that doesn't
break the directory listing.

Comment 4

[Mitchell Stoltz (not reading bugmail)]

Mass changing milestones to Moz0.9.1. Many of these bugs are dependent on the
XPConnected DOM and its associated security UI changes.

Comment 5

[Mitchell Stoltz (not reading bugmail)]

I don't think this is necessary for RTM, but the fact that directory listings are 
chrome URLs may cause other failures or exploits. Reassigning to Jesse for more 
exploration. Jesse, could you see if it's possible to run JS code in a directory 
listing page, or similar weirdness?

Comment 6

[Jesse Ruderman]

I'm not going to have much time to do Mozilla development this semester, so 
giving back to Mitch.

Comment 7

[Mitchell Stoltz (not reading bugmail)]

Future.

Comment 8

[Thomas]

I retried the 3 steps as documented in the description.
Step 1 works, Step 2 opens a second window "foo", Step 3 doesn't do anything...
Is this normal?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050514

Comment 9

[Boris Zbarsky [:bzbarsky]]

Thomas, check your JS console and compare your result to the "expected result"
in comment 0.  Sounds to me like you're reproducing this bug quite nicely, which
shouldn't be too surprising, since nothing has happened to fix it.

Comment 10

[Jesse Ruderman]

WFM in Firefox trunk, which doesn't use XUL trees for FTP directory listings.

Comment 11

[Jesse Ruderman]

This bug might be related to bug 332182.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Worth retesting, but I'm probably going to have some special checks for chrome principals in that patch.

On the other hand, are ftp:// results really chrome?  If so, we should fix that ASAP.

Comment 13

[Daniel Veditz [:dveditz]]

> are ftp:// results really chrome?  If so, we should fix that ASAP.

They may be chrome documents (I'll go check) but they definitely no longer have chrome permission -- javascript:alert(Components.stack); fails correctly. That comment was specifically about the generated directory listing, an HTML file loaded over ftp always had the correct principal.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Ah, ok.  In that case yes, bug 332182 may help here.  If I ever get time to finish it.  :(

Comment 15

[Boris Zbarsky [:bzbarsky]]

Bug 332182 landed... we should retest this, if I can figure out how to turn on the XUL viewer...

Comment 16

[Boris Zbarsky [:bzbarsky]]

This works for me, both before and after patch for bug 332182.