Message-Id: <33B3FFED.7BA3@bell-labs.com>
Date: Fri, 27 Jun 1997 14:01:17 -0400
From: Vinod Anupam <anupam@bell-labs.com>
To: "CERT(R) Coordination Center" <cert@cert.org>
Subject: Re: Browser Vulnerability (VU#16403)
This is a multi-part message in MIME format.
--------------56B753B7244C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi Jim,
First, quick answers to your questions:
1) we haven't tested the beta IE 4 yet. I plan to do so in the near
term, and will make information available if the exploit works.
2) Your assessment is pretty accurate. I'd classify the problems as a
design flaw in Explorer, and a combination of design and implementation
flaws in Navigator. I'm attaching a document that describes things in
more technical detail.
Do let me know if there's more information you'd like.
cheers,
-Anupam
CERT(R) Coordination Center wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Vinod Anupam <anupam@bell-labs.com> writes:
> >
> >We have discovered a serious vulnerability in popular versions of both
> >Netscape Navigator/Communicator (2.*, 3.*, 4.*) as well as Microsoft
> >Internet Explorer (3.*).
>
> Have you tested this against the beta IE 4?
>
[...]
>
> Thanks for copying us on your report. We have added this to our
> knowledgebase as VU#16403. One question -- for scoping purposes we are trying
> to understand if this is a design flaw or an implementation error.
>
[...]
> If so, it sounds as though this is an implementation error in Netscape and
> design flaw in MS IE. Or is the problem something else that we haven't correctly
> understood?
>
> Thanks!
>
> -- Jim Ellis
[...]
-- Vinod Anupam _ /| email: anupam@bell-labs.com Bell Labs, Lucent Technologies \'O.o' phone: (908)582-7366 700 Mountain Ave., Rm 2C-223 =(___)= fax: (908)582-5809 Murray Hill, NJ 07974-0636 U www: http://www-db.research.bell-labs.com/user/anupam--------------56B753B7244C Content-Type: text/plain; charset=us-ascii; name="tech.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tech.txt"
Whither Security in Browsers? A technical look at newly discovered security flaws in todays popular browsers -Vinod Anupam
A serious security flaw exists in popular versions of Netscape Navigator (2.*, 3.*, 4.*) and Microsoft Internet Explorer (3.*). This vulnerability allows a perpetrator to use an innocuous web document to load a Trojan horse from a browser window W into a new browser window X. This Trojan horse can then execute arbitrary Javascript code in the context of any/all web documents subsequently loaded into window W with the following implications.
The perpetrator can - track URL's of visited documents - observe any/all data filled into HTML forms - observe value of cookies - observe contents of password elements (on Windows) - dynamically change contents of the action URL of forms, thus enabling the hijacking of form data (tested only on Netscape) - observe form, password, and cookie information even from 'secure' HTTPS-based documents. These documents are protected while data moves over the network, but no protection is provided for the data while in the browser, from where it can be, and is, stolen.
There are three deficiencies in these browsers. - They support the ability to execute arbitrary JavaScript code originating outside a document in the context of the document, creating a huge vulnerability. (Design flaw?) - They support the ability to extract password element data as plain text (on Windows), documentation to the contrary. (Bug) - They provide no facility to protect data in browser documents retrieved using HTTPS from being compromised - i.e. security is not end-to-end. (Design flaw?)
We now discuss the technical aspects of this vulnerability. This discussion assumes that the reader has some familiarity with HTML/HTTP; JavaScript; the JavaScript Object Model & Instance Hierarchy; JavaScript Security; and LiveConnect/ActiveX.
There are three requirements for the Trojan horse to successfully snoop. It needs to persist across multiple document fetches, it needs to be able to access data from those documents, and it needs to be able to transmit the captured data to a desired location.
This exploit uses a loophole that allows JavaScript executing in one browser window to observe components of another window. The seriousness is compounded by the fact that password elements of forms are accessible in clear-text on some platforms, and by the fact that documents retrieved using HTTPS are equally vulnerable.
The first step for the exploit is to set itself up to exist independently of the original window, so it can persist across multiple document loads in the original browser window. To do this, it creates a new window (subsequently called the snooping window) and loads an exploit-relevant HTML document. The exploit code runs in this new window instance.It is enirely possible that a user will notice the presence of the new window. However, the creation of a new window is not a suspicious act in itself- a multitude of sites use multiple windows to display documents on the Web. In addition, control over size and placement of the window can be used to reduce the chances of detection.
The next step is to get a handle (object reference) to the window that is being observed. The exploit uses the window object to get a handle to the window that created it. Different browsers (and versions) are exploited slightly differently.
Microsoft Internet Explorer 3.02 is the simplest environment, and imposes no security restrictions that need to be bypassed. JavaScript code in the snooping window is free to walk the instance hierarchy of the original window, and has direct access to all the information typed into any form subsequently loaded into the original window, the URLs etc. JavaScript code in the snooping window periodically polls the document in the original window for its contents, and copies the data into its local 'context'. We have not yet tested the exploit on beta versions of IE 4.0. We consider this absence of security restrictions to be a design flaw.
Netscape Navigator 2.02, 3.01 and 4.01 have increasingly sophisticated "security" models. Navigator 2.* uses only script address based access control - only JavaScript from the server that sent the HTML document is supposed to be able to access data in the document. Navigator 3.* adds a 'tainting' model which, if enabled, lets arbitrary scripts access any data that is explicitly marked as being safe to expose (data in forms starts out being marked unsafe to expose). By default, all data is considered to be unsafe to expose. Navigator 4.* does away with the tainting model, and uses a digital signature based scheme for access control. Here, only scripts with the appropriate rights are supposed to be able to access data in documents.
This exploit bypasses security in all cases by using the window handle to make the targeted window execute arbitrary JavaScript in its own context via JavaScript URLs (javascript:<arbitrary JavaScript code> ). JavaScript URLs don't seem to be subject to any restrictions. The injected code periodically gathers all information that the user types into an arbitrary HTML document in the original window, and makes it available to the context of the snooping window. In 2.* and 3.* this is achieved directly, by writing into variables in the snooping window's document context. In 4.*, this is achieved by writing to and reading from a property of a mutually accessible object (the original window object). We regard the bypassability of access control in 2.* and 3.* to be an implementation bug. The presence of this bug in 4.*, where access control is stricter indicates that the problem may be more fundamental. The absence of a clear notion of capabilities of JavaScript URLs is a design f! law.
Once data is obtained, the snooping window is free to transmit it to a location of its choosing. It can transmit directly via HTTP by sending the data to a dynamically constructed URL. This cannot be detected by the user. the snooping window can put the data into fields of a form and submit the form. This method may be detected and circumvented by a vigilant user who sets up the browser to require interactive confirmation for all form submissions. Finally, code in the snooping window may communicate with an installed Java applet and/or ActiveX script to transmit the information to a desired location. This also cannot be detected by the user.
This browser vulnerability has a serious implication for intranets. Most users use the same browser to access information on the intranet as well as the Internet. A user who has been "attacked" using this vulnerability has essentially compromised the firewall - the Trojan horse is able to extract data from intranet documents and transmit it to an external entity. Any data that the user enters into forms - ID numbers, social security numbers, PO numbers, vendors and prices, bug reports, passwords etc. (all kinds of proprietary information) can be relayed to the outside. In addition, the document itself can be subjected to analysis, yielding information about different fields, options and their corresponding values. Particularly serious is the fact that this exploit bypasses security provided by HTTPS or HTTP authentication - many Web servers and other business platforms are administered over the web nowadays. Information about document URLs and links on pages provide the snoop ! with an idea of how the domain i
s organized. This knowledge may be used to conduct other attacks.
The exploit capitalizes on both design and implementation flaws. E.g., functionally, it appears that JavaScript URLs are treated the same as inline code. Once injected into a window, however, there seems to be no notion of where the code came from, leading to the ineffectiveness of access controls.
The following needs to be done by browser vendors to fix this vulnerability. 1) JavaScript code, like Java applets, should be made to execute in a properly implemented sandbox with explicitly specified and regulated access control. A formal model, rather than ad-hoc implementation, is needed. 2) Password fields in forms (as specified in JavaScript documentation, and as happens in Unix versions) must never be accessible in the clear to JavaScript. 3) Data in documents retrieved using HTTPS must never be accessible in the clear to scripts from any other server.
In the short term, we recommend that users set up their browsers to 1) turn off JavaScript (via the language preference settings) 2) require confirmation before any form submissions (via the security settings) till browser vendors release fixed versions of the software.
--------------56B753B7244C--