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:
Well, the problem with ADODB.Stream wasn't executing files, it was writing
them to disk. ...
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
... 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.
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,
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.
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
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
Indeed, as I've always said and as the US-CERT seems to have recently
come to realize too...
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854
Full-Disclosure - We believe in it.