Security Adviser | Roger A. Grimes » TAG: Application Development

April 11, 2008

Don't throw out ActiveX (or Java)

TAGS: Application Development

For years, many security consultants and well-meaning guidelines have recommended completely disabling ActiveX in Internet browsers (mainly Internet Explorer) to prevent a particular type of Web client-side attack. Running a browser without ActiveX enabled can be a frustrating experience for end-users, as many popular and legitimate Web sites use ActiveX to enhance the user's overall experience.

Barely a week goes by without one or more ActiveX controls from various vendors being declared unsafe, so I can understand the caution. You should always disable unneeded and unauthorized software, but running a browser without ActiveX enabled when other more reasonable alternatives exist is throwing the baby out with the bathwater.

(Disclosure: Although I work full time for Microsoft, everything I say here could equally apply to Sun's Java.)

Yes, hundreds of ActiveX controls have been found, over the last decade, to contain buffer overflows or to allow malicious behavior. But with a few exceptions, the problem isn't with the ActiveX platform itself, but with insecure program code passed along using ActiveX mechanisms. Sometimes the ActiveX controls are downloaded by users, but problematic controls are just as likely to be preinstalled by hardware and software vendors.

ActiveX is a platform, not a language. No one codes in the ActiveX language. ActiveX is a popular way for a software vendor to transport its program (normally in .CAB, .DLL, or .OCX file formats) from a Web site, then install and launch it in a user's browser session in an almost seamless manner.

There are many other methods to download and install Internet-based code, but ActiveX is fairly easy to use, integrates well with multiple Internet browsers, and contains many native security mechanisms. For one, vendors can sign their ActiveX controls with a publicly trusted digital certificate to confirm to the end-user that the program they are receiving is indeed from the purported vendor. There have been a few malicious uses of digital certificates over the last decade, but the inappropriately used certificates are quickly revoked when discovered. Overall, the publisher identity system works pretty well in identifying the originating software publisher, when users pay attention to it.

But unfortunately, a digital signature doesn't guarantee that the control won't do something unauthorized to the user's system or that it doesn't contain an exploitable vulnerability. No programming language or Internet transportation method can do that. ActiveX gives vendors one way to transport their program from source to destination, but it doesn't absolve the vendor of using SDL (secure design lifecycle) programming.

Now, it is completely valid to ask if ActiveX's ability to seamlessly download and integrate programs within the context of a browser is a safe thing in today's scary Internet world. But if you're going to identify an Internet programming mechanism involved with more Internet crime than another other mechanisms, you would single out JavaScript. JavaScript is involved in nearly 100 percent of browser-related, client-side attacks, including the ones involving ActiveX, and you don't hear popular calls to get rid of JavaScript.

In all but the most secure enterprise environments, a more moderate support statement would be to approve needed ActiveX controls, while not allowing users to install uninspected and unapproved controls and programs.

Many programs allow administrators (or end-users) to control what software may run on their computer, including many mechanisms built into Windows. For one, only administrators can download and install new ActiveX controls. As long as most of your end-users aren't running as administrators, this gives the administrator a lot more control. Many environments incorporate approved ActiveX controls into their deployment and build methodologies. And since the end-user isn't an administrator (hopefully), they can't install new controls.

If end-users are administrators and can install their own controls, there are still several defenses against unapproved controls. The primary method is to dictate what types of controls (and other active content, such as binary behaviors and .Net components) can be downloaded and installed in the browser. Internet Explorer allows dozens of settings, regarding signed and unsigned controls to be governed across various Web site zones (such as Internet, Restricted, Intranet, and so on)

If a particular control is known to be malicious, end-users or administrators can set a "kill bit." This basically involves finding the control's related CLSID identifier in the registry and configuring a value to be 0 (disabled) versus 1 (enabled). Jesper Johansson has a couple of great articles on setting kill bits, including how to automatic the process using scripts and Active Directory. Programs can also be allowed or disabled using various group policies and knowing the program's unique CLSID.

Windows 2000 and above domain computers can also use Software Restriction Policies (SRP), which can restrict (or allow) programs based on name, location, digital certificate, or Internet zone. Windows Vista has the added benefit of the new ActiveX Installer Service (AXIS). It allows an administrator to download approved ActiveX controls to pretrusted locations, and when a user needs the control, Windows will redirect the user's browser to the trusted location first. Controls in the trusted location (and you can define multiple locations) can be silently installed, prompt the user for installation, or be prohibited. Controls not located in the trusted locations fall back to the normal ActiveX install rules, and can be controlled using one of the previously stated methods. You can see much more detail in this white paper on AXIS.

Some people, rightly or wrongly, simply hate ActiveX. They've been burned before or are tired of reading stories of vendors who continue to use insecure programming methods. I can understand that, but disabling ActiveX when you can prevent the unsafe controls from loading seems a little heavy-handed. Is JavaScript next? Should ASP, SQL, or PHP be disallowed on the server just because a programmer writes insecure programs using them?

In preparation for this blog column, I searched the Internet for vulnerable ActiveX controls. What I found is that most ActiveX control vendors have fixed the holes in their products in a relatively speedy manner. And nearly all vendors that were reported as having a vulnerable ActiveX control have not been found to have them at a later date (although I did locate three instances that contradicted this finding). Further, I discovered that the vast majority of the superpopular programs (which nearly everyone has installed) and which are getting patched and repatched every month, aren't using ActiveX. What do we do now?

Posted by Roger Grimes on April 11, 2008 03:00 AM

February 29, 2008

Security Development Lifecycle trumps code complexity

TAGS: Application Development

In last week's column, I talked to Bruce Schneier about complexity, one of the main reasons it will be hard for computer security to improve in the future. As software becomes more complex, in terms of more lines of code or functionality, the harder it becomes to stay secure. More lines of code mean the potential for more security bugs. Increasing feature sets means more opportunities for programs to be used and manipulated in unexpected, malicious ways. In general, I wholly believe in this axiom, but it doesn't always have to be true. In fact, there is empirical evidence that better coding practices can more than offset the complexity argument.

Michael Howard is the co-author of several books on Security Development Lifecycle (SDL), and he's principal security program manager at Microsoft. (Full disclosure: I am a full-time employee of Microsoft.) He, like myself and thousands of Microsoft security employees, cares more about computer security than allegiance to the company. We call a spade a spade, even when it doesn't always reflect well on Microsoft. Luckily for us, security is a top concern at Microsoft, despite what some people will tell you. It may not be the only decision point, as it is for OpenBSD, but it is as important as any other initiative the company has, if not more.

Michael is heavily involved in Microsoft's use of SDL in its own software. And the results of SDL has meant fewer found vulnerabilities in SDL-developed software in the same time periods as compared to pre-SDL software versions. Michael's article starts first by referencing Jeff Jones' blog entry comparing Windows Vista vulnerabilities to those of Windows XP and other first-year OS releases.

There is no doubt that the number of vulnerabilities in Microsoft's software is going down despite increasing complexity. Critics, including some who are sure to write heated e-mails in response to this column, constantly blast Jeff Jones' figures. I don't know why -- he uses industry-accepted figures, grabs his numbers from external, independent sources, and compares apples to apples in terms of default software and feature sets.

Some critics say that a single metric neither means everything nor tells the whole story. I agree. What I won't accept is that it doesn't mean anything. I don't care how much you hate Microsoft, and the record still needs lots of improvement, but the number of found vulnerabilities is going down, year after year. SDL is working.

Microsoft SQL 2000 had 10 vulnerabilities, the last in early 2004; Microsoft SQL 2005 has had none. Internet Information Services (IIS 5) had 12 vulnerabilities; IIS 6, released in March 2003, has had five.

Even in the most heavily attacked Microsoft products, with high found vulnerability counts, the overall trend is positive. In 2003, Internet Explorer 6 had 24 vulnerabilities versus Internet Explorer 7's 17 in 2007. IE is tracking nearly dead even with Mozilla's Firefox 2.0, built as the "secure alternative" browser. It might not surprise you to learn that Window Snyder, Mozilla's CSO, is a heavy promoter of SDL.

All of these statistics are not just to inflame anti-Microsoft zealots, but to promote two points.

First, although complexity is the enemy of security, increasing complexity doesn't always mean more vulnerabilities. If your software security coding practices are nonexistent or hugely inconsistent, SDL practices can offset the increasing complexity problem, at least for your product. Increasingly complexity may still make the Internet an unsafe place, because a gazillion new products and protocols are being invented every day, but less because of your product.

Second, if you're a developer and your company is not using SDL, it's time to get on it. There are books on it everywhere. You can search on titles by Michael Howard or look for other books on writing secure code and/or threat modeling.

If you want to improve your company's security programming, teach SDL and build it into the company culture. It might take a little while to get the ship turned around, but once you do, the results are tangible, and they'll benefit everyone.

And contrary to popular belief, Microsoft wants all companies, even tough competitors and open source advocates, to write more secure code. More secure programs make a more secure Internet, which benefits everyone and every platform.

A rising tide lifts all boats.

Posted by Roger Grimes on February 29, 2008 03:00 AM