879751 - window.stop can be abused when a site is vulnerable to XSS

Status: RESOLVED INVALID

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

Description

[Christoffer]

Attachment: noStop.zip

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130511120803

Steps to reproduce:

According to the MDN documentation (https://developer.mozilla.org/en-US/docs/Web/API/window.stop) the stop function is stated as:

The stop() method is exactly equivalent to clicking the stop button in the browser. Because of the order in which scripts are loaded, the stop() method cannot stop the document in which it is contained from loading, but it will stop the loading of large images, new windows, and other objects whose loading is deferred.

The problem here is that window.stop() can be called in places where a human can’t click the stop button. As of lately it is very hard to actually press the stop button as all major browser vendors has removed the button. When the window.stop() is called in a JavaScript that is executed before the body is rendered it is a really strange behavior and should not be widespread. But as has found out the behavior of the window.stop() in combination with a Trojan is a very bad combination as it wipes out any client script based defenses.

The noStop.zip file contains a simple test case where the bad.js file (which loads first) replaces the complete document with a new. But all JavaScript attached to the original document from the index.html file still gets executed. This behavior is the same on Chrome, FF and IE. Also a interval is executed every 5 seconds and pressing the browser stop button (tested on IE8) doesn’t affect the interval JavaScript from running. That is the JavaScript is still allowed to run even if the stop button has been pressed.

The stopFFIE.zip file contains the test case where the bad.js file runt windows.stop() and replaces the complete document with a new. This only works on FF and IE, there is also a stopChromeIE.zip that that works on Chrome and IE. It is the way the document is replaced that differs in the browsers. But in both cases the document is rewritten, the bad.js script is allowed to continue its execution and all JavaScript from the original index.html is removed and isn’t executed. It’s here that I would argue that the window.stop() function doesn’t behave as the browser stop button. 



Actual results:

Diffrend behaivior in diffrent versions.


Expected results:

Not really shore, but maybe
1.	Stop all current script. And all registered events (ex. Keyboard, timer and so on.)
2.	Do not allow manipulation of DOM.
3       Remove this funktion, quite many malware is using this funktion to get a green adresbar in the browser.
3.	Maybe some think else..

Comment 1

[Christoffer]

Attachment: one more exampel

Comment 2

[Christoffer]

Attachment: stopChromeIE.zip

Comment 3

[Benjamin Smedberg]

There is nothing security-sensitive in this report. If you've already allowed bad script onto your domain, any subsequent protections you have are basically moot. I don't know why we have a window.stop function, but I don't think there's any security reason to remove the API.

Comment 4

[Christoffer]

Hello,

We have seen that more and more malware is using this function 
(window.stop()). The trojan injects script to our webpage with 
window.stop() at the beginning, it essentially gets “green SSL 
verified bar” and this is what the criminals want.


The problem is that the function is quite defuse, and we have figure 
out that the browser is stopping all threads BUT not the own thread, 
so the malware (is always running first) can stop all script/content 
from us, and still run the own script. So one question is why stop 
part of scripts and note you self.

Comment 5

[Boris Zbarsky [:bzbarsky]]

We have a stop() function because Netscape 2 or whatever added it, then pages used it and then everyone has to support it.

The spec is at http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-window-stop and as far as I know we match it fairly well.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

As I mentioned in email, that function does not "stop all scripts". It does prevent the loading of additional scripts, which might appear to be the same depending on when the malicious code runs.

As I also said in email, and as bsmedberg points out, having arbitrary code running in your page's context is not really a problem you can effectively mitigate by just changing stop(), so it's not useful to just focus on that. To ensure security, you need to avoid the malicious code from ever running to begin with.

At this point window.stop() is a longstanding part of the web platform with some valid use cases, so we can't just remove it without very good justification, and I don't see any such justification here.