New IE Exploit

This one is brand new, and MS is probably only just looking at it now. Note that
although the current discussions center on Windows XP SP2 and/or Internet
Explorer 6 SP2, it would seem to me that *any* version of IE is similarly
vulnerable.

A temporary workaround is easy, though, provided you aren't afraid of the
Registry:

In REGEDIT, locate the following key:
HKEY_Local_Machine\Software\Microsoft\Internet Explorer\Active-X Compatibility\
{8856F961-340A-11D0-A96B-00C04FD705A2}
(I went to the parent key, then used Find from the Edit menu to make it easy.)

Change the DWORD value named "Compatibility Flags" to 00000400.

At least one MVP has already run into the exploit, but noticed something amiss
and aborted the invasion. For further reference see:

"Security Focus"
http://www.securityfocus.com/bid/11467/info/

"How to Stop an ActiveX Control from Running in Internet Explorer"
http://support.microsoft.com/?kbid=240797

--
Gary S. Terhune
MS MVP Shell/User

Interesting. From my memory, this sure sounds like something that was
addressed in an earlier Windows Security Update - the one that also
prevented the Windows 98 Troubleshooters from working, or something like
that? It too was associated with ActiveX compatability, and a similar
DWORD flag value (as I recall). Wonder what I'm getting this confused
with????


Gary S. Terhune wrote:
This one is brand new, and MS is probably only just looking at it now.
Note
that although the current discussions center on Windows XP SP2 and/or
Internet
Explorer 6 SP2, it would seem to me that *any* version of IE is similarly
vulnerable.

A temporary workaround is easy, though, provided you aren't afraid of the
Registry:

In REGEDIT, locate the following key:
HKEY_Local_Machine\Software\Microsoft\Internet Explorer\Active-X
Compatibility\ {8856F961-340A-11D0-A96B-00C04FD705A2}
(I went to the parent key, then used Find from the Edit menu to make it
easy.)

Change the DWORD value named "Compatibility Flags" to 00000400.

At least one MVP has already run into the exploit, but noticed something
amiss
and aborted the invasion. For further reference see:

"Security Focus"
http://www.securityfocus.com/bid/11467/info/

"How to Stop an ActiveX Control from Running in Internet Explorer"
http://support.microsoft.com/?kbid=240797

--
Gary S. Terhune
MS MVP Shell/User

It's a common type of vulnerability. The one you "remember" probably involved a
different ActiveX control. Note that the workaround doesn't truly fix the
problem, it just makes it irrelevant by disabling that particular ActiveX
control. I don't know what that one is used for, but we'll soon find out if it's
one of the more popular ones.

--
Gary S. Terhune
MS MVP Shell/User

"Bill in Co." wrote in message
...
Interesting. From my memory, this sure sounds like something that was
addressed in an earlier Windows Security Update - the one that also
prevented the Windows 98 Troubleshooters from working, or something like
that? It too was associated with ActiveX compatability, and a similar
DWORD flag value (as I recall). Wonder what I'm getting this confused
with????

OK, that makes sense. It *would* be nice to know which specific control
they are disabling, and what specifically initiated this.

Gary S. Terhune wrote:
It's a common type of vulnerability. The one you "remember" probably
involved
a different ActiveX control. Note that the workaround doesn't truly fix
the
problem, it just makes it irrelevant by disabling that particular ActiveX
control. I don't know what that one is used for, but we'll soon find out
if
it's one of the more popular ones.

--
Gary S. Terhune
MS MVP Shell/User

"Bill in Co." wrote in message
...
Interesting. From my memory, this sure sounds like something that was
addressed in an earlier Windows Security Update - the one that also
prevented the Windows 98 Troubleshooters from working, or something like
that? It too was associated with ActiveX compatability, and a similar
DWORD flag value (as I recall). Wonder what I'm getting this confused
with????

The Secure Response write-up has some further info, but the MVP source mentions
having to visit a site that employs the exploit, that you don't notice the
anomalies in behavior, and that once you've rebooted once or twice your machine
is laid wide open.

--
Gary S. Terhune
MS MVP Shell/User

"Bill in Co." wrote in message
...
OK, that makes sense. It *would* be nice to know which specific control
they are disabling, and what specifically initiated this.

Gary S. Terhune wrote:
It's a common type of vulnerability. The one you "remember" probably
involved
a different ActiveX control. Note that the workaround doesn't truly fix
the
problem, it just makes it irrelevant by disabling that particular ActiveX
control. I don't know what that one is used for, but we'll soon find out
if
it's one of the more popular ones.

--
Gary S. Terhune
MS MVP Shell/User

"Bill in Co." wrote in message
...
Interesting. From my memory, this sure sounds like something that was
addressed in an earlier Windows Security Update - the one that also
prevented the Windows 98 Troubleshooters from working, or something like
that? It too was associated with ActiveX compatability, and a similar
DWORD flag value (as I recall). Wonder what I'm getting this confused
with????

OK, I went to the MS web page, and I'll paste some more info on it here, for
anyone who is interested: from:
http://www.securityfocus.com/bid/11467/discussion/

Microsoft Windows XP SP2 and Internet Explorer 6 SP2 have enhanced Local
Zone security restrictions to prevent various exploits that depend on the
previous relaxed security settings associated with this Security Zone. A
proof-of-concept has been released demonstrating that it is possible to
bypass these restrictions through the use of the 'hhctrl.ocx' HTML ActiveX
control.

It has been previously reported that this issue required a second issue
(namely BID 11466) to place malicious code onto the affected computer.
However this has recently been shown to be untrue; this issue alone may be
used to execute code in the Local Zone.

It is possible for an attacker to use the 'hhctrl.ocx' HTML ActiveX control
object to place and execute arbitrary code on the Local Zone of the affected
computer; this is possible due to the ability of the attacker to inject
script code into a help pop-up window that resides in the Local Zone.

The original proof-of-concept that uses the issue outlined in BID 11466, as
well as the later proof of concepts employ various ADODB methods such as
ADODB.Connection and ADODB.recordset to write malicious arbitrary code to
the file system, in the form of an '.HTA' type file.


Gary S. Terhune wrote:
The Secure Response write-up has some further info, but the MVP source
mentions having to visit a site that employs the exploit, that you don't
notice the anomalies in behavior, and that once you've rebooted once or
twice
your machine is laid wide open.

--
Gary S. Terhune
MS MVP Shell/User

"Bill in Co." wrote in message
...
OK, that makes sense. It *would* be nice to know which specific control
they are disabling, and what specifically initiated this.

Gary S. Terhune wrote:
It's a common type of vulnerability. The one you "remember" probably
involved a different ActiveX control. Note that the workaround doesn't
truly fix the problem, it just makes it irrelevant by disabling that
particular ActiveX control. I don't know what that one is used for, but
we'll soon find out if it's one of the more popular ones.

--
Gary S. Terhune
MS MVP Shell/User

"Bill in Co." wrote in message
...
Interesting. From my memory, this sure sounds like something that was
addressed in an earlier Windows Security Update - the one that also
prevented the Windows 98 Troubleshooters from working, or something
like
that? It too was associated with ActiveX compatability, and a
similar
DWORD flag value (as I recall). Wonder what I'm getting this
confused
with????

Thanks for the information, Gary Terhune. Would using Mozilla Firefox as
your default browser and thus going to the dangerous page through Firefox
allow this vulnerability to be executed on a Microsoft Windows operating
system or would you have to go to the page with Internet Explorer?

"Gary S. Terhune" wrote in message
...
This one is brand new, and MS is probably only just looking at it now.
Note that
although the current discussions center on Windows XP SP2 and/or
Internet
Explorer 6 SP2, it would seem to me that *any* version of IE is
similarly
vulnerable.

A temporary workaround is easy, though, provided you aren't afraid of
the
Registry:

In REGEDIT, locate the following key:
HKEY_Local_Machine\Software\Microsoft\Internet Explorer\Active-X
Compatibility\
{8856F961-340A-11D0-A96B-00C04FD705A2}
(I went to the parent key, then used Find from the Edit menu to make it
easy.)

Change the DWORD value named "Compatibility Flags" to 00000400.

At least one MVP has already run into the exploit, but noticed
something amiss
and aborted the invasion. For further reference see:

"Security Focus"
http://www.securityfocus.com/bid/11467/info/

"How to Stop an ActiveX Control from Running in Internet Explorer"
http://support.microsoft.com/?kbid=240797

--
Gary S. Terhune
MS MVP Shell/User

But to be honest, I'm not certain. You'd have to ask someone who knows about
Firefox.

--
Gary S. Terhune
MS MVP Shell/User

"Dan" wrote in message
...
Thanks for the information, Gary Terhune. Would using Mozilla Firefox as
your default browser and thus going to the dangerous page through Firefox
allow this vulnerability to be executed on a Microsoft Windows operating
system or would you have to go to the page with Internet Explorer?

"Gary S. Terhune" wrote in message
...
This one is brand new, and MS is probably only just looking at it now.
Note that
although the current discussions center on Windows XP SP2 and/or
Internet
Explorer 6 SP2, it would seem to me that *any* version of IE is
similarly
vulnerable.

A temporary workaround is easy, though, provided you aren't afraid of
the
Registry:

In REGEDIT, locate the following key:
HKEY_Local_Machine\Software\Microsoft\Internet Explorer\Active-X
Compatibility\
{8856F961-340A-11D0-A96B-00C04FD705A2}
(I went to the parent key, then used Find from the Edit menu to make it
easy.)

Change the DWORD value named "Compatibility Flags" to 00000400.

At least one MVP has already run into the exploit, but noticed
something amiss
and aborted the invasion. For further reference see:

"Security Focus"
http://www.securityfocus.com/bid/11467/info/

"How to Stop an ActiveX Control from Running in Internet Explorer"
http://support.microsoft.com/?kbid=240797

--
Gary S. Terhune
MS MVP Shell/User

Alright, I will. It will be interesting to see if both browsers are
affected.

"Gary S. Terhune" wrote in message
...
But to be honest, I'm not certain. You'd have to ask someone who knows
about
Firefox.

--
Gary S. Terhune
MS MVP Shell/User

"Dan" wrote in message
...
Thanks for the information, Gary Terhune. Would using Mozilla
Firefox as
your default browser and thus going to the dangerous page through
Firefox
allow this vulnerability to be executed on a Microsoft Windows
operating
system or would you have to go to the page with Internet Explorer?

"Gary S. Terhune" wrote in message
...
This one is brand new, and MS is probably only just looking at it
now.
Note that
although the current discussions center on Windows XP SP2 and/or
Internet
Explorer 6 SP2, it would seem to me that *any* version of IE is
similarly
vulnerable.

A temporary workaround is easy, though, provided you aren't afraid
of
the
Registry:

In REGEDIT, locate the following key:
HKEY_Local_Machine\Software\Microsoft\Internet Explorer\Active-X
Compatibility\
{8856F961-340A-11D0-A96B-00C04FD705A2}
(I went to the parent key, then used Find from the Edit menu to
make it
easy.)

Change the DWORD value named "Compatibility Flags" to 00000400.

At least one MVP has already run into the exploit, but noticed
something amiss
and aborted the invasion. For further reference see:

"Security Focus"
http://www.securityfocus.com/bid/11467/info/

"How to Stop an ActiveX Control from Running in Internet Explorer"
http://support.microsoft.com/?kbid=240797

--
Gary S. Terhune
MS MVP Shell/User

REGEDIT4

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX
Compatibility\{8856F961-340A-11D0-A96B-00C04FD705A2}]
"Compatibility Flags"=dword:00000021

Mine does not have a dash (-) in "ActiveX". It was a DWORD x'21'. Now, I
have changed it to x'400' & haven't blown up yet. But I haven't done any
Internet clicking!


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"Bill in Co." wrote in message
...
| OK, I went to the MS web page, and I'll paste some more info on it
here, for
| anyone who is interested: from:
| http://www.securityfocus.com/bid/11467/discussion/
|
| Microsoft Windows XP SP2 and Internet Explorer 6 SP2 have enhanced
Local
| Zone security restrictions to prevent various exploits that depend on
the
| previous relaxed security settings associated with this Security Zone.
A
| proof-of-concept has been released demonstrating that it is possible
to
| bypass these restrictions through the use of the 'hhctrl.ocx' HTML
ActiveX
| control.
|
| It has been previously reported that this issue required a second
issue
| (namely BID 11466) to place malicious code onto the affected computer.
| However this has recently been shown to be untrue; this issue alone
may be
| used to execute code in the Local Zone.
|
| It is possible for an attacker to use the 'hhctrl.ocx' HTML ActiveX
control
| object to place and execute arbitrary code on the Local Zone of the
affected
| computer; this is possible due to the ability of the attacker to
inject
| script code into a help pop-up window that resides in the Local Zone.
|
| The original proof-of-concept that uses the issue outlined in BID
11466, as
| well as the later proof of concepts employ various ADODB methods such
as
| ADODB.Connection and ADODB.recordset to write malicious arbitrary code
to
| the file system, in the form of an '.HTA' type file.
|
|
| Gary S. Terhune wrote:
| The Secure Response write-up has some further info, but the MVP
source
| mentions having to visit a site that employs the exploit, that you
don't
| notice the anomalies in behavior, and that once you've rebooted once
or
| twice
| your machine is laid wide open.
|
| --
| Gary S. Terhune
| MS MVP Shell/User
|
| "Bill in Co." wrote in message
| ...
| OK, that makes sense. It *would* be nice to know which specific
control
| they are disabling, and what specifically initiated this.
|
| Gary S. Terhune wrote:
| It's a common type of vulnerability. The one you "remember"
probably
| involved a different ActiveX control. Note that the workaround
doesn't
| truly fix the problem, it just makes it irrelevant by disabling
that
| particular ActiveX control. I don't know what that one is used
for, but
| we'll soon find out if it's one of the more popular ones.
|
| --
| Gary S. Terhune
| MS MVP Shell/User
|
| "Bill in Co." wrote in message
| ...
| Interesting. From my memory, this sure sounds like something
that was
| addressed in an earlier Windows Security Update - the one that
also
| prevented the Windows 98 Troubleshooters from working, or
something
| like
| that? It too was associated with ActiveX compatability, and a
| similar
| DWORD flag value (as I recall). Wonder what I'm getting this
| confused
| with????
|
|