OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Ben Li (baliTHOCK.COM)
Date: Mon Jan 22 2001 - 22:24:14 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    *** Aa explotable example of this has been found using white text. I think
    it's time this hits the list, wether MS likes it or not -Ben ***

      DHTML/CSS/web-based email Vulnerability

      Report: Dylan Griffiths (dylangthock.com) and Ben Li (balithock.com)
      Discovery: Ben Li

      Jan 15, 2001

      Originally sent Jan 6, 2001 (not Jan 6, 2000)

      ----------------------------------------------------------------------------

    Summary:

    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.

    Vendor contact:

    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.

    Details:

    A properly malformed page containing the <DIV> (or <LAYER>) tag anchors a
    BROKEN* 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).

    * the SRC address for the image refers to a resource that cannot be found at
    that address

    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.

    Browser specifics:

    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).

    Solutions:

    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.

    Notes:

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

      "The layer tag is a new tag introduced in Netscape 4 that allows authors to
    position and animate (through scripting) elements in a page. A layer can be
    thought of as a separate document that resides on top of the main one, all
    existing within one window."

     -Adam Brown / adambrown2iname.com /
    http://www.geocities.com/SiliconValley/Orchard/5212/layer.htm

    Why this is bad is left as an exercise for the reader. (Are other DHTML
    document-formatting tags vulnerable as well?)

    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.

    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.

    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 (beware of wrapping)

    <HT-ML>
      <HE-AD>
        <TI-TLE>
          dhtml vulnerability test page (Mozilla 0.6 vulnerable)
        </TI-TLE>
      </HE-AD>
    <BO-DY>

    <d-iv align="left">
      <d-iv 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">
        <i-mg src="http://exploit.me.please" width="1600" height="1600"
    border="0"></-A>
      </d-iv>
      Visit our <-A HREF="http://l33t.porn.site">l33t p0rn site</-a>
      Remove address:<-a href="mailto:removeme.con">removeme.con</-a>
    </d-iv>

    </BO-DY>
    </HT-ML>

    (HTML tags intentionally broken with hyphens to prevent HTML-capable email
    clients from being overzealous in rendering. It is left to the reader how
    best to turn this into a force-click situation for many users.)

    Changing
    <i-mg src="http://exploit.me.please" width="1600" height="1600" border="0">
    to
    <i-mg 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.

    Discussion:

    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/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.

    Comments:

    Clearly we have failed to demonstrate to Microsoft, to their standards, that
    being able to force a web based email user to visit a web page and to
    potentially divulge account information by sending them an email can be a bad
    thing. Microsoft, has in turn, successfully confused us with such statements
    as "It looks like this issue from the hotmail side will be corrected in an
    upcoming update early February or at the end of this month," and "In short we
    do not see this as a security vulnerability or a violation of our security
    model design." If there is no issue, what is being fixed?

    Copies of correspondence with Microsoft are available upon request.

    References:

    Brown, Adam / adambrown2iname.com /
    http://www.geocities.com/SiliconValley/Orchard/5212/layer.htm

    Anonymous / HTML 4.01 Specification / http://www.w3.org/TR/html4/

    H+kon Wium Lie / howcomew3.org / Bert Bos / bertw3.org / Cascading Style
    Sheets, level 1 / http://www.w3.org/TR/REC-CSS1

    DisLamer:

    Use this information at your own risk. Authors take no responsibility for
    your actions or stupidity, etc, etc

    Names and Trademarks used herein are properties of their respective owners.

    EOF


      DHTML/CSS/web-based email Vulnerability


      Report: Dylan Griffiths (dylangthock.com) and Ben Li (balithock.com)
      Discovery: Ben Li

      Jan 15, 2001
        
      Originally sent Jan 6, 2001 (not Jan 6, 2000)



      ----------------------------------------------------------------------------
      
    Summary:

    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.


    Vendor contact:

    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.


    Details:

    A properly malformed page containing the <DIV> (or <LAYER>) tag anchors a BROKEN* 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).

    * the SRC address for the image refers to a resource that cannot be found at that address


    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.


    Browser specifics:

    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).


    Solutions:

    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.


    Notes:

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

      "The layer tag is a new tag introduced in Netscape 4 that allows authors to position and animate (through scripting) elements in a page. A layer can be thought of as a separate document that resides on top of the main one, all existing within one window."

     -Adam Brown / adambrown2iname.com / http://www.geocities.com/SiliconValley/Orchard/5212/layer.htm


    Why this is bad is left as an exercise for the reader. (Are other DHTML document-formatting tags vulnerable as well?)


    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.

    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.


    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 (beware of wrapping)


    <HT-ML>
      <HE-AD>
        <TI-TLE>
          dhtml vulnerability test page (Mozilla 0.6 vulnerable)
        </TI-TLE>
      </HE-AD>
    <BO-DY>

    <d-iv align="left">
      <d-iv 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">
        <i-mg src="http://exploit.me.please" width="1600" height="1600" border="0"></-A>
      </d-iv>
      Visit our <-A HREF="http://l33t.porn.site">l33t p0rn site</-a>
      Remove address:<-a href="mailto:removeme.con">removeme.con</-a>
    </d-iv>

    </BO-DY>
    </HT-ML>


    (HTML tags intentionally broken with hyphens to prevent HTML-capable email clients from being overzealous in rendering. It is left to the reader how best to turn this into a force-click situation for many users.)

    Changing
    <i-mg src="http://exploit.me.please" width="1600" height="1600" border="0">
    to
    <i-mg 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.


    Discussion:

    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/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.


    Comments:

    Clearly we have failed to demonstrate to Microsoft, to their standards, that being able to force a web based email user to visit a web page and to potentially divulge account information by sending them an email can be a bad thing. Microsoft, has in turn, successfully confused us with such statements as "It looks like this issue from the hotmail side will be corrected in an upcoming update early February or at the end of this month," and "In short we do not see this as a security vulnerability or a violation of our security model design." If there is no issue, what is being fixed?

    Copies of correspondence with Microsoft are available upon request.



    References:

    Brown, Adam / adambrown2iname.com / http://www.geocities.com/SiliconValley/Orchard/5212/layer.htm

    Anonymous / HTML 4.01 Specification / http://www.w3.org/TR/html4/

    H+kon Wium Lie / howcomew3.org / Bert Bos / bertw3.org / Cascading Style Sheets, level 1 / http://www.w3.org/TR/REC-CSS1



    DisLamer:

    Use this information at your own risk. Authors take no responsibility for your actions or stupidity, etc, etc

    Names and Trademarks used herein are properties of their respective owners.


    EOF