在安全补丁Security Advisory 960715 更新之后 ACCESS或Visual B

 

Summary of the issue: After installing security advisory 960715 and opening a workbook with one of Visual Basic 6 ActiveX controls embedded in the workbook you receive an error:
“Object library invalid or contains references to object definitions that could not be found” or “Element not found.”
See Microsoft security bulletin MS08-070 article 932349 for more information regarding this error:
MS08-070: Vulnerabilities in Visual Basic 6.0 Runtime Extended Files (ActiveX Controls) could allow remote code execution.
Please refer to the “Known issues with this security update” in the “More Information” section.
<<<Update 4th March 2010: Begin>>>
 
It is important to remember that the security update stated in this blog, 960715, will be included in all subsequent Cumulative Updates of ActiveX Kill Bits. Check the Frequently Asked Questions of the CU KB article that’s affecting you to see if it is included.
 
<<<Update 4th March 2010: End>>>
Cause: The security advisory listed above sets the kill bit for the following Visual Basic 6 ActiveX controls.
The VB6 controls affected are:

File Name	Control Name	Class Identifier (CLSID)
Comct232.ocx	Windows Common Controls	{1E216240-1B7D-11CF-9D53-00AA003C9CB6}
Mschrt20.ocx	Chart Control (OLEDB)	{3A2B370C-BA0A-11d1-B137-0000F8753F5D}
Mscomct2.ocx	Windows Common Controls-2	{B09DE715-87C1-11d1-8BE3-0000F8754DA1}
Msdatgrd.ocx	DataGrid Control 6.0 (OLEDB)	{cde57a43-8b86-11d0-b3c6-00a0c90aea82}
Msflxgrd.ocx	FlexGrid Control 6.0	{6262d3a0-531b-11cf-91f6-c2863c385e30}
Mshflxgd.ocx	Hierarchical FlexGrid Control	{0ECD9B64-23AA-11d0-B351-00A0C9055D8E}
Msmask32.ocx	Masked Edit Control	{C932BA85-4374-101B-A56C-00AA003668DC}
MSWinsck.ocx	Winsock Control 6.0	{248dd896-bb45-11cf-9abc-0080c7e7b78d}

Theses kill bits were necessary because of security vulnerabilities found within these controls and addressed in Microsoft security bulletin MS08-070 http://www.microsoft.com/technet/security/Bulletin/ms08-070.mspx
 
To ensure that the correct ActiveX control is being used Microsoft had disabled the particular GUID or “kill bit” the control. Setting the kill bit makes sure that even if a vulnerable component (i.e. malicious code) is introduced or is re-introduced to a system, it remains inert and harmless. Kill-Bits must be issued to prevent old / vulnerable signed versions of controls from being effectively imposed on users. Even if you have a fixed version of the control on your system, a renamed and signed DLL or OCX served from a malicious web page can revert the machine to an insecure state. The software vendor cannot just update the control with the same GUID because there is no way ensure that control in use is the updated control.
For more information about the kill bit for ActiveX controls, see the following Microsoft Security Vulnerability Research & Defense Blog posts:
The Kill-Bit FAQ: Part 1 of 3 
http://blogs.technet.com/swi/archive/2008/02/06/The-Kill_2D00_Bit-FAQ_3A00_-Part-1-of-3.aspx
The Kill-Bit FAQ: Part 2 of 3 
http://blogs.technet.com/swi/archive/2008/02/07/The-Kill_2D00_Bit-FAQ_3A00_-Post-2-of-3.aspx
The Kill-Bit FAQ: Part 3 of 3 
http://blogs.technet.com/swi/archive/2008/02/08/The-Kill_2D00_Bit-FAQ_3A00_-Part-3-of-3.aspx
To resolve this issue you must update the development computer with updated controls and then update the controls on the client computer. Please see step by step instructions below.
On Development Computer
1. Install the Microsoft Visual Basic 6.0 Service Pack 6 Cumulative Updatehttp://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cb824e35-0403-45c4-9e41-459f0eb89e36
2. Delete the cached versions of the control type libraries (extender files). To do this, search your hard drive for ".exd," and delete all the .exd files. The .exd files will be re-created automatically using the new controls the next time that you use VBA. The extender files will reside under the users profile and may reside in multiple locations such as:
C:\documents and settings\username\Application Data\Microsoft\Forms
C:\documents and settings\username\AppData\Local\Temp\VBE
Note that you can search the "HKEY_CLASSES_ROOT\TypeLib" key in the registry using the search term "exd" to find the locations where the extender files reside.
3. Open the Excel workbook with the ActiveX control.
4. Open the Visual Basic Editor and under Debug click “Compile VBAProject”
5. Then save and redeploy the updated workbook
Note: If you do not recompile the project on the development computer that has a design time license for the control. When you open the open the workbook on a client computer you will receive the following error “License information for this component not found. You do not have an appropriate license to use this functionality in the design environment.” This is because the runtime time license is stored with the ActiveX control within the workbook and by re-compiling the control on the development computer the run time license is correctly updated.
On Client Computer
1. Delete the cached versions of the control type libraries (extender files). To do this, search your hard drive for ".exd," and delete all the .exd files. The .exd files will be re-created automatically using the new controls the next time that you use VBA. The extender files will reside under the users profile and may reside in multiple locations such as:
C:\documents and settings\username\Application Data\Microsoft\Forms
C:\documents and settings\username\AppData\Local\Temp\VBE
Note that you can search the "HKEY_CLASSES_ROOT\TypeLib" key in the registry using the search term "exd" to find the locations where the extender files reside.
2. Download the update control from the URL associated with the problem control into a browser window (see list below).
COMCT232.OCX - http://activex.microsoft.com/controls/vb6/comct232.cab 
MSCHRT20.OCX - http://activex.microsoft.com/controls/vb6/mschrt20.cab 
MSCOMCT2.OCX - http://activex.microsoft.com/controls/vb6/mscomct2.cab 
MSDATGRD.OCX - http://activex.microsoft.com/controls/vb6/msdatgrd.cab 
MSFLXGRD.OCX - http://activex.microsoft.com/controls/vb6/msflxgrd.cab 
MSHFLXGD.OCX - http://activex.microsoft.com/controls/vb6/mshflxgd.cab 
MSMASK32.OCX - http://activex.microsoft.com/controls/vb6/msmask32.cab 
MSWINSCK.OCX - http://activex.microsoft.com/controls/vb6/mswinsck.cab
3. When prompted, choose to Save the file to client computer.
4. Extract the files from the .CAB
5. Browse to the location of the extracted files.  Right-click on the .INF file, 
and choose 'Install' (this should take a matter of a couple of seconds and there 
will be no confirmation message)
6. Click on Start, then Run, type in 'regsvr32 <OCXNAME>.ocx' (excluding quotes, 
substituting the name of the control that was just installed) and click on 'OK'.
7. A message stating the 'DllRegisterServer in <controlname>.ocx succeeded.'  
Click 'OK'.
8. Open the re-complied workbook to ensure that the control is working.
Other options
There are two additional workarounds
1. Remove the kill bit for the ActiveX control; this means that the security vulnerabilities are still exposed. (this is not recommended)
2. To remove the AlternateCLSID and keep the Kill Bit; this will cause the control not to load.
When security advisory 960715 is applied, the following two registry keys are added for each control listed above. Example:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\
{CLSID of killed ActiveX control}, Compatibility Flags, 0x0400
*This is the actual Kill Bit, 0x400, which is “COMPAT_EVIL_DONT_LOAD” which means the control is never used.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\
{CLSID of killed ActiveX control}
This registry key is referred to as the Phoenix-Bit, a.k.a AlternateCLSID. Since a Kill-Bit completely prevents a control from loading, this key points to the updated controls GUID.
Workaround one
Change the Compatibility Flags to 0x00800000 which means Safe for Loading. The information regarding Compatibility Flags can be found at http://msdn.microsoft.com/en-us/library/aa768234.aspx
Workaround Two
Remove the AlternateCLSID registry key, this will remove the control from the form.
*With both of these workarounds, once you install the check security advisory, you must make the same changes again because registry keys revert to the Kill bit behavior.
 
(Author: Lee Kohrman)