Build 2003071708 on Mac OS X 10.2.6 I've also seen the same bug in Safari 1.0, and IE Exploder. Mozilla never crashed btw, there's no datalos (unless you pull the plug of your computer to stop the attack ofcourse). Click the following link *only* if you know what you're doing ! http://www.xvsxp.com/applications/internet/malicious-iframe-script.html The code comes down to this : <script type="text/javascript"> for (var loopVar = 1; loopVar <= 800; loopVar++) document.write("<iframe src=telnet://towel.blinkenlights.nl></iframe>") next </script> This page will open 800 telnet-connections to towel.blinkenlights.nl, each in a separate iframe. This is obviously a massive DNS attack on this host (which might be innocent bystander, so be careful !), and you'll have much trouble on your pc too. I had to yank out the network cable, and start force-quitting the terminal appplication (which tried to run telnet in hundreds of windows). Note : I've set the OS/Platform field to All/All, although this bug can't be tested on Linux until bug 33282 is fixed (support for telnet-url on Linux). But the potential for the bug is also here. It might also work for irc-urls for instance (open 800 different channels, hmmmm ?) I tried to find a duplicate, but I couldn't find one. But I have to following questions, how to prevent this kind of stupid attacks : - do we need to allow protocol-urls in iframes ? Not everything makes sense, especially if they don't want to open the data in the iframe itself (IRC, telnet, ...) - do we need a limit the number of iframes in a single page ? - do we need to limit the number of 'calls' to external handlers in a single page ? (especially if they're all the same !) I know we can't prevent everything, people will always write stupid things (see bug 31041 for instance). But we can try at least. Just wait until some stupid journalists picks up the story (and gives away the url to millions of readers).

Also, the effects depend on the handler used (some might not open the connection without confirming). I suppose there isn't a reason to open telnet in an iframe unless there is a Mozilla-based telnet client installed, though to prevent this kind of attack in general, limiting calls (or giving a confirmation warning after a certain number) would probably be best.

> do we need to allow protocol-urls in iframes ? Not everything makes sense, > especially if they don't want to open the data in the iframe itself (IRC, > telnet, ...) How do you know that? What's to prevent us running a telnet client right in the iframe? Or an irc client (chatzilla could easily run in an iframe, for example). > - do we need a limit the number of iframes in a single page ? This is bound to break some pages... we do have some sort of limiter on docshells, iirc (100 off one page, iirc), but there may be no docshells being created in this case... > - do we need to limit the number of 'calls' to external handlers in a single > page ? (especially if they're all the same !) Maybe. This seems like the most worthwhile approach (along with UI to trigger the remaining calls). Pretty nontrivial to do, though....

*** Bug 250585 has been marked as a duplicate of this bug. ***

*** Bug 275766 has been marked as a duplicate of this bug. ***

Dup of bug 167475?

> How do you know that? What's to prevent us running a telnet client right > in the iframe? We cannot run external applications directly within an iframe without an especially designed plugin. <iframe src="telnet:..."> causes external Telnet window to appear outside of browser, not in the iframe content area. Thus I gess <iframe src="telnet:..."> to be not a valid opportunity. And anyway it makes no sense at the Web page, . > Or an irc client (chatzilla could easily run in an iframe, for example). Indeed, logically this is another case than telnet. It may be usable in the chrome context, but I also have doubts about admissibility of this at Web pages. I categorically don't want to log in to the unknown IRC server without my voluntary decision, but iframe does. So, seems that both telnet and irc protocols should be applicable only in <a href>, and so, this seems to be a dupe of bug 167475.

Cleaning per duplicate.