From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Betr.: Re: Fix for IE ADODB.Stream vulnerability
 is out

"Matthew Murphy" wrote:

<<snip>>
> Well, the problem with ADODB.Stream wasn't executing files, it was writing
> them to disk.  ...

Exactly.

ADODB.Stream is just doing what it is supposed to.  The "problem" is 
that code loaded from "the Internet zone" is just not supposed to be 
allowed to get access to this object (or any other with similarly 
"dangerous" functionality).

> ...  However, as you correctly point out, there are plenty of
> ActiveX components on an average Windows system that are deliberately marked
> *unsafe* because of the functionality they offer, and they *should not* be
> invoked by a browsing interface for any purpose -- regardless of the trust
> level associated with them.

Exactly.

> So, the point of this is that we shouldn't cripple individual components, as
> that is a ridiculous cat-and-mouse game that Microsoft cannot win,

Precisely...

> particularly as slow as it is to react to this sort of thing.  We've been
> talking about the risks of this particular component for months, but
> Microsoft did what... nothing.

Which was, in fact, the right thing to do.

After all, ADODB.Stream is just doing what it is supposed to do.  The 
fact that it has been used in various ways by code accessed through 
what IE should have considered the relatively untrusted "Internet zone" 
but didn't is the main problem.

There is a deeper problem to though...

How many other controls that MS ships are known (or easily found) to be 
able to step into ADODB.Stream's shoes?

If MS had a clue about what it was doing, it should not have taken the 
"break ADODB.Stream" approach, but instead done something useful to 
address  the underlying problem.  Something like ship an emergency 
update that replaces whatever .DLL with one that has stub routines to 
bypass the real core of the problem -- yep, it will break lots of 
stuff, but that just may be the price you have to pay if you accept the 
level of dangerous "extra" functionality and integration that is 
silently packaged up in Billy Boy's vision of computing.

Of course, marketing and the corporate spin-doctors at MS would never 
actually allow that approach, so we yet again see the true weight of 
MS' commitment to its much touted "security initiative", where security 
was reputedly going to trump functionality.  Obviously that brave new 
vision of Bill's didn't extend as far as a security stance where 
transparency and honesty trump marketing and BS as well...

> The real fault doesn't belong with individual components (ADODB.Stream
> included), and I think the almost rant-like posts of Drew Copeley and
> HTTP-EQUIV miss this fact.  ADODB.Stream does *not* represent a
> vulnerability, although it does act to significantly worsen the impact of an
> existing one, by allowing transfer of binary files to targets.  However, the
> same functionality as ADODB.Stream could be accomplished by simply altering
> the open-restrictions registry value that IE uses for executable files
> (that's right -- the hardcoded warning required behavior isn't hardcoded at
> all), and then invoking IE to do this for you.
<<snip example>>

Indeed.

And there are most likely very many other ways to skin this cat -- 
after all, the real problem is that, as US-CERT was recently moved to 
comment (http://www.kb.cert.org/vuls/id/713878) "[t]here are a number 
of significant vulnerabilities in technologies relating to the IE 
domain/zone security model, the DHTML object model, MIME type 
determination, and ActiveX"...

A clever or motivated spammer or more focussed attacker need only find 
one of many possible combinations of those known flaws and approaches 
to quickly devise an attack that will beat your IE installation, 
leading one to the realization that, as the US-CERT said in its next 
sentence "[i]t is possible to reduce exposure to these vulnerabilities 
by using a different web browser, especially when browsing untrusted 
sites".

> This demo may contain bugs, and was somewhat hastily cobbled together (not
> intended to be used verbatim in code, only demonstrate theory), but you get
> the idea: given full ActiveX access, you can do huge amounts of damage,

Indeed.  It has always intrigued me that every attack we have seen so 
far has, once it got its code into the "local security zone", stuck to 
using the same local zone "exploits" when they have the whole gamut of 
(safe-for-scripting) ActiveX controls at their disposal.  (Actually, it 
doesn't surprise me at all -- it is simply evidence that very many of 
these "attackers" are not actually that clever and depend on copying 
the PoC exploits published by those who find, or at least publicize, 
these kinds of problems.)

> particularly if the user visiting you is an admin.  However, this isn't a
> significant setback, as the exploits in-the-wild that overwrite wmplayer.exe
> require the same privilege level.

Of course, this is the where the extreme security-awareness of your 
typical XP Home comes to the fore...

> The real fault in this case most definitely does belong with Microsoft (few
> will argue that, and none will persuasively argue it, otherwise), but for
> the reason that its browser simply allows too much access to system internal
> components.

Indeed, as I've always said and as the US-CERT seems to have recently 
come to realize too...


-- 
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854

Powered by blists - more mailing lists