FITUG e.V. Förderverein Informationstechnik und Gesellschaft

Results, Not Resolutions

------- Forwarded message follows ------- Date sent: Fri, 15 Feb 2002 07:53:20 -0500 To: Digital Bearer Settlement List <dbs@philodox.com>, dcsb@ai.mit.edu, cryptography@wasabisystems.com, mac-crypto@vmeng.com From: "R. A. Hettinga" <rah@shipwright.com> Subject: Results, Not Resolutions

http://www.securityfocus.com/news/315

Results, Not Resolutions A guide to judging Microsoft's security progress. By Bruce Schneier and Adam Shostack Jan 24 2002 3:50AM PT Last week, Bill Gates published a company-wide memo outlining a new strategic direction for Microsoft. Comparing this to the change when the company embraced the Internet, Gates elevated security to Microsoft's highest priority. By focusing on what he called "Trustworthy Computing," Gates plans on transforming Microsoft into a company that produces software that is available, reliable, and secure.

"We must lead the industry to a whole new level of Trustworthiness in computing." - Bill Gates internal memo, 15 January 2002.

Trust is not something that can be handed out; it has to be earned. And trustworthiness is a worthy goal in computing. But unlike performance goals or feature lists, progress toward it is hard to measure. How can we determine if one piece of software is more secure than another? Or offers better data integrity than another? Or is less likely to contain undiscovered vulnerabilities? How do we know if Microsoft is really committed to security, or if this is just another performance for the press and public? It's not as easy as measuring clock speeds or comparing feature lists; security problems often don't show up in beta tests.

As longtime security experts, we'd like to suggest some concrete ways to evaluate Microsoft's (and anybody else's) progress towards trustworthiness.

These are specific and measurable changes that we would like Microsoft to make. This is not intended to be an exhaustive list: building secure software requires much more than what we delineate here. Our goal is to provide a list of measurable recommendations, so that the community can judge Microsoft's sincerity.

Some of our recommendations are easier to implement than others, but if Microsoft is serious about security and wants to take a true leadership position, they can't shirk any of them. Some of our changes are easier to verify than others, but it is our goal that all of them be independently measurable. In the end, the pronouncements and press releases don't mean a thing. In security, what matters are results.

If we can distill our recommendations into a single paradigm, it's one of simplicity. Complexity is the worst enemy of security, and systems that are loaded with features, capabilities, and options are much less secure than simple systems that do a few things reliably. Clearly Windows is, and always will be, a complex operating system. But there are things Microsoft can do to make even that complex system simpler and more secure. Microsoft must focus its programmers on designing secure software, on building things right the first time.

I. Data/Control Path Separation

"Security models should be easy for developers to understand and build into their applications." -Gates memo.

One of the simplest, strongest, and safest models is to enforce a rigid separation of data and code. The commingling of data and code is responsible for a great many security problems, and Microsoft has been the Internet's worst offender.

Here's one example: Originally, e-mail was text only, and e-mail viruses were impossible. Microsoft changed that by having its mail clients automatically execute commands embedded in e-mail. This paved the way for e-mail viruses, like Melissa and LoveBug, that automatically spread to people in the victims' address books. Microsoft must reverse the security damage by removing this functionality from its e-mail clients, and from many other of its products. This rigid separation of data from code needs to be applied to all products.

Microsoft has compounded the problem by blurring the distinction between the desktop and the Internet. This has led to numerous security vulnerabilities, based on different pieces of the operating system using system resources differently. Microsoft should revisit these design decisions.

We recommend the following modifications in the next release of these Microsoft products. In short: illustrate the actions, and provide a sandbox environment. This release should be focused only on removing insecure features and adding security.

Office: Macros should not be stored in Office documents. Macros should be stored separately, as templates, which should not be openable as documents. The programs should provide a visual interface that walks the user through what the macros do, and should provide limitations of what macros not signed by a corporate IT department can do.

Internet Explorer: IE should support a complete separation of data and control. Java and JavaScript should be modified so they cannot use external programs in arbitrary ways. ActiveX should eliminate all controls that are marked "safe for scripting."

E-mail: E-mail applications should not support scripting. (At the very least, they should stop supporting it by default.) E-mail scripts should be attached as a separate MIME attachment. There should be limitations of what macros not signed by a corporate IT department can do.

.NET: .NET should have a clear dilineation of what can act and what cannot. The security community has learned a lot about mobile code security from Java. Mobile code is very dangerous, but it's here to stay. For mobile code to survive, it should be redesigned with security as a primary feature.

Implementation of Microsoft SOAP, a protocol running over HTTP precisely so it could bypass firewalls, should be withdrawn.

II. Default Configurations

"Our products should emphasize security right out of the box." -Gates memo.

Microsoft software, by default, installs with many more features than most users need or want. This makes the software more vulnerable than necessary. There are many recent examples of this. The recent Universal Plug-and-Play bugs work even if you don't know what UPnP does, or whether or not you're using it. The SuperCookie bug in Windows Media Player works even if you don't use WMP. Code Red successfully attacks IIS installations, even in Windows setups that aren't being used as a Web server.

Additionally, features must be installable one by one. In UNIX, for example, a Web server and an ftp server are separate, and must be installed separately. With IIS, installing a Web server not only installs a Web server, but also an ftp server, a Gopher server, and Bill himself probably doesn't know what else.

It's not enough to give users the ability to turn off unneeded features. Users don't even know which features are turned on, much less how to turn them off, and the features might accidentally get turned on again. The best prevention for attacks against a feature is for the feature not to be there.

We recommend that the next release of all Microsoft products have default installations with the most minimal feature set possible, and that additional features require special installation activity to make them work. We also recommend that this installation be visible to the user, so that the user knows the features are there. We recommend that Microsoft ensure that all features can be installed and uninstalled separately, as well as in common packages. We recommend that unneeded features not be installed, instead of being installed and disabled. Additional controls should be implemented to allow a corporate IT department to prohibit certain features from being installed.

We also recommend that .NET come with the ability to use configurations from a variety of sources, including Microsoft, its competitors, and public interest/advocacy groups like the Electronic Frontier Foundation.

III. Separation of Protocols and Products

"As software has become ever more complex, interdependent and interconnected, our reputation as a company has in turn become more vulnerable." -Gates memo.

Today Microsoft builds large, complex services that intermingle many smaller services. For example, the Microsoft file-sharing protocol contains file sharing, registry sharing, remote editing, printer sharing, password management, and a host of other services. If a user wants one of those services, he has to implement them all.

These need to be split into separate services, running on separate bits of server software so that a user can choose which to install where. Absent that, the complexity of the software grows to demonstrably insecure levels.

We recommend that Microsoft separate functionality so that the user can install only the specific functions they need. We also recommend that Microsoft provide, and allow others to provide, a variety of pre-bundled functions. Most users don't want to install individual functions, and will rely on others to tell them what they need.

IV. Building Secure Software

"So now, when we face a choice between adding features and resolving security issues, we need to choose security." -Gates memo.

Commercial software is full of bugs, and some of those bugs harbor security vulnerabilities. This is not meant to excuse Microsoft's long-standing apathy towards security; it's merely a statement of fact. These bugs are caused by bad software specification, design, and implementation.

Much of what we discuss above (data/command separation, default configurations, separate software for separate protocols) has the effect of minimizing the impact of software bugs by reducing the amount of software on a computer. However, there will still be a great deal of software on any computer, and that software needs to be resilient to attack. This means that the software doesn't easily break when attacked. And if it does break, the system as a whole doesn't fall apart. Today, we can worry that a single bug in Windows will render a server completely insecure, or a single bug in IIS will expose all the data in .NET. Today Microsoft software is brittle; it needs to be resilient.

There is much Microsoft can do to make its software more resilient, and our recommendations could go on for pages. But generally speaking, certain features are more fragile than others. We recommend the following:

Microsoft should drop all plans for automatic software updates via the Internet until they can be done securely and reliably. Today there are too many problems with updates and patches to allow them to occur without the user's knowledge, and too many problems with authentication to prevent others from maliciously using the capability to attack systems.

Microsoft should eliminate all centralized customer databases in its .NET services. These databases are too dangerous to keep in one place; the ramifications of a security breach are too great.

Microsoft is already moving towards signing code files. While we recommend that Microsoft continue this practice, we also recommend that Microsoft not rely on code signing for security. Signed code does not equal trustworthy code, something the security community graphically demonstrated through the many ActiveX vulnerabilities. Microsoft should drop the code-signing security paradigm in favor of the sandbox paradigm.

Today, too many Microsoft server components run as Administrator. When a service runs as Administrator, it is much easier for a security flaw to result in the machine being fully compromised. Under UNIX, servers are often designed to run as a normal user. This should be the default configuration for Microsoft servers as well.

All other Microsoft features should be evaluated for resilience. Those that are too risky should be removed until they can be rewritten and secured.

V. Transparency and Auditability

"If there is any way we can better protect important data and minimize downtime, we should focus on this." -Gates memo.

Too much of the Microsoft operating system operates invisibly, without the user's knowledge. Too much of it functions without leaving audit records of what happened. With each successive version of the Microsoft operating system, it has become increasingly difficult for a user to control his own system or to examine what his system is doing. This has disastrous security ramifications, and should be reversed.

We recommend that Microsoft add strong auditing capabilities to all products, both operating systems and applications software. We recommend that Microsoft provide configuration tools along with its operating system, as well as tools for an IT department to manage the configurations of its computers. We would also like to see Microsoft abandon the Registry in favor of a less opaque and more user-friendly system.

VI. Advance Publication of Protocols and Designs

"There are many changes Microsoft needs to make as a company to ensure and keep our customers' trust at every level-from the way we develop software, to our support efforts, to our operational and business practices." -Gates memo.

If there's one thing that security experts have learned over the years, it's that any system, when initially proposed, will have security bugs. The only reliable remedy is to publish system details early, and let the security community examine them.

Microsoft needs to publish specifications for protocols in advance and encourage public comment. This is doubly important for security protocols and systems. If a portion of the software is critical to security, then there is no way to achieve trustworthiness without publication. Publication does not ensure security, but it's an unavoidable step in the process.

We're not suggesting that Microsoft must give up all proprietary rights to its protocols and interfaces, or allow anyone to implement or use its standards. We are saying that they must be public, not secret.

The published specifications must be complete, readable, and generally available. It's not sufficient to make the specifications available to specific researchers, or to people who have signed non-disclosures or paid for the privilege. Again, this is not easy from a business point of view, but if Microsoft is serious about putting security first, it needs to engage rather than ignore the security community. And Microsoft should wait before implementing those specifications in products

We recommend that all protocols and interfaces used in Microsoft software be immediately published, and a one-year moratorium be placed on all non-security modifications to those protocols. We also recommend that Microsoft publish any new protocols or interfaces at least one year before implementing them in products.

In addition to making its protocols and interfaces public, we suggest that Microsoft consider making its entire source code public. We're not advocating that Microsoft make its products open source, but if they really want to impress everyone about their newfound security religion, they will make their code available for inspection. Honestly, we don't expect Microsoft will do this. It's too much of a cultural change for them to even consider.

VII. Engaging the Community

"Compensation plans of Microsoft product engineers, such as raises and bonuses, will also be tied to how secure their products are." -Associated Press article on Gates memo, 15 January 2002.

Tying security to compensation is the best way to effect a cultural change inside Microsoft. We feel that Microsoft needs to go further, and reward not only Microsoft employees but independent researchers. Microsoft can no longer threaten, insult, or belittle independent researchers who find vulnerabilities in their products.

Microsoft needs both automated security reviews and evaluations by security experts. A great deal of work in this area has already been done outside Microsoft. We recommend that Microsoft devote resources towards comprehensive security reviews for all of its code, using security experts both inside and outside the company. We also recommend that Microsoft set up an independent body to evaluate security vulnerabilities found by researchers outside the company.

Conclusion

"Eventually, our software should be so fundamentally secure that customers never even worry about it." -Gates memo.

Our recommendations are by no means comprehensive. There's substantially more involved in building secure software than the seven items we list here. These items are intended to be near-term milestones; they're recommendations more about implementation than architecture.

Buffer overflows, everyone's favorite whipping boy, are a comparatively easy implementation-level problem to fix. Higher-level constructs, such as implementing a scripting engine or securing inter-process communications, are more complicated design-level issues. But if Microsoft doesn't start with the simpler stuff, they're never going to get to the hard stuff.

Security isn't easy, nor is it something that you can bolt onto a product after the fact. Making security Microsoft's first priority will require a basic redesign of the way the company produces and markets software. It will involve a difficult cultural transition inside Microsoft. It will involve Microsoft setting aside short-term gains in order to achieve long-term goals. It's a difficult goal, and we believe that Microsoft can do it. We hope that they remain committed.

Bruce Schneier is Chief Technology Officer of Counterpane Internet Security Inc. Adam Shostack is Director of Technology at Zero-Knowledge Systems, Inc.

Zurück