5 of 11Image
Microsoft's ActiveX technology seemed like a very bright idea in 1996, when the World Wide Web was still shiny and new. ActiveX controls were helper programs that could be called by a local app or a Web browser for a specific function. But the architects who dreamed up ActiveX didn't think of its consequences on PC security. The results over the next 10 years or so were disastrous. Today, if you ask a computer security professional or an IT pro about ActiveX, they'll probably just roll their eyes and groan.
The subject came up last year when I criticized Adobe's record on security. Several readers pointed out, quite reasonably, that the same Symantec report I referenced in that post said that "ActiveX technologies still constituted the majority of new browser plug-in vulnerabilities [in 2009], with 134." And indeed, for years after XP's introduction Microsoft was continuing to deal with the fallout of ActiveX insecurity.
Initially, ActiveX provided a convenient way for crooks to sneak malware onto Windows PCs. These were classic social engineering attacks, with malware disguised as a required update to play media files, for example.
Microsoft dealt with those But then, in June 2009, the mother of all ActiveX vulnerabilities was discovered. This is the infamous MSCOMM32.OCX ATL Loader Remote Code Execution Vulnerability (CVE-2008-0024). The problem was found in a template file that was included with Microsoft Visual Basic. In its security advisory, IBM Internet Security Systems rated its exploitability as "high" and described what made the problem so acute:
Although this ActiveX control is not installed by default, most PCs have it. Nearly all Visual Basic applications include this DLL during the installation process, and, since it's considered a shared component of these applications, it is typically left on the system even after an uninstall. So, if a Visual Basic program has ever been installed on a computer, it probably has this ActiveX control installed, too, which makes this component highly prevalent, and, therefore, a lucrative target for attackers.
There's no telling how many ActiveX programs were affected by this vulnerability, but the number is probably in the hundreds. The problem was worst for anyone using Windows XP with Internet Explorer 6.
Over time, Microsoft has tightened security around ActiveX controls dramatically. IE7 introduced a feature called ActiveX opt-in, which made it impossible for an attacker to use an installed ActiveX control without permission. In Windows Vista and Windows 7, Internet Explorer use Protected Mode, which sandboxes ActiveX controls so they're unable to do any serious damage. And cumulative updates to Internet Explorer routinely set ActiveX "killbits" for vulnerable controls to block them from running at all.
In modern Windows versions, you're unlikely to find more than a handful of ActiveX controls. (Adobe's Flash plugin for Internet Explorer is the most common one.) But it's taken years to shake off the security headaches that came with ActiveX, and Internet Explorer's image remains tarnished today.