337223 - Make sure moz-anno protocol is not available to web pages.

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, defect, P2)

Description

[Brett Wilson]

Comment 1

[Brett Wilson]

moz-anno has the same priveledges as chrome. Part of this bug is I wanted to double-check that this is still the case.

The other part of this bug is a more fundamental problem that images don't respect chrominess. In other words, any web page can have a reference to a chrome: URI and it will work, despite the fact that these would normally be forbidden. I think this is used for FTP views for showing the icons.

This also affects annotation URIs. This means any web page can pull up image annotations you have in your system. Extensions might add images, so I'm not sure how bad this would be. The only thing we have by default is favicons, so this could expose which web sites you've visited. However, this is already exposed by the :visited CSS style, so it's not (more) of a privacy leak.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> The other part of this bug is a more fundamental problem that images don't
> respect chrominess.

Er... they do on trunk and 1.8 branch, last I checked!

> In other words, any web page can have a reference to a chrome: URI and it will
> work

Chrome URIs are allowed from web pages for XBL bindings, scripts, and CSS style sheets. That's it.  But moz-anno seems to be allowed in all those places too; is there a reason?

Put another way, is there a reason moz-anno is ChromeProtocol instead of DenyProtocol?  DenyProtocol means "allow loads only if the thing loading is chrome" while ChromeProtocol means something very different.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Or to make it even more clear, will I break anything if I change this to DenyProtocol?

Comment 4

[Brett Wilson]

(In reply to comment #3)
> Or to make it even more clear, will I break anything if I change this to
> DenyProtocol?

Not that I can think of.

Comment 5

[Brett Wilson]

(In reply to comment #2)
> > The other part of this bug is a more fundamental problem that images don't
> > respect chrominess.
> 
> Er... they do on trunk and 1.8 branch, last I checked!

Then check again:
http://maxradi.us/post/bugzilla/chrome.html
Trunk or branch is OK. I talked with dveditz about this last year.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Then check again:

That's the right behavior.  Not loads of chrome:// image by untrusted content.  What's the problem?

In any case, it doesn't look like I'll have CheckLoadURI redone in time for 1.9a1, so you probably want to change that ChromeProtocol to DenyProtocol.

Comment 7

[Brett Wilson]

Both my truuk and 1.5 build show the image.

Comment 8

[Brett Wilson]

(In reply to comment #7)
> Both my truuk and 1.5 build show the image.

This is with Firefox. If you are using Seamonkey, the image will probably be broken because the URL doesn't work.

Comment 9

[Brett Wilson]

(In reply to comment #8)
> This is with Firefox. If you are using Seamonkey, the image will probably be
> broken because the URL doesn't work.

And by doesn't work I meant there't no image with that name.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Ah, hmm... we do seem to pass nsIScriptSecurityManager::ALLOW_CHROME for images, like we do for scripts, etc.

None of which is directly relevant to this bug, right?

Comment 11

[Brett Wilson]

(In reply to comment #10)
> Ah, hmm... we do seem to pass nsIScriptSecurityManager::ALLOW_CHROME for
> images, like we do for scripts, etc.
> 
> None of which is directly relevant to this bug, right?

I guess not. I didn't think there was another mode so that this would be as locked down as we could make it, which is why I thought it was relevant earlier.

Comment 12

[Brett Wilson]

Attachment: Patch

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 222971 [details] [diff] [review]
Patch

I'm not a CAPS peer, really...  Try jst or dveditz?

Comment 14

[Johnny Stenback (:jst)]

Comment on attachment 222971 [details] [diff] [review]
Patch

r=jst

Comment 15

[Peter Kasting]

Checked into trunk.  Clearing blocking request.

/mozilla/caps/src/nsScriptSecurityManager.cpp 1.309

Comment 16

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv