VB6 and security in the Kill-Bit world
VB6 runtime support
In spite of being a rather old technology, Visual Basic 6 code is still among us - to a suprisingly large extent. Some usual places where you find VB6 these days:
· VB6 desktop applications and custom controls
· VB6 ActiveX controls hosted on Web sites or in desktop applications (including .NET applications)
· VB6 ActiveX controls in Office VBA aplications
The support for VB6 IDE has ended on 8. April 2008, but Microsoft is committed to further supporting the so-called Visual Basic 6.0 Runtime Extended Files, which include most of the VB6 Controls originally shipped with the VB6 IDE, in order to allow legacy VB6 code to run even on newer operating systems. The details are here:
https://msdn.microsoft.com/en-us/vbrun/ms788708.aspx
Kill-bits
Recently, we have seen an almost unprecedented effort in strengthening security on MS operating systems: as part of this effort, several vulnerabilities in the original releases in many VB6 ActiveX Controls have been discovered. The primary solution to address these issues was publishing several Security Bulletins and Advisories containing Kill-Bits for the vulnerable ActiveX controls. What a Kill-Bit is and how it works is explained here:
https://support.microsoft.com/default.aspx?scid=kb;EN-US;240797
In short:
· The "Compatibility Flags" register value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control is set to a bit mask that prevents the ActiveX control to be instantiated
· Optionally, an AlternateCLSID for a new version of the control in which the vulnerability has been fixed is provided. This allows the transparent instantiation of the new control via the old CLSID (the system is doing this redirection for you). There are some catches to this with licensing issues - as described below.
An important note: Kill-Bits do not only affect Internet Explorer - I have encountered this misunderstanding quite often. What applications respect the Kill-Bits - as well as a wealth of other infos on Kill-Bits - you can read here:
https://blogs.technet.com/srd/archive/2008/02/06/The-Kill_2D00_Bit-FAQ_3A00_-Part-1-of-3.aspx
https://blogs.technet.com/srd/archive/2008/02/06/The-Kill_2D00_Bit-FAQ_3A00_-Part-2-of-3.aspx
https://blogs.technet.com/srd/archive/2008/02/06/The-Kill_2D00_Bit-FAQ_3A00_-Part-3-of-3.aspx
What applications respect the Kill-Bit?
The Kill-Bit is respected in Internet Explorer (all zones) and also in Microsoft Office scenarios where objects are embedded within documents. The Kill-Bit should also be effective by default in any other application or platform that hosts the IE browser’s rendering engine (MSHTML).
In addition to the Kill-Bit mechanism per se, upgrading Kill-Bit-ed controls to new, unblocked versions using AlternateCLSIDs can also lead to licensing issues in applications that would otherwise ignore the Kill-Bit (as described below).
How can I be affected
If you are – maybe without even realizing - using VB6 components in applications on your computer/server, sooner or later you will probably come across Kill-Bits - either because you install one of the MS Security Bulletins containing Kill-Bits or because this is automatically installed by Windows Update (some of the vulnerabilities are rated critical, so installing the patches do by far more good than bad !)
Kill-Bits Security bulletins are cumulative, the most recent ist:
https://www.microsoft.com/technet/security/bulletin/ms09-032.mspx
What kill bits does this Cumulative Security Update of ActiveX Kill Bits contain?
This Cumulative Security Update of ActiveX Kill Bits contains all kill bits previously released in MS08-023, Security Update of ActiveX Kill Bits; MS08-032, Cumulative Security Update of ActiveX Kill Bits; and advisories entitled Update Rollup for ActiveX Kill Bits, Microsoft Security Advisory 953839, Microsoft Security Advisory 956391, Microsoft Security Advisory 960715, and Microsoft Security Advisory 969898.
So what do you do if one of the Kill-Bit Security Updates is breaking your application, web site or Office VBA code that uses VB6 Controls ? First of all, make sure the control that has stopped working is indeed part of the supported VB6 Runtime: you can look it up in the Cumulative Rollup for the VB6 SP6 Runtime Extended Files:
https://support.microsoft.com/kb/957924
This contains new versions of VB6 Controls that replace the old, vulnerable ones by redirecting them to AlternateCLSIDs so that the Kill-Bits are no longer blocking them. You need to get these updated versions o VB6 controls onto the affected computers.
At this point, there is one important mention to be made: you cannot simply install this patch on an affected machine - it will only install on a machine with a VB6 IDE license. The reason is simple: VB6 Controls are licensed controls that can only be redistributed by packing them in your VB6 application setup.
So how do you get the new VB6 Controls on the machines where KillBits have disabled your VB6 code functionality ? The answer is: it depends on the application.
1. A "pure" VB6 application or control running in a Kill Bit-unaware application can still run with killbit-ed VB6 Controls. However, it is still a good idea to install KB 957924 on the development machine with VB6 IDE, recompile your VB6 code there and the re-deploy your application with the new VB6 Controls.
The reason is that, if you don't recompile your code with the new controls from KB 957924 and later deploy these controls as part of a Kill Bit-aware applications that requires them, you will run into licensing issues on the target machines when running the VB6 app. This is because the runtime license for VB6 controls that is embedded in your old application or custom control is not valid for the new version of the control, which has a different CLSID. Therefore, when you run the app on the target machine, the runtime license will be invalid and - if no design-time license is present, which should only be the case on a machine with VB6 IDE - the instantiation of the control will fail and you will most probably see something like this:
The morale is: simply recompile your VB6 code with KB 957924 controls, redeploy and save yourself the hassle.
2. If you are hosting VB6 controls on a web site, you will need to deploy the KB 957924 controls and, additionally, you will run into the LPK (license file for hosting in IE) issue as described here:
Currently, the only workaround is to call Microsoft Support and get an updated LPK file for the controls. As the above blog post suggests, some work is currently done on the Internet Explorer client side to enable instantiation with the old LPK file and alleviate the issue.
3. If you have issues with Office VBA components (which are Kill-Bit aware !), read this excellent blog post from the Visual Studio Office Dev Team here:
The preferred way to deal with this is to rebuild your Office VBA component on a VB6 machine with the updated controls.
Other resources:
· Stay updated on Security Updates and bulletins on the Microsoft Security Research & Defense blog: https://blogs.technet.com/srd/