COMMAND

DHTML/CSS/web-based email

SYSTEMS AFFECTED

DHTML/CSS/web-based email

PROBLEM

Ben Li found following. There is a bug in many 4th generation
browsers that allows users of web based email to be mis-directed
to unintended destinations when mail management buttons are
clicked. This is due to interactions between the browser and CSS
<DIV> tags, and the DHTML <LAYER> tag.

A properly malformed page containing the <DIV> (or <LAYER>) tag
anchors a BROKEN (the SRC address for the image refers to a
resource that cannot be found at that address) clickable image (an
image surrounded by <A HREF=...></A>) over top of the page
containing other links by using a z-index of zero (effectively on
top of everything else) in the style for the image. Since it is a
broken image, the page is not obscured by the image, and clicks
directed to links on the page will instead send the user to the
page specified in the HREF for the floating image.

This could be exploitable by sending crafted HTML to users of
web-based email providers (such as Hotmail, ZDNet mail, etc) or
possibly by sending the same email to users with email clients
that render HTML. This is vulnerability could also exist in other
HTML-rendering applications as well (for example, Napster, CuteMX,
etc).

Examples:
1. A user gets an stupid-looking (or blank) malicious mail in
their web-based email. They click "delete" (or other
navigation tools: forward, back, save address, etc) to delete
the message, and are sent to a nasty place like goatse.cx,
which is linked to by the floating image. Alternatively, the
user is directed to a counterfeited page on the attacker's
server asking the user to re-login or supply information asking
them for verification of adulthood through a credit card
number.

2. A user is logged in to Hotmail and views the message contained
in the HTML code example below. Since the floating image
covers the entire page (the image is 3000 by 3000 pels in our
example below), they would be unable to log out or navigate
from the current message by clicking elements on the page and
would need to navigate out of the message using the back button
(or its keyboard counterpart) or by specifying a new URL to
view using the address bar.

3. A user is logged in to Hotmail and clicks the ad banner, which
has a broken image positioned over it which directs the user to
another site, resulting in monetary losses for Microsoft and
the people advertising with the banner.

The presentation of links in DHTML can be very complex because of
the interactions between link rendering, image rendering, page
layering, other elements, and CSS. Thus different browsers are
vulnerable to different variations of the exploit code below and
on different web-based email sites. Additionally, some page
elements (for example, form elements) may be assigned an effective
Z-order of -1 in the browser (which is above the Z-order of 0 for
the floating image), resulting in vulnerable image and text links
but not form elements. Your mileage will vary.

Internet Explorer for Windows and Mozilla are largely vulnerable
because there is no easy way of turning off CSS (doing so seems to
correct the issue in other browsers). Mozilla is, however, harder
to trick into allowing the layer overlay to obstruct links below
it. If the domain from which the image is sourced does resolve
but does not contain the image file, Mozilla reduces the image to
a link with the ALT text. If the domain doesn't resolve, it will
use a placeholder image in its place.

Opera is partially vulnerable on Hotmail (some buttons are
obscured by the large image shown in the code above, others are
not), and not vulnerable on ZDNet mail because of how ZDNet mail
implements their buttons. ZDNet mail and Yahoo! also use frames
to separate the message display frame from navigation/other frames
which reduces this vulnerability to only the message display
frame.

Netscape 4.7 is vulnerable to both <DIV> and <LAYER> on the PC and
appears to be vulnerable to <DIV> on MacOS (response to clicking
a link appears to change if the browser is resized after the
exploit code is loaded, thanks to problems with NS4's rendering
engine).

The introduction of the <LAYER> tag by Netscape was silly and
exposes users to this and potentially other link-spoofing
vulnerabilities.

Tested vulnerable browser/OS combinations using the code below
Yahoo!, Hotmail, and ZDNet:

Opera 4.02 / W2KPro SP1/US: DIV
-------------------------------
The entire message frame links to the exploit page with the
exception of the drop-down list containing folder names and the
"move to" button next to it (Hotmail). Text links appear to be
unaffected by the floating image while most image links are
affected. For example, in Hotmail, the "sign out of passport"
image link works, but the "Inbox", "Compose" ... image links are
compromised. Additionally, there might be unusual boundary
conditions involved in the way the floating image is handled. In
Hotmail, moving the cursor (a pointer) in from the top to the
message results in the maintenance of the pointer with the switch
to the finger at about 100 pels or until the cursor hits an image
link. Moving the cursor up again shows that the finger is
maintained for about 80 pels (until the top line menu in the
Hotmail window is reached).

Internet Explorer 5.00.3103.1000/5.50.4522.1800 / W2KPro SP1/US: DIV
--------------------------------------------------------------------
The entire message frame links to the exploit page with the
exception of the IFRAMEd banner and the drop-down list containing
folder names. The IFRAMEd banner links to the site intended by
the code in the IFRAME.

Netscape 4.75 / W2KPro SP1/US, Linux, MacOS 8.6/9.0: DIV and LAYER
------------------------------------------------------------------
The entire message frame links to the exploit page with the
exception of the drop-down list containing folder names and the
"move to" button next to it. Resizing the Netscape window or
changing focus causes different things to link to the exploit page
and alters cursor display behavior when hovering over things.
Additionally, bringing in the cursor from the top generally
results in the hand cursor, while bringing it in from the status
bar results in a pointer cursor, although in both cases object
clickability is identical.

Mozilla 0.6/0.7 / W2KPro SP1/US: DIV*
-------------------------------------
(ZDNet mail) Everything in the message frame links to the exploit
page including the drop-down list containing folder names except
for about 20 pels at the top of the message frame where the
outline for the broken image is visible.

Mozilla build 2000123106 / Linux: DIV*
Netscape 4.7 / MacOS 9: DIV**
Internet Explorer 5 / MacOS9: DIV
--------------------------------------
* Only if the server from which the image originates does not
resolve. For example, the exploit would work if the image came
from http://test.dom/whatever_directory (domain name does not
resolve) but NOT from http://slashdot.org/whatever/lalala
(domain name resolves but resource does not exist).
** Netscape 4.7 on MacOS 9 becomes more susceptible (more page
elements are covered by the floating image) if the window is
resized after the exploit page is loaded.

Example code? The following HTML page, if sent to a Hotmail,
ZDNet, or Yahoo! mail account, will cover the entire page or frame
with the broken floating image which links to http://exploit.me:

<HTML>
<HEAD>
<TITLE>
dhtml vulnerability test page (Mozilla 0.6 vulnerable)
</TITLE>
</HEAD>
<BODY>

<div align="left">
<div id="layer4" style="width:99px; height:99px; position:absolute; left:0px; top:0px; z-index:0;">
<p align="center"><A HREF="http://exploit.me" ALT="Exploit Me" TITLE="Example String">
<img src="http://exploit.me.please" width="1600" height="1600" border="0"></A>
</div>
Visit our <A HREF="http://l33t.porn.site">l33t p0rn site</a>
Remove address:<a href="mailto:remove@me.con">remove@me.con</a>
</div>

</BODY>
</HTML>

It is left to the reader how best to turn this into a force-click
situation for many users.

Changing:

where the domain slashdot.org resolves results in Mozilla being
non-vulnerable (the resource /whatever/lalala should not exist).
The vulnerability generally does not work if the resource
specified in the SRC exists.

The most obvious indication that this exploit exists on a page is
by the broken image icon(s) on the page itself (although this
exploit may be possible using a working clear image or other
element which would not show such an icon, we have not tested
this. This, however, can be obscured in a sea of broken images.
It is conceivable that other things (objects, applets, HTML
pages, etc) could be floated in a broken or non-broken state as
well which could result in interesting related vulnerabilities
and exploits.

There are ways of determining if this exploit is being used
against your browser. The status bar will usually display the
link which is hovered over by the mouse (depending on browser
version) but this can be defeated using creative scripting or the
use of the HTML 4 TITLE attribute in the link (variable success
depending on browser version/web-based email provider).
Additionally, it would be trivial to use multiple floating images
crafted to fit exactly over the buttons used by a particular
web-based email provider (since this provider is known ahead of
time) to avoid the one-big-clickable-image provided in the example
above.

We only tested DIV (and LAYER to a limited extent). This exploit
may be available with other positioning tags. Additionally, the
variety of responses obtained from the tested browsers indicates
that each renders DHTML in a different manner, and each could be
subject to different variations of this vulnerability (not all of
which have yet been conceived or tested). Conceivably, this
vulnerability also extends to web bulletin boards, usenet, and
other areas where HTML can be posted, but this has not been
tested.

Since developing patches for and patching every version 4+ browser
is not feasible, it would be prudent to disable CSS on the client
if possible (protects one installation/profile only), or at the
web-based email server by filtering out DIV and LAYER tags as
suggested above (protects all web-based email users on that
server). The use of framed windows when external links are opened
which indicate the off-site status of the link, such as those used
by Hotmail, would reduce the effects of this vulnerability
somewhat by indicating that the exploiting page is off-site,
although this technique could be defeated by linking to a page
that spawns another window on top of the ZOrder quickly, or
reloads itself to top using javascript.

While testing the snippet, we noticed that the resulting message
would be presented differently depending on the placement of white
space in the snippet. For example, Yahoo! mail presents in-line
HTML code (not vulnerable) when the <HTML> tag is preceded by a
single space (0x20), but presents the message as expected
(vulnerable) if that space is not present and <HTML> begins on a
new line.

More research into the possible misuse of DHTML positioning tags
is needed, but we feel that it is important to let this out now
so as to prevent actual exploitation of this vulnerability. This
vulnerability was inspired by broken HTML received in spam on the
Hotmail account of B. L. which was one step away from being
exploitable (it positioned a logo at the top of the page, covering
some Hotmail buttons) but lacked an anchor.

SOLUTION

It would be impossible to contact every web-based email provider
out there in a timely manner so those with the most users will be
given priority.

Microsoft, Netscape, Opera, USANet and Yahoo! were sent a
preliminary copy of this report on 6 Jan 2001 since they have the
largest web-based email subscriber bases and thus the most
potential vulnerable users. Microsoft was the only vendor that
responded interactively and has stated that they do not believe
this to be an issue. The vendors were sent a second preliminary
copy of this report on 14 Jan 2001 with no response from any
vendors other than Microsoft.

Web mail providers should filter out <DIV> and <LAYER> tags (or
better still, have all allowed HTML tags in a whitelist, and
escape all other tags to reduce the risk of future vulnerabilities
of this type) OR disable document CSS in your browser (Netscape
4.x, Opera 4.x). IE5 and Mozilla do not support disabling CSS in
an easy manner.

Tested non-vulnerable:

Opera 3.62b6 / W2KPro SP1/US (incomplete CSS implementation)
------------------------------------------------------------
The floating image renders as an inline image entirely within the
table containing the email message body and does not affect any
links.

Netscape 3.04 16-bit / W2KPro SP1/US (does not understand CSS)
--------------------------------------------------------------
Only broken image icon links to the exploit page.

Internet Explorer 3.0 / Win95 4.00.950A (does not understand CSS)
Lynx (does not understand DHTML or CSS)
-----------------------------------------------------------------
Clickable? :-) [LINK] links to the exploit page.