Minor IE vulnerability: about: URLs

2001-10-20T00:00:00
ID SECURITYVULNS:DOC:2112
Type securityvulns
Reporter Securityvulns
Modified 2001-10-20T00:00:00

Description

Zone spoofing? Oh yes, that reminds me. Here's another one.

Affected: Internet Explorer under Windows, up to version 6 Risk: Low Workaround: Disable scripting in the Internet Zone

Problem:

If an unknown 'about:' name is used, IE echos the string exactly to the page. So 'about:foo' results in an HTML page containing the word 'foo', 'about:<em>bar</em>' results in a page containing the emphasised word 'bar', and 'about:<script>...</script>' is an obvious security issue.

This amounts to a cross-site-scripting hole (see CERT CA-2000-02) built into every copy of IE.

Consequences:

'about:' pages are in the Internet Zone; hence, sites in the Restricted Zone (including HTML e-mail) may, by linking to an 'about' page, inject and execute content they would not normally be allowed to run.

Sites that accept user-submitted content must* filter out about: URLs just as they should filter out 'javascript:' and 'vbscript:' ones.* It's probably a good idea to disallow all protocol not known- good (http[s], ftp, etc.) as there may be other protocols which present a risk.

Cookies can be stored for 'about:' pages in newer versions of IE. This allows any site to store and read cookies from a shared location, circumventing the normal restriction that sites may not pass cookies to each other.

[Each 'about:' page is considered different so if we were to write 'about:<script>alert(document.cookie);document.cookie='a=b'</script>', that cookie would only be readable from the same URL, which would only give us a one-bit store for each URL. We can get around this by noting that IE incorrectly applies HTTP-style URL parsing to 'about:' URLs - one consequence of which is that if you include a question mark in the URL, only the part of the URL before the ? is considered part of the unique page name.]

Exploit:

Global shared cookie store. Cookies are deliberately designed to disallow sharing between sites, through restrictions on the 'path' setting. These pages, however, can read each other's cookies:

http://and.doxdesk.com/transfer/vuln.html http://www.1value.com/transfer/vuln.html

Of course they could do so with a lot more subtlety, hiding from the user using techniques like invisible frames, transparent redirects, etc.

Versions:

Assume all versions of IE/Win are vulnerable. Status of IE under other platforms is unknown. Versions tested:

4.72.3612.1713 (SP2; 3283) 5.00.3315.1000 (SP2) 5.50.4522.1800 6.0.2600.0000

However, only IE5.5 and IE6 seemed able to store cookies for about: pages; the exploit did not work on IE4 and IE5.0.

Vendor response: Probably won'tfix.

A Microsoft chap pointed out that sites can already break out of the Restricted Sites Zone, simply by pointing at another site that is not in that Zone.

(Cookies could similarly be shared by creating a 'cookie aggregator' site which could be redirected to in order to set the desired cookie and return to the originating site with a copy of all cookies set by different sites.)

My response: in both cases, the 'rogue' site being redirected to can also be put in the Restricted Sites Zone to stop it. This is not the case with about: URLs, which are always in the Internet Zone and cannot be changed. External sites can also be foiled through firewalling and local blackhole routing, which about: cannot. Unlike external sites, about: URLs are processed instantaneously, making the user much less likely to notice them. Finally, an external cookie aggregator site would be subject to privacy policies and laws, which about: URLs cannot be.

I think it is a shame that the usefulness of the Restricted Sites Zone feature and the locality restrictions on cookies are compromised in favour of a feature (about:something generating a page with 'something' on) that is undocumented, non-standard, little-known and of no conceivable legitimate use whatsoever.

But your mileage may vary. Make sure your web apps aren't exploitable, anyway.

-- Andrew Clover Technical Consultant 1VALUE.com AG