Closed Bug 213280 Opened 19 years ago Closed 7 years ago

denial-of-service-attack using iframe & telnet-urls

Categories

(Core :: Networking, defect)

defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 167475

People

(Reporter: jo.hermans, Unassigned)

Details

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?
Blocks: 334426
Depends on: 167475
Depends on: 229168
No longer depends on: 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.
Assignee: darin → nobody
QA Contact: benc → networking
Depends on: 167475
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 167475
You need to log in before you can comment on or make changes to this bug.