"With great power comes great responsibility." Truer words have never been spoken, neither to young Peter Parker, nor to modern application programmers. This applies doubly to programmers who install ActiveX controls on Microsoft Windows systems.

(Let me apologize right now for not making this posting about Spider-Man. I would have enjoyed it a lot more, and so would you. Unfortunately, Spider-Man doesn't really have a lot to do with network security, and ActiveX controls do. I promise I'll write a Spider-Man post someday.)

The term "ActiveX" is tossed around a lot these days. What is it, really? Well, it's an instance of another term tossed around a lot: component-oriented programming. Component-oriented programming (or, as I like to call it, COP) is a programming paradigm that lets programmers link various off-the-shelf components into working programs, like assembling little puzzles or making little machines. ActiveX does this on Windows by providing "controls" (components) that export standard interfaces. Any program can "instantiate" one of these controls, and access its functionality through well known interfaces.

This is great for developers, because there are components for everything: encryption, file management, photo handling, HTML rendering...anything you could possibly want to do, there's an ActiveX control that can do it.

There's only one small fly in the ointment: one of the programs that can instantiate ActiveX controls is Internet Explorer. On the surface, this appears to be (and actually is, mostly) a good idea. Web pages can instantiate ActiveX controls and utilize all sorts of advanced functionality there provided. It lets web pages do amazing things, to see things no other web page can see, do things no other web page can do. Unfortunately, ActiveX relies on the weakest link of all in computer security: trust.

Internet Explorer will only instantiate ActiveX controls if they've been marked as "safe for scripting". A control thus marked is believed to be safe: it doesn't export methods that you wouldn't trust an unknown person to execute. No "DeleteAnyFile" methods. No "EmailMyPasswordToThisAddress" methods. Not even the old fan favorite "GiveMeCompleteAccessToYourSystemViaTelnet". The exported methods are supposed to be safe, even from things like buffer overflows.

The vast majority of ActiveX controls out there that are marked "safe for scripting" probably are indeed that. Unfortunately, some of them are not. There are plenty of ActiveX controls that were never meant to be instantiated by anything other than the application that installed them. They certainly should not be instantiated by some random, untrusted web page. Herein lies the problem: these controls are very often marked "safe for scripting". Any web page that instantiates these controls can basically do anything the current user can do.

While Microsoft is not blameless in this situation - there are, every now and again Microsoft ActiveX controls that are revealed to be vulnerable - the real problem is that practically every Windows application installs ActiveX controls, and there are a lot of programmers out there who don't care or know about security. These controls have easily exploitable vulnerabilities that, depending on the installing application, could exist on thousands if not millions of computers.

These vulnerabilities are rapidly becoming the low hanging fruit of the security world. It's not that they're getting more common; they're as common as they've ever been. It's just that the desires of attackers are changing. Servers used to be the primary targets: compromise the server and get access to email and passwords and industrial secrets. Those type of vulnerabilities are like hand-crafted toys: they're a lot of fun, but they're expensive and time consuming to make. The modern attacker is after as many machines as possible, so he can sell those machines into a spam farm or botnet. Mass production. Less fun, but more profitable.

So, what can you do? Well, that's a tougher answer. You could eliminate the problem completely by running another web browser other than Internet Explorer, such as Firefox or Opera. You could disable all ActiveX controls. Both of these are fine options, but there are some situations where that just isn't possible. For those cases, there is no panacea. User education is the only real solution. Make sure your users only visit trusted sites, and make sure there's a reason those sites are trusted.

Because of the power afforded to ActiveX controls, these types of flaws are going to be exploited for a long time. That's not so bad, though. I'm trying to buy a house.

(Update: You may want to also have a look at Marc's posting here. In it, he talks about malicious ActiveX instantiations and how they are used to recruit innocent machines into botnets. He also uses the word "gyring" and quotes Yeats. I quote Spider-Man. Yeah, we both probably got beaten up in high school.)