I have nto hand checked this expliot, just passing it on now for the
HTMLEmailIsGod crowd. I await ostrich replies:)-
---------- Forwarded message ----------
Date: Tue, 23 Jan 2001 04:24:14 -0000
From: Ben Li <bali@thock.com>
To: BUGTRAQ@SECURITYFOCUS.COM
*** 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 (dylang@thock.com) and Ben Li (bali@thock.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 / adambrown2@iname.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:remove@me.con">remove@me.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 / adambrown2@iname.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 / howcome@w3.org / Bert Bos / bert@w3.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 (dylang@thock.com) and Ben Li (bali@thock.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 / adambrown2@iname.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:remove@me.con">remove@me.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 / adambrown2@iname.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 / howcome@w3.org / Bert Bos / bert@w3.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
This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:19:01 PDT