Closed Bug 337223 Opened 14 years ago Closed 14 years ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED
Firefox 3 alpha1

People

(Reporter: brettw, Assigned: brettw)

References

Details

Attachments

(1 file)

 
Flags: blocking1.9a1?
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.
> 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.
Or to make it even more clear, will I break anything if I change this to DenyProtocol?
(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.
(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.
> 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.
Both my truuk and 1.5 build show the image.
Priority: -- → P1
(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.
(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.
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?
(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.
Priority: P1 → P2
Target Milestone: --- → Firefox 3 alpha1
Attached patch PatchSplinter Review
Attachment #222971 - Flags: review?(bzbarsky)
Whiteboard: has patch
Comment on attachment 222971 [details] [diff] [review]
Patch

I'm not a CAPS peer, really...  Try jst or dveditz?
Attachment #222971 - Flags: superreview+
Attachment #222971 - Flags: review?(jst)
Attachment #222971 - Flags: review?(bzbarsky)
Comment on attachment 222971 [details] [diff] [review]
Patch

r=jst
Attachment #222971 - Flags: review?(jst) → review+
Whiteboard: has patch → check in
Whiteboard: check in → [needs checkin]
Checked into trunk.  Clearing blocking request.

/mozilla/caps/src/nsScriptSecurityManager.cpp 1.309
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: blocking1.9a1?
Resolution: --- → FIXED
Whiteboard: [needs checkin]
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.