Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Betr.: Re: Fix for IE ADODB.Stream vulnerability is out
From: Nick FitzGerald <nick () virus-l demon co uk>
Date: Sat, 03 Jul 2004 17:30:52 +1200

"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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]