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.
