Silently Pwning Protected-Mode IE9 and Innocent Windows Applications

Those familiar with Windows COM servers know that they come in two types, in-process and out-of-process. For this post, the former type is of interest: an in-process COM server is a dynamic link library (DLL) that a COM client instantiates when needed, usually by calling the CoCreateInstance function with the class identifier (CLSID) of the said COM server. What happens then is the COM server initialization code looks up the provided CLSID in local registry under key HKEY_CLASSES_ROOT\CLSID, and finds the path to the DLL under the InProcServer32 subkey. It then expands eventual environment strings in the obtained DLL path and calls LoadLibrary with the resulting path. Whatever happens afterwards is of no interest to us here.

From the binary planting perspective the above process would be vulnerable if both of the following conditions were met:

1. the path to the COM server DLL is a relative path instead of an absolute one; and
2. the DLL doesn't exist in the LoadLibrary search path prior to the current working directory (i.e., in COM client's home directory or any one of the Windows system folders).  

Condition #1 is at the discretion of whoever registers the COM server. While most COM servers are registered with full absolute paths to their DLLs, some merely specify the name of the DLL without the path. This may not be due to a developer's oversight or laziness: the so-called side-by-side COM components (see here and here) require the DLL to be specified with a relative path.

Condition #2 is a bit more tricky as it seems unlikely, at the first glance, that someone - or some application - would register a COM server that doesn't exist on the system. But for reasons beyond our willingness to investigate, some software products do just that. Furthermore, some other software products fail to unregister their COM servers upon removal, leaving the user's computer with exploitable remnants of a removed COM server DLL. And finally, in the case of side-by-side COM components, these DLLs are successfully found and loaded when the COM server is invoked by the original application (the DLL is in the same folder as the COM client executable), but if another applications tries to invoke the same COM server, it won't find the DLL and will finally try to find it in the current working directory - to attacker's great satisfaction.

Read more: Acros

Posted via email from Jasper-net