Internet Explorer is one of many examples of insecure software. Some
call Internet Explorer the browser that made the Internet accessible to
the masses. Others call it an accident waiting to happen (again and
again). Let's think about where IE grew up. Started as a skunk works
project alongside Windows 95, Internet Explorer was first released in
1995 as part of the Internet Jumpstart Kit found in Microsoft Plus! For
Windows 95. While it was well integrated with the new operating system,
few users adopted it, as much more mature and feature rich applications
already existed. With the release of IE 2.0 in 1996 it was obvious that
MS was not abandoning this software. Cross platform support was added
for Macintosh users, and several emerging technologies such as cookies,
VRML and RealAudio were now supported. Later that year IE 3.0 was
released, and the browser wars truly began. Finally MS had released a
product that was capable of competing with Netscape on even ground.
Internet Explorer was no longer merely a Web browser, it was the launch
point for most of the users Internet needs. Users could read your
e-mail, check newsgroups, view videos, listen to music, and (believe it
or not) browse the Web too.
Within nine days of its release the very first exploit for IE 3.0 was
discovered and released to the public. The rest, as they say, is
history.
So how could a company with the resources of Microsoft develop and
release a product that is so obviously flawed? The Microsoft campus
contains some of the most brilliant designers and programmers the world
has to offer. Many of the development practices present at MS are used
throughout the industry (which many would say contributes to the
problem, but that is a different topic altogether). Why, then, can't
even the imposing minds at Microsoft seem to be capable of writing
software that can be trusted?
First of all, we should note that there is more than one way for
software to be insecure. Methods for exploiting and circumventing
security in programs are as varied as the applications they are
attacking. Perhaps the fundamental problem is that software is not
necessarily designed and constructed with security in mind. Until
recently, security has been something of an afterthought in the
computer industry, both amongst vendors and among customers/users. Apart from the
obvious problem that security has not been a fundamental part of the
development process, there are other fundamental problems with software
that add to insecurity.
Complexity and Integration of Programs
Today when a program is written, it cannot be assumed that only it and
the operating system will be running at any given time. The terms
integration and interconnectivity have been chanted like a mantra for
several years now. For those old enough to recall, applications used to
be relatively single purpose. WordPerfect 5.1, arguably one of the best
word processors in existence, was only a word processor. It didn't have
any notion of programs other than itself and the operating system. It
performed a specific task, and performed it well. However, when
Microsoft released their Office suite the world was forever changed.
Now not only could you create documents, spreadsheets, and
presentations using one application suite, you could actually use these
tools together. For example, if you had a spreadsheet in Excel that you
wanted to include in your report, all you had to do was copy and paste
it into your report document.
As time moves on, more and more components have been either integrated
with one another, or are at least able to talk amongst themselves. Soon
certain options and functions were only available if other, sometimes
unrelated services were enabled. If you wanted to share files across a
network, you had to enable the Microsoft file-sharing protocol. Along
with this protocol, usually unbeknownst to the user, several other
features such as printer sharing and remote registry management were
also enabled. To put it another way, the "package deal" was delivering
more than the user expected and possibly wanted. This makes the job of
securing the system even more difficult as the user may not have an
accurate picture of what is and is not setup on the computer.
The code required to construct and run such
sophisticated multi-application software is not only highly complex, it
is also huge. The code for a single program, like Microsoft Word,
consists of millions of lines of code. It is almost beyond the scope of
human possibility to ask the software developers to perform the
comprehensive quality assessment necessary to ensure optimal security.
Even if it were possible, it would be very easy to overlook one or two
bugs; after all, even if considerable resources are made available for
quality assessment, there is still a finite time in which to conduct
it. Hackers, on the other hand, have endless hours to prod and probe
for a single vulnerability to exploit.
Need to Rush Software Out Without Adequate Testing
Part of the problem may be the “necessity” to role out commercial
software by deadlines imposed by finance and marketing needs. Ask any
software developer what it's like to code during a crunch and you'll
probably get an earful of complaints. "They want us to do too much in
too little time" or "I hope no one ever looks at this code again!” and
“It's terrible, but it works" are oft repeated phrases. The Almighty
"hack" -- a so-called elegant solution to a programming problem -- or
more usually a short-sighted but "clever" way of covering up flaws in
the system becomes the required method of development. Suddenly design
and coding style are thrown out the window in favor of down and dirty
"do what works, we'll fix it later" coding. Initially some of the more
idealistic (and typically youthful) coders feel that this sort of
programming is wrong; this feeling usually passes quickly under the
tutelage of the more experienced team members.
Under these time pressures, errors that may normally be obvious and
easy to catch slip through because inadequate attention is given to
reviewing and testing the code. This is not to say that flaws are not
introduced into the system at earlier stages in the development cycle,
but I suspect that most of the big errors are made during this time of
accelerated development. Poor program or feature specifications are
compounded by designers who can only assume that the specification is
complete, and then further by programmers who each have their own
unique idea of what the design is really calling for.
With added features comes the added responsibility of ensuring that
each of those features works both by itself and with the other
components of the system. If you have a subsystem of 15 components,
each of which relies on the other at some point, adding another
component causes you to not only test the newest piece, but all of the
other connected pieces. This can be a very expensive and time consuming
process; it is a process that is often cut short, or is poorly done in
the interests of shipping on time or reducing costs.
Closed Source Patches
An argument that you hear all the time from the Open Source community
is: How can we trust your software if we cannot see what the code is
doing? Closed source software is often patched by closed source patches
-- essentially you are adding even more unknowns to the security puzzle
every time you patch something. When Windows 2000 Service Pack 2 was
released, one of the biggest concerns was that suddenly MS Exchange
2000 Server would not longer run. This was not documented, and it was a
flaw discovered time and time again by hapless users who, perhaps
naively, assumed that the bug fixes in Service Pack 2 would not
adversely affect the way that other applications on their systems ran.
In fact, even after taking a look at the full list of documented changes found in SP2, one would not be able to guess or deduce that any problems would occur with MS Exchange 2000.
Poor Training
Many software developers do not understand the risks that they are
exposing their users to by creating poorly written code. While many
explanations are possible, at the root of the problem we can usually
find that poor training is the culprit. Either as students the young
software developers were not adequately inundated with good coding
styles and practices or they simply chose to ignore what advice was
given to them. For those fledgling software developers who actually
attended some post-secondary education in a relevant field, many of the
assignments and problems that they were asked to solve were one-shot
standalone entities, meaning that once a problem was solved by whatever
code they had written, they would “throw away” their work and never
look at it again. Why spend extra effort on making your code clean and
safe when the quick and dirty solution still got you full marks?
The write – debug - rewrite cycle is common practice among students and
junior coders; that is to say that rather than spending time on design,
they will code as much as they can, debug the software when it doesn’t
work, and continue rewriting and debugging until such time as the code
does what they want it to. Once the goal has been accomplished, it is
left alone and the next problem is attacked. Audits for proper memory
management, coding style, or compatibility with other code are not
adequately conducted. If this trend is not stopped early on, it will
grow into a much larger problem until it becomes standard operating
practice.
Conclusion
Underlying all the causes of insecure software is a simple
philosophical flaw: software is not designed with security in mind.
However, there may be a light at the end of the tunnel. Recently, Bill
Gates issued a company-wide memo to all Microsoft employees dictating
that from this moment forward, security will be a programming priority.
In the memo, entitled “Trustworthy Computing”, Gates states:
“Trustworthy Computing is the highest priority for all the work we are
doing. We must lead the industry to a whole new level of
Trustworthiness [sic] in computing...Eventually, our software should be
so fundamentally secure that customers never even worry about it...So
now, when we face a choice between adding features and resolving
security issues, we need to choose security".
Whether or not this resolution will be realized is impossible to tell.
However, the fact that the memo was issued indicates the growing
awareness that software developers must place a much higher priority on
secure coding. Whether or not they do so remains to be seen. Until they
do, organizations that base their operations on bug-weakened software
will continue to be castles built on sand.