The following AppleScript script opens a chrome:// URL in Firefox: tell application "DeerPark" activate Get URL "chrome://browser/content/" end tell From what Josh Aas has said to me, I think this is similar to how other Mac apps give URLs to Firefox, so this means other Mac apps (such as QuickTime?) could be abused to open chrome:// URLs in Firefox.

Yeah, we should probably not load chrome:// urls in the GetURL handler. Are there other protocols we should block (data:, res:)?

We need to either block or do the right thing with javascript: and data: URLs that come from external sources. I think that's covered by bug 304690.

If we disable the ability to open chrome URLs from other applications, would be be blocking functionality that is necessary for XULRunner? I've never really looked into XULRunner, so I'm not sure. I CC'd bsmedberg.

If that becomes a problem, we'll add a new AppleScript command that's equivalent to the -chrome command-line switch. We'll have to take that approach anyway assuming bug 286651 is fixed.

This does not affect xulrunner.

This should do it, but I don't have a built tree to test right now and I'm feeling to sick to ensure that this works anyway. My only concern is that if urlString is < 6 characters long it might crash. The documentation is a little unclear here, but it looks like it just stops comparing when it hits \0 string termination. If that is the case, then no need for an extra check and my patch should do fine.

Another concern about my patch - what if someone gives a URL that has a single space at the beginning. The test will fail, the URL will get sent. Is this really a problem? Again, can't test at the moment.

Comment on attachment 193637 [details] [diff] [review] fix v1.0 cancelling reviews, Mark should be posting an improved patch per our discussion on IRC

This builds on Josh's proposal by advancing past leading whitespace, looking for the trailing colon, and doing a case-insensitive comparison.

Comment on attachment 193729 [details] [diff] [review] v1.1 please request approval after you've got sufficient reviews. thanks.

P.S. I think that this patch is necessary, but there's no likely exploit via the standard URL-passing channel. We don't tell the system that we handle chrome: URLs, so the system won't tell us when it gets a chrome: URL in the standard handlers (LSOpenCFURLRef, ICLaunchURL, or the Cocoa equivalent). The caller needs to explicitly specify Firefox, like the AppleScript in comment 0 does. That limits exposure quite a bit.

>This builds on Josh's proposal by advancing past leading whitespace, looking >for the trailing colon, and doing a case-insensitive comparison. It would probably be better to use Gecko's normal URL parsing stuff: get an nsIURI through nsIOService::NewURI and then using nsIURI::schemeIs to check whether it's a chrome URL.

Comment on attachment 193729 [details] [diff] [review] v1.1 You want to do what Jesse mentioned. We've been converting rogue callers over to nsIURI for a while, please use that wherever you're parsing URIs.

Jesse: I talked to jst before writing my patch about doing the standard URI parsing and he said if we're not making that object anyway, then a strcmp-like check should be fine. Will change if other people feel different.

As Josh said, the word was that the strcmp family would be OK here. Here it is using nsIURI instead.

shouldn't have removed the comment, and the variable should be called isBlockedScheme for clarity.

Fixed on trunk.

...and branch.