370583 - Script tags can be used to determine connectivity to various servers

Status: NEW

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

Description

[Jason Barnabe (np)]

This http://www.cs.indiana.edu/pub/techreports/TR641.pdf describes a scenario a webpage can take over a user's router by:
1. Determining the internal IP of a user behind a router with a Java applet
2. Based on that IP, making educated guesses to determine the user's router's internal IP
3. Using a list of common names and passwords, logging in to the router's configuration
4. Determining the make and model of the router based on the images it serves up
5. Doing bad things to the router by submitting POST requests to it

While the exploit depends on having an easily guessable username and password and granting the applet permission to do the IP lookup, I believe there's a cross-domain scripting issue in here.

In #2, the malicious web page can determine whether something's at certain addresses by using a script tag pointing to those addresses and a window.onerror function. If the onerror function complains about "Error loading script", the script knows that there's nothing at that IP. If script returns no error or a different kind of error (currently, an XML parsing error - bug 370580), then it knows there's something there. This is the bug.

Of the other methods I've thought of off the top of my head that could possibly accomplish this, none seem to offer this level of detail to the malicious script.
-a JavaScript Image object will fire its onerror handler if the image couldn't be loaded, but the onerror handler will also fire for non-image requests, so a script couldn't use this without knowing an image's address
-window.onerror is not fired for non-loading CSS, images, or frames
-The documents of cross-domains frames and iframes  are not available
-XHRs don't permit cross-domain requests

Some possible solutions:
-Show "Error loading script" for loading a non-JS file with a script tag so the malicious script can't tell the difference between a non-existent server and a server that doesn't send it JS
-Don't report JS loading errors in window.onerror, but keep reporting them to the Error Console

Comment 1

[Jason Barnabe (np)]

Didn't read this far in the link I provided. It basically says what I said:

6.1.2 HTML and JavaScript Protections

The only other client-side technologies used in this attack are the HTML
<script> tag and JavaScript Image object. These both have widespread use for
off-site content loading; advertising revenue relies on this off-site data
inclusion (embedding a script from adsource.com or loading an image like a hit
counter from a third party's site. The errors caught by JavaScript while
loading third-party scripts with the <script> tag indicate whether a host
exists or not. To eliminate the ability to detect if a host exists, one could
change JavaScript error reporting such that a web page cannot differentiate a
failure to load a script file and a failure to parse a script file.

Comment 2

[Jesse Ruderman]

It would be very hard to prevent scripts from finding out whether third-party images load.  The widths and heights of images affect layout, and scripts are allowed to ask questions about layout.

Wontfix?

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The router part sounds bad though. But maybe it's simply using the fact that you can POST to any server, in which case the problem is with the router since it's too late for us to remove that feature.

Comment 4

[Jason Barnabe (np)]

(In reply to comment #2)
> It would be very hard to prevent scripts from finding out whether third-party
> images load.

The issue is not with images. A script has to specify a path to an image to determine whether a server exists - to a script, "server responded with a non-image" and "no server responded" look the same. This isn't the case with script tags - the script can differentiate between "server responded with a non-JS file" and "no server responded" by looking at the error message.

Comment 5

[Jesse Ruderman]

Oh.  Isn't that bug 363897?

Comment 6

[Jason Barnabe (np)]

Bug 363897 is "don't tell the script the line number or what kind of XML parsing error happened because it can use it to figure out what HTML was served". This is "don't give the script any way of differentiating between a lack of response and a non-JS response". If we fixed bug 363897 by giving a generic "XML Parsing Error" without a line number, this bug would still exist.

There's also bug 370580, "don't give an XML parsing error at all because it's not supposed to XML".

Comment 7

[Jesse Ruderman]

You're getting an "XML parsing error" because the JavaScript engine thinks it's seeing bogus E4X when it's really seeing HTML tag soup.  As far as bug 363897 is concerned, it's no different from any other JavaScript syntax error.

Comment 8

[Daniel Veditz [:dveditz]]

I saw Jeremiah Grossman demonstrate exactly this at Black Hat 2006
http://www.darkreading.com/document.asp?doc_id=99686&WT.svl=news1_2

Probably don't need to hide this one behind the security flag, they all know...

We should fix bug 354493 to prevent remote sites referencing "local" ones (I thought there was a different bug, but 345493 is the closest I could find). Is there anything non-duplicate left in this bug?

Some folks have suggested the image onError should only fire for images on the same-origin, but you can determine load/no-load by checking the dimensions of the image as Jesse noted. Dunno if there's a specific bug number for this one.

Comment 9

[Jason Barnabe (np)]

While bug 354493 describes a different method of achieving this (using onload/onerror of iframes and images), it sounds like the proposed solution would cover this situation as well (looking at the message passed to window.onerror when loading a script).

I didn't intend for this bug to be about image load/no-load with image dimensions.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm very confused what this bug is about at this point. If someone can give a description on what would be left to do to fix this bug once bug 354493 is fixed, please give a short description here. And if you feel that that is worth to consider blocking for, please renominate.

Comment 11

[Jason Barnabe (np)]

This bug is about using script tags and window.onerror to determine whether local network servers exist. Bug 354493 is about timing onload and onerror events on JavaScript Images and HTML iframes to determine whether local network servers exist. If the fix for bug 354493 is to prevent remote sites from loading resources from local network servers, then this will be fixed along with it. If the fix for bug 354493 is something else, then maybe not.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Marking this as wanted unless we determine that this has higher security implication (right now it's just sg:needinfo)

Comment 13

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.