User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4) Gecko/2008031317 Firefox/3.0b4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4) Gecko/2008031317 Firefox/3.0b4 See the following link for a more complete description and test cases of the bug: http://files.codechunk.net/fx-img.htm Using a URL redirect in an <img> tag for the src attribute allows arbitrary protocols to be run. Reproducible: Always Steps to Reproduce: 1. <img src="redirect_to_bad_code.png" /> (See link for example) 2. View the page Actual Results: Code is executed when the page with the image is loaded. Expected Results: The code in the <img> redirect should not have been executed. This is mostly a problem on forums or social networking sites, as anyone can make a JS redirect to bad URLs. But on a forum, software is unable to detect redirects to code and cannot prevent it. This makes a usually trusted site potentially unsafe. Since bad protocol URLs directly in the img src attribute are stripped, Firefox should also check for this in redirects before loading code.

This testcase works for me against a recent trunk nightly.

When I load data:text/html,<img src="http://tinyurl.com/yvkh82"> I get a dialog asking me which application I want to use for mailto:.

Actually, yeah, that seems to be what's happening to me also. Perhaps this just looks scarier than it is.

On a vanilla Firefox profile, this is not a big issue, as prompts are made before anything is executed. This mainly affects those that have already configured an application for mailto: or have already approved those (ex.) irc: or apt: handlers in the past. Also note it appears that Firefox uses the GNOME default (or GNOME sets the Firefox default) for mailto: on a Linux system, so there is no prompt here.

Doesn't block Beta 5 ... I'll let the security triagers decide if it blocks final.

Opening a mailto: handler is not "code execution" though.

I don't think this should be security-sensitive. This is just a way to work around the fix for bug 181860. That bug was never security-sensitive. Perhaps we should flag channels that _can_ produce data that go through the no-data check so that if they get redirected we can block the redirect. I do think we should do something here, but this just isn't that big a deal... It's also in the wrong product, but minor details. ;)

Brian: I know, mailto: is nowhere near dangerous. But you have those people that decide for some reason that it is a good idea to register a cmd: protocol to run commands on a system, and could be taken advantage of. It's a bad idea to begin with, but is still an issue. There are also some other possible protocols this could be used with: - apt:install-a-package (not too bad, apturl uses installed repositories at the moment) - irc:/network/channel (mostly an annoyance/spam issue) - sip:1234567890 (call a SIP number or a charge line if the user can call landlines) Many of these examples are rare, and only affect a very very small amount of users. I'm not saying this is a really big security issue; when I first reported this I just veered on the safe side of marking it as one.

Modifying bug summary to better reflect security sensitivity. Along the lines of comment 7, do we _ever_ want to follow redirects for image content?

Yes. If you don't, I suspect the web will more or less break.... This does reduce the value of adblock, of course, if all the ad sites start using tinyurl like this. ;)

Could we simply deny redirects to no-data-protocols maybe?

I could live with that, perhaps. We might want to allow them if the load is in a docshell; not sure about the compat issues there. But that would be pretty easy to check for.

Reassigning to Jonas as this is a subset of another bug he fixed, bug 181860. Probably not a blocker because bug 379804 is not blocking, but would be nice to fix in a 1.9.0.x. Removing security-sensitive flag because it is a subset of other non-hidden bugs.

I agree that this shouldn't block (as in comment #13 and boris' view), but I also think this should be considered in wanted-next instead of 1.9.0.x. Feel free to argue.

Don't think this is blocking. There is no security issues here, the only thing you can do is annoy people with "popups". The original bug got fixed because people would spam forums with <img src="telnet://foobar.com"> which would cause other readers of the forum to get annoying dialogs asking if it was ok to open that url. I think we should fix this the way comment 11 and 12 suggests. But I think we can do that in a dot-release.

This bug is already fixed. <img> elements do not load external protocol URLs. This has been fixed by bug 552605