The exploitation of ActiveX controls is not new to the security community. While initially designed to provide website authors with new embeddable features, and granting Internet Explorer (IE) users access to these new functional capabilities, the liabilities and damages, have almost surpassed its benefits. Websites have been avoided and blocked, and alternative browsers to IE adopted. In response to the frequently discovered vulnerabilities, numerous workarounds and security patches have been created.
Although, frequently I come across people who are adept at implementing corresponding security policies and protocols, and can regurgitate words from Microsoft advisories, but don’t really understand the mitigation of ActiveX issues. Due to Microsoft’s recent “multi-rated” security bulletin, fixing Yahoo! Music Jukebox vulnerability, I thought this would be an opportune time to discuss “kill bits” and ActiveX security.
In order for your browser to interpret a webpage’s content, it must determine if the necessary Active X controls are installed on the system. This is achieved by looking at the object tag in the page and extracting its CLSID (Class ID), unique to each ActiveX component. The CLSID is a 128-bit UUID, designated by Microsoft, to identify objects registered by their applications. If the system possesses the control, then the page is properly displayed, otherwise, the URL to the required software is referenced, and a message prompting the user to download the necessary control appears.
The central database for all system settings is contained in the registry, which stores this data as values, within its keys. The CLSID key contains thousands of different ActiveX control IDs. For example, the ActiveX control for Real Player can be found at:
HKEY_CLASSES_ROOTCLSID{CFCDAA03-8BE4-11CF-B84B-0020AFBBCCFA}
Specifically, certain CLSID subkeys will mark the control as “safe for scripting” or “safe for initialization”, which indicates that it can be instantiated by a website from within IE. However, controls without these subkey classifications, can still be loaded by way of the browser.
The ActiveX controls, which are designated to permit IE to run the interactive content from a website, can be located by their CLSID in a different registry location. For example, the IE compatible ActiveX control for Real Player can be found at:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftInternet ExplorerActiveX Compatibility{CFCDAA03-8BE4-11cf-B84B-0020AFBBCCFA}
This location displays the DWORD value for the Compatibility Flag of the control. Setting this to a hex value of 400 disables its control. If this flag doesn’t exist, than it can be created– “Compatibility Flags”=dword:00000400. This is also called the “kill bit” and prevents the control from being loaded by IE. Since it is really manipulating a hex registry value, and not a bit, it seems to be a misnomer of sorts.
When an ActiveX vulnerability is first discovered, setting a kill bit is often a first measure used, until a code fix is issued. The recent vulnerability with RealPlayer, by Elazar Broad, initially required the use of a kill bit for ActiveX supported browsers. Later, the vendor released RealPlayer 11.0.2, which addressed this issue. However, the type and source of the ActiveX control, often influences the security imposed.
Using kill bits as a sole means of security, as opposed to writing secure code, is not an effective long term solution. In March of 2007, with the move to MSXML 6, Microsoft intended to implement a kill bit for MSXML 4. However, due to the large number of MSXML 4 users, they decided to reverse this decision, and instead release an updated binary that fixed the security issues.
However, there are times when it can be useful. Microsoft has allowed vendors to request kill bit fixes into their updates, as recently demonstrated by Yahoo for its Music Jukebox. Furthermore, it has been used as a means of blocking spyware.
Given a scenario in which a website, an often unreliable source, is permitted to manipulate host and application controls, restrictive mechanisms are necessary. Even if all scripting components are updated, kill bits can be used to ensure older, vulnerable versions aren’t exploited. If the old ActiveX control resides on the system, then the kill bit prevents a malicious site from using the old version-if it’s not on the system, it prevents the nefarious installation and scripting of an older control, authorized by the user from a “trustworthy” source. Thanks, Authenticode.
Even with a kill bit, one must consider situations where it’s not supported. In this case, fixing the code is necessary to prevent exploits. Although, in a supported environment, it is still necessary to employ when using fixed code. When providing the fixed code in the form of a version update, a new CLSID must be assigned to the updated control. Although, this poses a problem for websites continuing to reference the previous ActiveX control with the old CLSID. This is solved through the use of a “Phoenix Bit”, named after the infamous X-Men character. The Phoenix Bit is actually a registry entry called AlternateCLSID, which is set at the same level of the Compatibility Flag in the old CLSID key. When navigating to a page that still refers to the old CLSID, IE will see the AlternateCLSID flag, redirecting it to the new CLSID, and will use the updated ActiveX control.
Further advances in ActiveX security demonstrate many uses of kill bits. A GUI kill bit application has been developed to assist with ActiveX security issues, due to the recent buffer overflow vulnerabilities discovered in the image uploader used by FaceBook and MySpace.
With the dominance of IE as a web browser and the proliferation of ActiveX controls, this will continue to be a security issue. Automated fuzzers have been developed for ActiveX vulnerability discovery and testing. Two good applications are HD Moore’s powerful AxMan, and iDefense Labs’ user-friendly COMRaider. For those who like to spend more time under the hood of their OS, numerous tools exist for manual auditing, such as, Process Explorer, RegMon, FileMon, TCPView, OLEVIEW, and TSTCON.
Regardless of a website’s reputation, put a little security thought into your decision to download that much needed ActiveX component, or just revert back to Mosaic.
To maximize your reading experience of this blog, please download the “Blog Viewer” ActiveX control. Send your killed bits to: greyhat@computer.org
