Results, Not Resolutions

[R. A. Hettinga]

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.


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com