324599 - Link with many pings can cause Firefox to DoS a server long after leaving the attacker's page

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Luke Macken]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060123 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060123 Firefox/1.6a1

A SYN flood attack can be triggered via the new <a ping> attribute due to a lack of duplicate URI checking.

Proof of concept:

    <script language="JavaScript">
        document.write('<a href="http://mozilla.org" ping="');
        for (var i = 0; i < 1000; i++)
            document.write('http://192.168.1.102 ');
        document.write('">Click me</a>');
    </script>



Reproducible: Always

Steps to Reproduce:
1. Embed malicious link on web site
2. User clicks on link
3. User's client floods the URI in the ping attribute with SYN packets

Comment 1

[Luke Macken]

Attachment: firefox-1.6a1-aping-flood.patch

Patch to resolve issue by detecting duplicate URIs.

Comment 2

[Hixie (not reading bugmail)]

How is this different from:

    <script language="JavaScript">
        for (var i = 0; i < 1000; i++)
            document.write('<img src="http://192.168.1.102/?'+i+'">');
    </script>

...?

Other than the fact that the ping="" attack doesn't work unless the user clicks, whereas the example above works whether or not the user does anything beyond visit the page in question?

Removing "Security-Sensitive" flag; the fact that ping="" (and <img>) can be used for DOS attacks is well-known.

Comment 3

[Hixie (not reading bugmail)]

I don't agree that duplicate detection is a valid solution. It is trivial to work around it (as my <img> example does, e.g.), and it would be a perf hit.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I midair collided with Hixie, with the comment, which I'll add anyway:

Two issues here:

1. This doesn't solve the case of all the URLs being slightly different (e.g., same host, randomly generated paths).

2. There are tons of other ways to cause lots of requests to be sent to a server, e.g., by loading lots of images with different URLs.  So why block this particular one?

This doesn't appear to me to be a class of vulnerability that we could actually fix, nor does this patch appear to fix anything but the simplest case of this particular vulnerability.  But maybe I'm missing something.

Comment 5

[Gervase Markham [:gerv]]

We have a max number of open connections to a particular server, right? And when you leave the page, the img ping stops. However, the a ping will carry on, as the browser will have stashed a list of the URLs and will be slowly pinging them one by one.

I think it would be entirely reasonable to de-dupe the list, regardless of any potential security implications. Wouldn't it?

Is it also worth having an arbitrary limit in the spec of, say, ten pinged URLs? Why would anyone ever want more than that?

Gerv

Comment 6

[Darin Fisher]

> Is it also worth having an arbitrary limit in the spec of, say, ten pinged
> URLs? Why would anyone ever want more than that?

dveditz made a similar suggestion over AIM the other day.

Comment 7

[Hixie (not reading bugmail)]

(In reply to comment #5)
> However, the a ping will carry on, as the browser will have stashed a list of 
> the URLs and will be slowly pinging them one by one.

Darin and I were looking at ways to let the STOP button still be active for pings (a "background loadgroup" or something).


> I think it would be entirely reasonable to de-dupe the list, regardless of any
> potential security implications. Wouldn't it?

Don't de-dupe the list. The spec doesn't say to do it. If the author listed URIs twice, he wants two pings.


> Is it also worth having an arbitrary limit in the spec of, say, ten pinged
> URLs? Why would anyone ever want more than that?

The spec won't put an arbitrary limit (why would anyone want more than 640KB of RAM? The moment you have a limit, someone will need to go above it). UAs are of course all going to have practical limits, even if it's 2GB or some high number.

Comment 8

[Gervase Markham [:gerv]]

> Don't de-dupe the list. The spec doesn't say to do it. If the author listed
> URIs twice, he wants two pings.

What I said was, of course, shorthand for "let's change the spec to say that the list should be de-duped".

> The spec won't put an arbitrary limit (why would anyone want more than 640KB 
> of RAM? The moment you have a limit, someone will need to go above it). 

Can you actually think of a use case? The fact that Bill Gates makes shortsighted statements doesn't invalidate my suggestion. How do you suggest preventing the "let's stack up the ping queue with ten thousand requests" abuse?

Gerv

Comment 9

[n0dalus]

Do we even need to allow more than one ping? If they want more than one they can send the subsequent notifications around on the server-side.

Comment 10

[Darin Fisher]

n0dalus: allowing more than one ping is important since the pings need to come from the browser.  limiting to one ping prevents a web page from notifying more than one site of link clicks without cooperation from the one site (i.e., that one site could redirect the browser to cause other sites to be pinged).

Comment 11

[n0dalus]

(In reply to comment #10)
> n0dalus: allowing more than one ping is important since the pings need to come
> from the browser.  limiting to one ping prevents a web page from notifying more
> than one site of link clicks without cooperation from the one site (i.e., that
> one site could redirect the browser to cause other sites to be pinged).
> 

Is it unreasonable to require that a site should need to notify any other sites itself? ie, Firefox 'pings' site a, which in turn is responsible for passing on that data in whatever form appropriate to site b et al.

Comment 12

[Darin Fisher]

fixed by bug 326155