Kurt Seifried wrote Friday, November 07, 2003 4:38 PM

> In other words no good methods for enumerating CLSID's seem to exist.

Doesn't HKLM\Software\Classes\(control name)\CLSID do the job OK?
You can also search HKLM\Software\Classes\ for the control name - it will
turn up another listing under (CLSID). This key is useful because it
specifies both the ProgID (specific version of the control) and the
VersionIndependentProgID if there is one.

Speaking of which, other ADODB.Stream control versions are listed in Classes
on machines that have been updated with various versions of MDAC:
ADODB.Stream.2.5
ADODB.Stream.2.7
etc.

These also work just fine in the malware script. Substitute
"Adodb.Stream.2.5" for "Adodb.Stream" in the script if the target machine
has ever had MDAC 2.5 installed - 2.7 is probably a better target because
IIRC it was a Critical Update that is likely to be installed on patched
machines. I'm too lazy to verify this.

This is not an additional vulnerability unless Microsoft somehow fails to
take these into acccount when they someday patch IE against http-equiv's
exploit, but it can be used to bypass overly explicit detection of
http-equiv's code. The CLSID for the version-specific object names is the
same as the version-independent ADODB.Stream, so the same kill bit entry
will kill them.

I think setting the kill bit for ADODB.Stream will cause collateral damage
in some environments. For instance Intranet ASP pages that incorporate file
downloads will be killed if the pages were build using ADO.

[ reply ]