Hello Thierry!

> Your saying above that this attack works if "Initialise and script
> ActiveX control not marked as safe" is ENABLED.

This Saved XSS hole works even with this option disabled (i.e. with default
settings). But when we want to use ActiveX in our code (e.g. for Code
Execution attack), than such problem occurs. It's bug in IE (when there is
preceding comment tag), which I found when researching possibility of making
CE via XSS in IE. So I found the workaround for this bug - to set up this
option to Enabled or Prompt (for Local intranet).

> Then you say that:
> "if it's on other line (i.e. without preceding comment),
> then code will work and without this setting (Disable)"

I added this information (that it's possible to make this attack with
disabled option) for those, who will not happy with situation, when it's
needed to have this option in Enabled or Prompt state. Who want attack even
with this option disabled, than don't use this XSS hole, and use only social
engineering for making of an attack.

> My question is, if this attack works with disabling access to unsafe
> controls without "preceding comment", why use the preceding comment
> at all ?

I understand reasons of your question :-). It's because in this article I
didn't wrote in detail about Saved XSS hole in IE (I referred to original
post about it). When using this XSS, after saving page, IE put comment into
saved file (where XSS code is also put and here these hole appears). So with
this hole we always will have preceding comment. And with bug which
Microsoft made in IE :-) it'll be needed to use my patch for this bug
(setting this option).

> If I understood you correctly this only works if the page is saved to
> the harddisk and then run?.

Yes, these XSS and Code Execution via XSS attacks work only after saving
page to HDD and opening it in IE.

This is Saved XSS vulnerability. I wrote article about this type of XSS,
which you can read. This hole allows attacker to put XSS code to any web
site (which appears in the page after saving), which can increase chance of
saving page and its local opening.

Post Persistent XSS (Saved XSS) vulnerabilities
http://websecurity.com.ua/2641/

Its translation to English:
http://www.google.com/translate?u=ht...&hl=en&ie=UTF8

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message -----
From: "Thierry Zoller"
To: "MustLive"
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, November 26, 2008 9:35 PM
Subject: Re: XSS in Internet Explorer 6 and 7


> Dear MustLivee,
> M> Which is also
> M> available on English (http://securityvulns.ru/Udocument911.html).
>
> Refering to the above, could you briefly explain :
>
> ==============
> This attack works in Internet Explorer when option “Initialize and
> script ActiveX control not marked as safe” (for Local intranet) is turned
> on (Enabled or Prompt). It's such bug in hole of Microsoft :-) and it's
> method of bypassing of the bug. This setting is needed only during attack
> via this XSS, when JS code placed on the same line, where there is a
> comment. Because if it's on other line (i.e. without preceding comment),
> then code will work and without this setting (Disable). That can be
> achieved in case, when attack made not via XSS, but the attack code is
> placed (in appropriate way) directly in body of page.
> ==============
>
> Your saying above that this attack works if "Initialise and script
> ActiveX control not marked as safe" is ENABLED.
>
> Then you say that:
> "if it's on other line (i.e. without preceding comment),
> then code will work and without this setting (Disable)"
>
> My question is, if this attack works with disabling access to unsafe
> controls without "preceding comment", why use the preceding comment
> at all ?
>
> If I understood you correctly this only works if the page is saved to
> the harddisk and then run?.
>
>
>
>
>
>
>
> --
> http://secdev.zoller.lu
> Thierry Zoller