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:

        <img src="http://exploit.me.please" width="1600" height="1600" border="0">

    to

        <img src="http://slashdot.org/whatever/lalala" width="1600" height="1600" border="0">

    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.