Preface

Chapter One Mobile Code and Security: Why Java Security is Important
Chapter Two The Base Java Security Model: The Original Applet Sandbox
Chapter Three Beyond the Sandbox: Signed Code in JDK 1.2
Chapter Four Malicious Applets: Avoiding the Common Nuisances
Chapter Five Attack Applets: Exploiting Holes in the Security Model
Chapter Six Securing Java: Improvements, Solutions, and Snake Oil
Chapter Seven Java Security Guidelines: Developing and Using Java More Securely
Chapter Eight Java Card Security: How Smart Cards and Java Mix
Chapter Nine The Future of Java Security: Challenges Facing Mobile Code
Appendix A Frequently Asked Questions:Java Security FAQ
Java versus Active X
Appendix B Java Security Hotlist
Appendix C How to Sign Java Code
References

Preface
Java has grown by leaps and bounds since its introduction in 1996, and is now among the most
popular computing platforms on the planet. Java has evolved and changed so much that at a mere
two-years old, our original work, Java Security: Hostile Applets, Holes, and Antidotes, found itself
in serious need of revision and expansion. This book is the result of several years of thinking about
mobile code and security, and includes many things we have discovered while working on real-
world systems with businesses and government agencies. Our goal is to present enough information
to help you separate fact from fiction when it comes to mobile code security.

Java has become much more complicated and multifaceted than it was when it was introduced. No
longer simply a client-side language for applets, Java can now be found on everything from
enterprise application servers to embedded devices like smart cards. We have tried to address
security factors from throughout the entire Java range in this book.

We hope this book appeals to geeks and grandmothers alike (not that some grandmothers aren't
geeks). Although it gets technical in places, we hope the messages are clear enough that even the
casual Web user comes away with a broader understanding of the security issues surrounding
mobile code. We kept four groups in mind as we wrote this book: Web users, developers, system
administrators, and business decision-makers. Many of the issues of mobile code security cut
across these groups. As Java integrates itself into the foundations of electronic commerce, Java
security issues take on more urgency.

Java is only one kind of mobile code among many. Other systems immersed in the same security
dilemma include ActiveX, JavaScript, and Word Macros. It is essential not to get the wrong
message from this book. Our focus on Java is no accident. We believe Java is the most viable
mobile code system created to date. Don't believe that through our work we imply that other
systems are any more secure than Java. Just the opposite is true.

With the introduction of code signing to Java (in JDK 1.1) and its enhancement with access control
(in Java 2), securing Java became much harder. Java's position along the security/functionality
tradeoff has moved significantly toward functionality, to the detriment of security. This is good if
you want more functionality, which most businesses and developers seem to need, but it is bad if
you are charged with managing security risks. Forming an intelligent Java use policy is more
important than ever, but doing so is more complicated than it used to be.

The computer field moves so fast that people have begun to refer to Internet time to grapple with its
constantly accelerating speed. Three months is a year in Internet time. Java is directly involved in
the speed of the field, and has done its share to make things move even more quickly. One tricky
aspect of writing a topical book relating to the Web is figuring out when to stop the action. This
process can be likened to freeze-framing a picture of a movie. In that sense, this book is a snapshot
of Java security. We hope we have succeeded in making it a useful way to learn about Java
security. For up-to-date information, see the book's companion Web site at www.rstcorp.com/java-
security.html.

As we went to press, Sun Microsystems renamed JDK 1.2 and called it Java 2. We have attempted
to use correct version numbers throughout and apologize for any confusion.
Chapter 1, "Mobile Code and Security: Why Java Security Is Important,"," sets the stage with a
discussion of the four intended audiences. As Java matures, it is making important inroads into the
enterprise world. That means Java security is now as important to business people and system
administrators as it is to Web users and Java developers. For the uninitiated, Chapter 1 provides a
quick and cursory introduction to Java. Pointers are provided to more through Java texts that cover
the ins and outs of the entire Java language in more detail. This is, after all, not a book on Java per
se, but is instead a book on Java security. We also spend some time discussing why the once-
important distinction between applets and applications has been superceded by concerns about
trust. It turns out that under the Java 2 architecture, applets can be completely trusted and
applications can be completely untrusted. In fact, every kind of Java code can be doled out different
amounts of trust, depending on what the user's policy says. Finally, we cover some other popular
forms of mobile code and discuss how their security stacks up against Java. The main purpose of
this chapter is to provide some context for the later discussion of Java's critical security
implications and to introduce the central idea of the book: weighing the benefits of Java use against
the risks.

Chapter 2, "The Base Java Security Model: The Original Applet Sandbox," examines the base Java
security model in some detail. As a prelude to our discussion, we introduce four categories of
attacks, ranging from the very serious to the merely annoying: system modification, invasion of
privacy, denial of service, and antagonism. We then discuss Java's programming-languages
approach to security and introduce the three parts of the original applet sandbox. These include the
Verifier, the Class Loader Architecture, and the Security Manager. We also introduce the idea that
Java security fundamentally relies on ensuring type safety. The base sandbox provides the
foundation of Java's new trust-based security model. Starting with a restrictive sandbox for
untrusted code, restrictions can be lifted little by little until code takes on complete trust and is
awarded full run of the entire system.

Chapter 3, "Beyond the Sandbox: Signed Code and Java 2," examines Java's new trust-based
security model. With the addition of code signing in JDK 1.1, Java's security architecture
underwent a large shift. Java 2 completed the transformation with the addition of access control. It
is now possible to create complex security policy for mobile code written in Java and have the Java
system itself enforce the policy. The change certainly affords more power to mobile code than ever
before, but it also introduces a major new risk to Java: a human-centered policy management risk.
Setting up and managing a mobile code policy will be a complex and error-prone undertaking
requiring security experience. JDK 1.1 and Java 2 rest on the notion of trust, which leverages the
technological power of code signing. Understanding the new model requires understanding the way
code signing and trust interact, and discounting some of the common myths associated with it.
Chapter 3 ends with a discussion of stack inspection and the Java 2 code-signing API. (Appendix
C, "How to Sign Java Code," is a code-signing tutorial covering Microsoft, Netscape, and Sun's
three different code signing schemes.)

Chapter 4, "Malicious Applets: Avoiding a Common Nuisance," begins to discuss what happens
when the Java security model is abused by hostile applets. Hostile applets come in two forms: very
dangerous attack applets that involve security breaches, and merely annoying malicious applets that
are more of a nuisance than anything else. Chapter 4 is all about malicious applets. Malicious
applets are quite easy to create, and they are equally easy to find on the Web. Unfortunately, there
are just as many unscrupulous individuals on the Net as there are in the rest of the world. Bad guys
are more than happy to include Java in their list of offensive weapons. Our mission is to make Java
users aware of common classes of attacks.

Chapter 5, "Attack Applets: Exploiting Holes in the Security Model," delves more deeply into the
Java security model by focusing attention on some of the well-publicized security holes that have
been discovered. This is where our discussion of hostile applets turns more serious. Securing Java
is a difficult job, especially when it comes to implementing complicated models. Attack applets
have been created in the lab that exploit the holes we discuss. Some of the holes are simple
implementation bugs, while others indicate more serious design flaws. The good news is that Sun
and other licensees take Java security very seriously and they respond quickly to fix any holes once
they are discovered. We think discussing these holes is important since it emphasizes the true
nature of computer security.

Chapter 6, "Securing Java: Improvements, Solutions, and Snake Oil," has two overall goals, both of
which are meant to impact the Java security situation positively. The first is to suggest some high-
level antidotes for Java security concerns that are not tied to particular attacks. Experts in computer
security have pointed out several global deficiencies in the Java approach to security. Fixing some
of these would certainly improve the model. High-level concerns addressed in Chapter 6 include
programming language issues, formal analysis of Java, applet logging, trust, decompilation, applet
monitoring, and policy management. Hopefully, some of the high-level concerns we raise will
eventually be addressed in the Java platform itself. In the meantime, a number of third-party
vendors are eager to help. The second goal of Chapter 6 is to introduce the players briefly and to
discuss what risks third-party vendors can and cannot address. The computer security field has its
share of snake oil, and complex issues such as mobile code security tend to be easy to exploit. One
of our goals is to bring some realism to the table and arm you with the right questions to ask.

If you only read one chapter of this book, read Chapter 7, "Java Security Guidelines: Developing
and Using Java More Securely." This chapter presents two sets of guidelines: one for Java
developers and one for Java users. Writing security-critical code is not easy, and developers need
all the help they can get. We offer 12 rules for writing safer Java. Although the rules get a bit
technical, it is worth spending some time to figure them out. By contrast, our guidelines for Java
users are simple to understand and follow; in fact, most of them are simply common sense.

Chapter 8, "Java Card Security: How Smart Cards and Java Mix," is devoted to Java on smart
cards. We decided to include this chapter since Java Cards are likely to show up in millions of
consumer wallets in the next few years. Smart card security is really too big an issue to cover in a
single chapter, so we focus primarily on the security impact of putting a Java Virtual Machine on a
card. Chapter 8 covers six key questions, including: What is a smart card?, Why put Java on a
smart card?, and How does the use of Java impact smart card security?

We conclude by covering some of the challenges to mobile code that remain to be

conquered. Chapter 9, "The Future of Java Security: Challenges Facing Mobile Code," presents a
concise set of six central lessons we have learned during our time in the Java security trenches. We
go on to discuss several open research issues that you're likely to hear about again. Finally, we
discuss the notion of security assurance, an important strategy in securing Java.
We hope that this book is both informative and useful. Making intelligent decisions regarding the
use of Java (especially in business and other mission-critical systems) requires some knowledge of
the current risks. Our goal is to disclose those risks-and countermeasures to curtail them-as clearly
and objectively as possible. Armed with the knowledge that we present in this book, Java users, site
managers, and business decision-makers can make better Java use policies.

Acknowledgments

This book is a collaborative effort in more ways than one. Not only did the authors work together
closely, but we also sought input from many other people. We are grateful for the help we received.

Reliable Software Technologies (www.rstcorp.com) remains a great place to work. The

intellectually stimulating environment makes going to work interesting and fun. Many people at
RST read drafts of the book or helped in other ways. They include John Viega (intrepid proofreader
and co-author of the code-signing tutorial in Appendix C), Tom O'Connor (who also read the entire
manuscript more than once and co-wrote the code-signing tutorial), Anup Ghosh (fellow security
researcher), Peggy Wallace (travel, anyone?), Lora Kassab (one-time RST intern whose code from
the first edition lives on), Jeff Payne (RST's forward-thinking CEO), Jon Beskin, Matt Schmidt,
Brad Arkin, Andi Bruno (who herds the marketing cats and makes us be nice), and Jeff Voas (who
continues to lead RST's excellent research group by example).

The members of Princeton University's Secure Internet Programming Team

(www.cs.princeton.edu/sip) also provided valuable input. Besides wading through several drafts,
the Princeton team was responsible for raising many of the key issues in Java security. Special
thanks to Drew Dean and Dan Wallach (cofounders of the Princeton team) and Dirk Balfanz. Dan
is now a professor at Rice University. Drew is a research scientist at Xerox PARC. Princeton's
Computer Science department provides a wonderful environment for discovering and exploring
new research topics.

We would also like to thank Tom Cargill, independent consultant and discoverer of two security
flaws; David Hopwood, discoverer of several attack applets; Mark LaDue, creator of the Hostile
Applets Home Page (keep 'em honest, Mark); Dennis Volpano of the Naval Postgraduate School;
Tom Longstaff, research director at the CERT Coordination Center; Roland Schemers, JavaSoft
security implementation wizard (who helped with code-signing tool questions); Marianne Mueller,
Java developer, security expert, and long-suffering target of press inquiries at JavaSoft; Jim
Roskind, Netscape's Java security expert; Andrew Herbert, APM's Chief Scientist in the real
Cambridge; Ken Ayer, chip card security manager at Visa; Don Byrd, UMass research associate
and careful proofreader of the first edition; Hideyuki Hayashi, who translated the first edition into
Japanese (and did an excellent job according to friends at Sumitomo in New York); Kieran
Murphy, editor at developer.com; Chuck Howell, now at Mitretek; and Mike Shoffner, Java
developer at Prominence Dot Com. Li Gong, security architect at JavaSoft, has been a particularly
valuable help, both as a research colleague and as a sane point-of-view at JavaSoft. More power to
you, Li.
Wiley's staff did an excellent job shepherding this book through the editing and production process.
Special thanks to Marjorie Spencer and Frank Grazioli, who went out of their way to make this
project go smoothly. Thanks to Margaret Hendrey for playing fast and loose with extensions (don't
tell anybody). Also thanks to the rest of the team at Wiley. Finally, and most importantly, we're
grateful to our families for putting up with us while we worked on the book, again. Amy Barley,
Jack, and Eli seem to have adjusted to Gary's persistent book-writing. Laura Felten and Claire
suspect that Ed's book-writing has become an addiction. Without the support of our families, this
book would not have been possible.

Mobile Code and Security:

Why Java Security Is Important

Java security is more important than ever. Since its introduction in 1995, Java has become one of
the most popular development platforms on the planet. In fact, Java has been widely adopted more
quickly than any other computer language. It now easily tops the list of preferred platforms for
Internet-savvy mobile code. There are tens of thousands of Java developers (some say hundreds of
thousands), and demand for Java skills appears to be growing. Java is definitely here to stay.

Java holds great promise as a platform for component-based software, embedded systems, and
smart cards. This means Java is poised to play an important enabling role in e-commerce as these
systems move from ether-ware to reality. Java components (aka JavaBeans) are appearing at a rapid
pace and encapsulate critical functionality for transaction-based systems. Java smart cards for e-
commerce will debut soon.

But what of the hue and cry over security? Should people be so concerned about the security
implications of Java that they disable Java in their browsers? Should developers avoid using Java in
their systems in favor of other languages like C++? Should system administrators block Java
content at the firewall (or better yet, can they)? Should business people avoid Java because of
security problems? These are the some of the questions this book answers. The answers are
nontrivial, and the issues are as complex as they are important.
 Chapter One Sections
1. Who Cares?
2. Mobile Code
3. The Power of Networking
4. Downloading Code: Not a New Problem
5. Java in a Demitasse
6. Securing Java
7. How Does Java Security Stack Up?
8. Where to Find More Information on Java
9. Mobile Code Has Its Price
10. Assessing the Risks

Mobile Code and Security: Why Java Security Is

Important
CHAPTER SECTION: 1

Section 1 -- Who Cares?

Next Page

Java security is important to a number of distinct sets of people:

• Web users, including one of the authors' 89-year-old grandmother, need to understand the
risks of using a Java-enabled browser.
• Developers of Java code that lives and works on the Internet need to keep security in mind
when they are writing programs.
• System administrators need to think carefully about how mobile code, including Java,
impacts the security of the systems they run.
• Business people need to understand what Java security risks are so they can make informed
business decisions based on fact and not fiction.

As you can see, Java security issues are multifaceted. This book has useful information for all four
groups, whose interests overlap in many ways.

Java security is a hot topic, but that does not make it an easy one. By itself, computer security is not
well-understood. Throw Java into the mix and things become even murkier. There is much
confusion and misinformation floating around about Java and security. Beware of snake oil,
impossible claims, and consultants who pretend to have all the answers. Also be aware that major
vendors are just as capable of misinformation as fly-by-night companies. Skepticism, Rene
Descartes' 300-year-old philosophical insight, is strangely relevant to computer security at the turn
of the millennium. In fact, skepticism turns out to be an excellent strategy. Ask hard questions; you
might be surprised by the answers.

Browser Beware

The most pressing security concerns surrounding Java impact millions of people-that is, anyone
who browses the Web. Given that there are tens of millions of Netscape Navigator and Microsoft
Internet Explorer users, the client security issue is no minor detail.1 It turns out that a majority of
the users of these browsers are also Java users, whether they know it or not. Java is built in to
Netscape Navigator and Internet Explorer, so if you use either of these products, you are a Java
user. 1

Just as all Internet users are taking security risks, all Java users are taking security risks. Because of
the way Java works, computer security issues are a fundamental concern. Most Java code is
automatically downloaded across the network and runs on your machine. This makes it very
important to limit the sorts of things that Web-based Java programs can do. Simply put, a hostile
Java program could trash your machine. Because Java is inherently Web-based, it provides crackers
with an easy way to implement a Trojan Horse-a program that may seem innocent enough on the
surface, but is actually filled with well-armed Greeks. Also of concern is the problem of computer
virus propagation. Fortunately, the creators of Java have made a good effort to protect users from
these hazards. For example, writing a Web-based Java virus as an applet would be very hard.
(Writing a Microsoft Word macro virus like the concept virus is, by contrast, easy.) Because mobile
code security is new, difficult, and complicated, Java's masters have not always been successful at
protecting everyone all the time.

One goal of this book is to educate Java users about the risks that they incur by surfing the World
Wide Web with Java-enabled browsers. This chapter provides a gentle introduction to Java and
explains why Java is potentially dangerous.

Developer Concerns

Java security is essential to developers as well. As a platform, Java has much to offer in terms of
security:

• Java has advanced cryptography Application Program Interfaces (APIs) and class libraries.
• Java includes language-level security mechanisms that can help make developing secure
code easier.
• Some aspects of Java that make it more difficult to write insecure (unsafe) code.

This book explains how to use the security features built in to the Java environment inside your
own programs. That's not to say that developing secure programs with Java is trivial or automatic.
Anyone who reads the newspapers or the trade press can see how often skilled programmers write
code with security bugs. You can make almost as many gaffes developing security-critical code in
Java as in any other language. Because of Java's security APIs and its position as a leading e-
commerce platform, it is likely that Java will be used to carry out some very important activities.
That means developers need to learn as much as they can about Java security. Know your enemy.
Think about what might confront your code in terms of malicious attacks. Mitigate risks by
designing, coding, and testing carefully.

A second goal of this book is to teach Java developers and project managers about the sorts of
things that will confront their code in "the wild." If you're a seasoned Java developer (something
that it was impossible to be a mere handful of years ago), this book will show you in great detail
how the security model works. There are lessons to be learned from the Java attacks we cover.
After all, like you, Java's designers and developers were serious about what they were doing. As we
have seen, however, even the most subtle bug can be turned into a security disaster.

System Administration and Java

Today's system administrator is seriously overworked, and security is a big part of the problem.
The days of the isolated Local Area Network (LAN) are behind us. Now, most networks are
connected directly to the Internet, which means security is more important than ever. Some early
adopters and sites with a lot to lose try to protect themselves with advanced security mechanisms
such as firewalls, secure shells, and virtual private networks. Many sites, however, have a long way
to go before they are "secure enough" (whatever that means). Mobile code systems, including Java,
make administering site security trickier.

The problem is that users want Java content, but system administrators don't want to take on
unnecessary risks. This is a classic example of the well-known tradeoff in computer security
between functionality and security. Computer security boils down to managing risks, which in turn
implies that the way to make better-informed decisions is to get a handle on the risks.

A third goal of this book is to present an informed discussion of the real risks of mobile code.
Burying your head in the sand like an ostrich is not a good solution, because security problems are
unlikely to miraculously disappear. However, the risks do not necessarily warrant throwing the
Java baby out with the bath water. Such a move may leave your users high and dry.

Even if the risks turn out to be too much to bear (a decision that is very much context dependent),
system administrators need to be wary of snake-oil "solutions" to the mobile code problem. There
are a number of products on the market that purport to improve Java security. The question is, do
they work? We will delve into these issues as well.

Java Gets Down to Business

Making informed business decisions at the edge of the technology curve has never been an easy
task. In addition to the technological concerns discussed earlier, there are often intangible factors to
consider. What impact will perceived security risks (whether justifiable or imagined) have on
potential customers? Is Java the best platform to use when designing e-commerce systems? How
will the use of Java within an enterprise affect security risks? What are the security challenges in
designing and deploying database-backed Web servers and three-tier applications?

It is surprising that some of the same companies that disallow the use of Java (often for silly
reasons) expect their customers and business partners not to disallow Java. The information in this
book can help business managers and leaders make better decisions about Java security. Good data
are essential to decision-making, but sometimes good data are hard to find.

CHAPTER SECTION: 2

Section 2 -- Mobile Code

The Java programming environment from Sun Microsystems is designed for developing programs
that run on many different kinds of networked computers. Because of its multiplatform capabilities,
Java shows great promise for relieving many of the headaches that developers encounter when they
are forced to migrate code between different types of operating systems. Code that is written in
Java should run on all of the most popular platforms-everything ranging from Macintosh and
Windows/Intel machines to Linux and Solaris boxes.

Recently, the cross-platform capabilities of Java have been called into question. This has led Sun's
marketing phrase "write once, run anywhere" to be reinterpreted by skeptics as "write once, test
everywhere." Part of the problem is that not all implementations of Java are completely
interoperable with Sun's version. Disagreement over what constitutes Java has generated at least
one high-profile lawsuit. Most people, including a majority of Java developers, would like to see
Java become a standard so that what happened to C (which was itself supposed to be a cross-
platform language) doesn't happen to Java.

In any case, a nice side effect of Java's built-in portability is that one special kind of Java program
(popularly known as an applet) can be attached to a Web page. More technically speaking, applets
are embedded into a Web page's hypertext markup language (HTML) definition and executed by
Java-savvy browsers.2 Such Java-enabled browsers automatically download and begin running any
Java applet they find embedded in a Web page. Java code's ability to run on many diverse
platforms makes such "magic" possible.

The ability to dynamically download and run Java code over the Net has led some computer
pundits to proclaim that the age of truly component-based software development may actually have
arrived. The idea is that instead of buying huge monolithic word processing behemoths with
hundreds of obscure features that most users will never need, users can instead "create" a personal
word processor on the fly out of Java building blocks. This modern sort of programming is akin to
building a large toy ship out of Legos blocks. Or, more realistically, the process of creating a
component-based software product could be likened to building a highway bridge out of
standardized structural components.
Sun is advocating a Java component architecture called JavaBeans. A number of companies are
creating sets of JavaBeans for various purposes. If these efforts are successful, developers will be
able to create programs by putting together sets of prefabricated Beans as illustrated in Figure 1.1.
Microsoft's Component Object Model (COM) is very much oriented this way, although it is not
specifically designed to use Java. Component-based software has its own interesting security
implications and open questions. For example, how can the developer of a system trust a
component manufacturer not to have (purposefully or accidentally) introduced security holes into
the system? How can a component manufacturer anticipate all uses to which a component will be
put? And so on. These sorts of questions are the topic of current research, including some by the
authors of this book.

Figure 1.1 Component-based software allows a

designer to create large applications from
standardized building-blocks.

Components in Java are known as JavaBeans. The

idea of using pre-fabricated components to build large-
scale applications will likely do for software what the
Industrial Revolution did for manufacturing.

Thinking even farther into the future, one can imagine a fundamentally new kind of computer
document that contains the word processing, spreadsheet, and database software that was used to
create it. Using a document's embedded components, a writer or editor could modify the document
on any platform. The built-in components would allow different people using different machines to
edit the document without worrying about the kind of computer they are using or file type
compatibility issues. If Java is developed to its full potential, this future world may not be far off.

The new idea behind all of these exciting aspects of Java is simple: the ability to send data that can
be automatically executed wherever it arrives, anywhere on the Net. Java is an implementation of
executable content, or mobile code. This powerful idea opens up many new possibilities on the
World Wide Web. For the first time it is possible to have users download from the Web and locally
run a program written in a truly common programming language.

These features of Java are certainly exciting; however, Java's fantastic potential is mitigated by
serious security concerns. Security is always an issue when computers are networked. Realistically
speaking, no computer system is 100-percent secure. Users of networked computers must weigh the
benefits of being connected to the world against the risks that they incur simply by connecting. In
practice, the goal of a security policy is to make such tradeoffs wisely.

One of the key selling points of Java is its use as a "cross-platform" language for creating
executable content in the highly interconnected world of the Internet. Simply by using a Web
browser, a Web surfer can take advantage of Java's cross-platform capability. Of course, the
activity of locally running code created and compiled somewhere else has important security
implications. These implications are one focus of this book.

The same risks and benefits that apply to connecting to the Internet itself directly apply to using the
Java language. As you will see, these concerns become particularly critical when "surfing the
Web." The same technology that allows Java applets to enliven once-static Web pages also allows
unscrupulous applet designers to invade an unsuspecting Java user's machine. With Java applets
showing up everywhere, and many millions of people using Java-enabled browsers, it pays to know
where you are pointing your browser.

CHAPTER SECTION:3

Section 3 -- The Power of Networking

Networking has changed the face of computing. We once thought of computers as calculating
machines, but now most people rightly view them primarily as communication tools. An Internet
connection is as essential a part of today's computer as a disk drive. The move toward a globally
networked world has been significantly furthered by Java.

The Internet: A World of Connections

Since its birth in the early 1970s as a 12-node network called the ARPANET,3 the Internet has
exponentially exploded into a worldwide network that provides a central piece of the planet's
information infrastructure. Figure 1.2 shows the growth pattern of the Internet from its humble 12-
host beginning through today's some 30-million registered addresses.
 Figure 1.2 Growth of the Internet since its early days as the ARPANET.

Data is from Network Wizards (www.nw.com). The Internet continues to grow at an astounding
rate.

Connecting computers together in a network allows computer users to share data, programs, and
each others' computational resources. Once a computer is put on a network, it is possible to access a
remote machine in order to retrieve data or to use its CPU cycles and other resources. Along with
this ability comes concern about security. Computer security specialists worry about issues such as:

• Who is allowed to connect to a particular machine

• How to determine whether access credentials are being faked
• Who can access which resources on a shared machine
• How to protect data (especially in transit) using encryption
• How and where to collect and store audit trails

Whenever machines are networked, these concerns must be addressed.

The Internet, the world's largest network of machines, has encouraged research into these security
issues. Mechanisms now in place go beyond simple password authentication, to firewalls and
security checking tools such as SATAN, ISS, and Ballista. New ideas in computer security are
constantly becoming available on the Net. Security approaches currently in preliminary use include
encryption-based authentication, encrypted communications, and intrusion detection based on
Artificial Intelligence (AI) [Hughes, 1995; Garfinkel and Spafford, 1996; Ghosh, 1998]. Computer
security has recently matured into a substantial commercial enterprise as well. As in any new field,
however, there is as much hype as there are barrels of snake oil. If it sounds too good to be true, it
probably is. Buyer beware.
 The Web: Making the Internet Enticing

One of the driving forces behind the exponential growth of the Internet in the last several years has
been the introduction of the World Wide Web. In 1992, Tim Berners-Lee, a British researcher at
the CERN physics facility in Europe, invented the Web, a new way to use the Internet. His
invention introduced hypertext markup language (HTML) and Web browsing to the world. In 1993,
Marc Andreessen helped to write the Mosaic Web browser while affiliated with the National Center
for Supercomputer Applications (NCSA). He later cofounded the company now known as Netscape
Communications. Though it may be hard to believe, the Web is only a few years old.

Before the invention of the Web, the Internet was almost exclusively text based. Researchers used
it to transfer files to one another and to keep in touch via email. After the Web was invented, it
suddenly became possible to see graphical pages sent across the Net by Web servers. These Web
pages can include pictures, sound, video, and text, as well as hyperlinks to related pages. A Web
browser provides an easy-to-use, intuitive interface for "surfing," or traveling around the Web,
visiting other people's pages. Figure 1.3 shows how a typical Web page looks when viewed with
the Netscape browser.

Figure 1.3 A view of this book's companion Web site

(www.securingjava.com) as displayed by Netscape Communicator.

All current Web browsers include the capability of running mobile code automatically.

Ease of use is partially responsible for the astonishing numbers of Web users, and perhaps for the
sense of safety that most Web users seem to enjoy. In addition, creating Web pages is a relatively
simple process. HTML editors like Netscape Navigator Gold and Microsoft FrontPage make the
job especially easy. Given one of these editors and a Web server, you have all the pieces you need
to create your own Web site. An alternative to using an HTML editor is to write HTML code
directly. Either way, this snazzy HTML facade makes the Internet more attractive than ever.

As shown in Figure 1.4, the Web has grown just as quickly as the Internet itself. The figure charts a
conservative estimate of the number of Web servers on the Net. It is these servers that allow people
to make Web pages available to everyone. The figure does not properly reflect the number of Web
pages that are out there, which some people number in the hundreds of millions. Keep in mind that
a server has the potential to serve hundreds or even thousands of pages for multiple users
simultaneously.

Figure 1.4 Growth of the World Wide Web, shown as the number of Web servers, since
its introduction in 1993.

Data from the Internet Society (www.isoc.org).

Java: Spicing Up the Web

HTML-based Web pages are certainly a big step up from using the obscure, text-based Unix
incantations of ftp, news, gopher, wais, and telnet to get around on the Net; however, they also have
a major drawback. Much like the page that you are reading now, Web pages are static. Wouldn't it
be better to have interactive Web pages that dynamically change themselves according to feedback
from a user? Wouldn't it be better to program your Web pages to accept input, compute results, and
then display them?

This sort of dynamic activity should ring a bell. After all, programming languages allow people to
program machines to do just these sorts of things. Why not make a programming language for the
Web?

That is the essence of Java. Java is a full-featured programming language that allows programmers
to compose executable content for the Web. The Java language is designed to be usable on all
platforms so that code can move from one machine to another and still work, regardless of the kind
of machine it ends up on. Cross-platform compatibility has always been a stumbling block in
previous attempts to create programming languages for executable content. Mobile code can only
truly be mobile if it can be executed on all platforms without porting and recompiling!

In order to allow Java to run on a computer, the administrator must first install a Java Virtual
Machine (JVM), or a browser that includes a Java VM. The JVM interprets Java instructions and
translates them into machine-specific instructions. This allows Java to be run on many different
types of machines.4 For old timers, the whole idea is reminiscent of P-code from the 1970s.

Having a well-defined, platform-independent definition allows Java to get around problems that
have plagued the C programming language, making C less platform independent than its designers
intended. Unlike C programs, Java programs are not hampered by machine-dependent structures
such as:

• Byte ordering (low or high endian)

• Pointer size (16 or 32 bit)
• Integer size (16 bit, 32 bit, or 64 bit)

Java's careful definition shields it from these platform-specific elements of programming. Each
Java VM is written to a specific platform and translates the more generic Java instructions into
platform-specific instructions.

Java has upped the ante on the Web. The best Web pages now include Java applets that do
everything from displaying selectable news tickers to providing front-end graphical user interfaces
(GUIs) for internal databases. There are even some Web-based videogames written in Java. Java
applets have become commonplace.

The Promise of Java

Java is by far the most popular implementation of Web-based mobile code. Lesser-known
competitors include JavaScript, Safe-Tcl, Telescript, Word macros, Excel macros, ActiveX, and
Postscript. Each of these systems raises its own security issues. Any document-embedded scripting
language that can be transferred around the Net and run on different machines falls under the
classification of executable content.5 Propelled by the marketing powers of Sun Microsystems and
IBM, the Java wave is still building. Java avoids the interactive content limitations that were built
in to forms and CGI (Common Gateway Interface) scripts.6 Java's power lies in the ability to
program complete applications in a real programming language that can then be dynamically
distributed and run by virtually any user over the Web.

CHAPTER SECTION: 4

Section 4 -- Downloading Code: Not a New Problem

In the early days of the Internet, everyone agreed that downloading arbitrary binaries and executing
them on your machine was a bad idea. Of course, most people did it anyway. By the mid 1980s,
there was a lot of freeware and shareware out there to be downloaded. To find it, you could use
archie, which provided a way to search a large index of anonymous ftp content. Once you dug up
some leads (often several ASCII pages worth), you chose your target and ftp'ed what you needed.
Then you installed and ran it.

The risks of running some random person's downloaded-from-the-Net code on your machine are
clear. If the code has a virus attached, your machine can be infected. If the program is a Trojan
Horse that appears to be doing something useful while it is actually doing something nefarious,
your machine can become "owned" by someone else. This is especially dangerous for machines
connected to the Net. How can we be sure that a program that someone says is useful hasn't been
hijacked to do something nasty?

When it works flawlessly, the Java security model provides one possible answer to this question, as
it was designed to allow untrusted programs to be run on a computer safely. As we will see, the
base Java security model is meant to counter the threat of viruses and other forms of attacks. But in
the early days of the Net, Java did not yet exist. (To be completely accurate, Java was evolving in
the early 1990s from an embedded platform called Oak that was meant to be used for smart devices
like that Internet-enabled toaster you've heard so much about.)

Back to our history . . . The question in the late 1980s was, how could a user be sure that a program
had not been hijacked (or Trojan'ed)? Checksumming provided part of the answer. A checksum is a
simple computation performed on a piece of code to provide a digest, or "thumbprint," of a
program. (Combine this with digital signatures and you have a system that can provide both data
integrity and authentication, which is most desirable, as we will discover in Chapter 3.)

Not many people were into checksums back then, but they existed for at least a few anonymously
downloadable programs. Of course, who was to say that a program's checksum hadn't been
tampered with? In reality, most people either ignored the risks or chose to live with them.

Skipping the advent of gopher, which most people pretty much ignored anyway, the next big thing
was the Web. As discussed in the last section, the Web got its start in 1992. At first, the Web was
static. Java changed all that, making it possible for a Web server to provide programs as content.
Java applets are these programs. The dangers of mobile code and systems for addressing these
dangers are the focus of this book. But there's still a drawback, even with the power that Java adds
to the Web-the only way to tell when new content has been added to a Web page is to surf back
over and find out. That's where push technology comes in.

Push: Too Much of a Good Thing?

As if surfing the Web with a Java-enabled browser isn't bad enough security-wise, another new step
in mobile code delivery appears to be "push" technology. Push provides a way to have information
(including mobile code) automatically flow to your machine-without you even asking for it! (Well,
you do have to set things up once in the beginning, but after that, no more clicking.) Now the
inconvenience of clicking on a hyperlink is completely removed. Heck, you don't need to make any
decisions at all. Just sit back and watch the content (which may include Java applets, ActiveX
controls, and client-side scripts) come to you. With push it is possible to subscribe to "channels"
that do things like provide constant stock information, news headlines, and (most dangerously of
all) software updates.

There are many push systems out there. Two of the most popular are Castanet by startup Marimba,
and PointCast by PointCast, Inc. The security systems of Castanet and PointCast are briefly
covered in an article written by McGraw entitled "Don't Push Me: The Security Implications of
Push," which is available at www.developer.com/techfocus/123097_pushsec.html. Push channels
are now available in both Internet Explorer 4.0 and Netscape Communicator.

First off, push is not very well named. It should actually be called "timed pull." Most systems,
including PointCast, work by having a tuner program, which functions like a fancy browser, issue
HTTP requests for information from a push server. (This is the "pull" part.) Once requested, the
information comes back across the Internet as HTML-based HTTP traffic and is eventually
displayed in a special window. PointCast is set up to take over the screen when the computer is not
in use, much like a screensaver program. Every once in a while, the program will wake up and
check for new information, which is grabbed in chunks and sometimes cached. (This is the "timed"
part.)

Let's get this straight: It is still a really bad idea to download and run arbitrary binaries off the
Internet. Automating things so that this happens more easily, behind the scenes, doesn't serve to
make it any less dangerous. We've gone from having to request binaries through the text-based ftp
interface and install them, through clicking on a hyperlink (the Java model), all the way to having
content come to you.

In the meantime, security issues have yet to be properly addressed. How do you know that the
information a push server is sending you is secure? How do you know that the update that was just
pushed onto your PC is really from the company that developed the software? These questions are
familiar ones to people interested in security. What we need to make push systems safe is strong
authentication, foolproof data integrity, and trust in the broadcasters. Current push systems are only
beginning to address security concerns.
 CHAPTER SECTION:5

Section 5 -- Java in a Demitasse

The security concerns raised in this book apply equally to both Java users and Java developers.
Using Java is as easy as surfing the Web. The simple use of Netscape Navigator, Internet Explorer,
or any other Java-enabled browser to run Java applets is a risky activity. In order to really
understand these risks, it is important to gain a deeper understanding of how Java really works.
Here is a short but thorough introduction to the Java language.

The Java development environment comprises three major components:

1. A programming language that compiles into an intermediate, architecturally neutral format

called byte code
2. The Java Virtual Machine that executes the byte code
3. An execution environment that runs on the JVM and provides some base classes useful for
building complete applications

Figure 1.5 shows how these three parts of the Java environment work together to provide
executable content for the Web. The Java Developers' Kit (JDK) is provided free to all. It includes
the three parts of the Java environment outlined here. To get your own copy, point your browser to
URL java.sun.com.

Figure 1.5 How Java implements the original sandbox approach to

mobile code.

Java source code is compiled into Java byte code which is transferred across
the Web to the browser that requested it. The HTML in a Web page specifies
which code is to be fetched from the Web server. The requesting Web
browser, prompted into action when a user clicks on a hyperlink, (1) fetches
the code from the Web, (2) verifies it, (3) instantiates it as a class or set of
classes in a namespace. The applet executes and (4) invokes a dangerous
method (5) causing the Security Manager to be consulted before the method
runs. The Security Manager (6) performs runtime checks base on the calling
class's origin and may veto some activities.

Because Java byte code runs on the Java Virtual Machine, it is possible to run Java code on any
platform to which the JVM has been ported. Some Web browsers, such as Netscape and Internet
Explorer, include an encapsulated version of the JVM. Using their built-in VMs, such Java-ready
browsers can automatically download and execute Java applets when a user accesses an HTML
Web page including the <APPLET> tag.
 The Java Language

One of the first public introductions to Java came in the form of a whitepaper released by Sun (and
since updated many times) [Sun Microsystems, 1995]. An especially pithy sentence from that
document attempts to describe the fundamental aspects of Java all at once. It reads:

Java: A simple, object-oriented, distributed, interpreted, robust, secure, architecture neutral,

portable, high-performance, multi-threaded, and dynamic language. Quite a collection of
buzzwords. In fact, some people joke that Java is "buzzword compliant." This book is concerned
mostly with the security claim, of course, but in order to understand the implications of Java for
computer security, you need to grasp the other important characteristics of the language first.
As the quote claims, Java has many interesting features. They will be briefly introduced here.
Pointers to more information on Java can be found on page 31. The Java language is:
Object-oriented: Unlike C++, which is an objectivized version of C, Java is intrinsically object-
oriented. This changes the focus of programming from the old procedural way of thinking (as in C
and Pascal) to a new data-centric model. In this new model, data objects possess associated
methods. Methods perform actions on data objects. Every Java program is composed of one or
more classes. Classes are collections of data objects and the methods that manipulate these data
objects. Each class is one kind of object. Classes are arranged in a hierarchy such that a subclass
inherits behavior and structure from its superclass. Object-oriented languages were designed using
the physical world as a metaphor. Classes communicate with each other in much the same way that
real physical objects in the world interact.

Strongly typed: This means that a Java program cannot arbitrarily access the host computer's
memory. Memory access by Java programs is limited to specific, controlled areas having particular
representations. Type safety is verified when code is loaded into the JVM by the Byte Code
Verifier (see Chapter 2, "The Base Java Security Model: The Original Applet Sandbox"). In
addition, runtime checks on type safety (such as checks for array bound overflow, type
incompatibility, and local-versus-remote code security policy) are all handled by the Java Virtual
Machine. As we shall see, type safety is essential for Java security. In fact, a majority of serious
Java security attacks target the type system.

Multi-threaded: Java programs can execute more than one task at the same time. For example, a
multimedia Java applet may want to play a sound file, display a picture, and download a file all at
once. Since Java is multi-threaded, it supports the concurrent execution of many lightweight
processes. An obvious benefit of this capability is that it improves the performance of multimedia
applications at the user end. Java's built-in support for threads makes designing such applications
far easier than it is in C and C++. Primitives for synchronization are also provided in Java.

Java has other important characteristics adapted from modern programming languages such as
Scheme (a popular dialect of Lisp) and ML. In particular, Java uses:
Garbage collection: Memory management is usually handled in one of two ways. The old-
fashioned approach is to have a program allocate and deallocate memory itself. This approach
allows all sorts of insidious errors and hard-to-squash bugs. C, for instance, uses this method. By
contrast, Lisp introduced the modern concept of garbage collection in 1959! Garbage collection
requires the system (rather than the programmer) to keep track of memory usage, providing a way
to reference objects. When items are no longer needed, the memory where they live is
automatically freed so it is available for other uses. Java provides a garbage collector that uses a
low-priority thread to run silently in the background. Java's memory management approach has
important implications for the security model since it prevents problems associated with dangling
pointers.

No pointers: This is also a feature of Java's modern memory management scheme. Instead of
allowing access to memory through pointers, memory is managed by reference. The crucial
difference between references and pointers is that references cannot be manipulated through
arithmetical means (as can pointers). This eliminates many potential bugs. Pointers are one of the
most bug-prone aspects of C and C++. Eliminating pointers has the effect of making Java a much
more reliable and safer language.

Exception handling: This defines how the program will manage an error condition. For example,
if a Java program tries to open a file that it has no privilege to read, an exception will be thrown.
Exception throwing and catching is a system for gracefully managing runtime errors that might
otherwise crash a system. This is a good idea if you are concerned about security.

Dynamic linking: Software modules (classes in Java) are linked together as they are needed. The
Java language knows where it should look for classes that need to be linked while a Java program
runs. By contrast, C has a linking phase during which all needed constructs are linked before the
program is run. The linking phase in C is static since library functions are assembled together with
other code into a complete executable at compile time. Dynamic linking makes it easier to keep
Java programs up-to-date since the latest version of a class will always be used. This can turn out to
be a problem for programs that expect a class to behave the way it has in the past and are surprised
when a new version appears. Version control and software assurance become much more
complicated with dynamic linking too. Java finds classes that it needs by searching for them in
locations specified in the CLASSPATH environment variable (though the system is undergoing
revision for Java 2). (As we will discuss in Chapter 2, it turns out to be very hard to ensure type
safety when dynamic class loading is allowed.)

Though it has more than doubled in size since its original introduction, Java is still a relatively
simple language. This is especially apparent when Java is compared with C and C++ [Daconta,
1996]. In C, there are often many possible ways in which to do the same thing. Java tries to provide
only one language mechanism with which to perform a particular task. Also, Java provides no
macro support. Although some programmers like using macros, macros often end up making
programs much harder to read and debug.

The designers of Java made their language simple by removing a number of features that can be
found in C and C++. Things that were removed include the goto statement, the use of header files,
the struct and union constructs, operator overloading, and multiple inheritance. Together with the
elimination of pointers, removal of these aspects of C and C++ makes Java easier to use. This
should result in more reliable code.7

We will revisit the impact that Java's features as a language have on security in Chapter 2.
 Portable Byte Code and the Java Virtual Machine

The second major component of the Java development environment is the Java Virtual Machine.
The VM makes Java's cross-platform capabilities possible. In order to run Java byte code on a new
platform, all that is required is a working VM. Once the VM has been ported to a platform, all Java
byte code should run properly.

Making a byte code/VM pair that works well on many varied platforms involves setting a few
things in stone. Java has variables that are of fixed size and of fixed format. An integer in Java is
always 32 bits, no matter what the word size of the machine running Java. Making data formats
machine independent and compiler independent is crucial to making Java truly portable. The very
different way in which variables are managed on different C platforms causes no end of portability
problems for C programmers.

The VM also makes use of symbolic data stored inside of Java byte code files. Java byte code
contains enough symbolic information to allow some analysis of the byte code before it is run. This
is one way the Java environment ensures that Java's language rules have been followed by the
compiler-something critical to security. Rules checked include, for example, type safety rules, and
ensuring that certain things claiming to be of a certain type actually are of that type. Since the Java
byte code Verifier is a critical part of the security model, it is discussed in detail in Chapter 2.

Using a Virtual Machine has obvious important repercussions for the Java approach. The VM
makes portability possible, and it helps to ensure some of Java's security features. Since Java is
often implemented using an interpreter, speed can be an issue. Interpreted languages are inherently
slow because each command must be translated to native machine code before it can be run. With a
compiler, this work is all done ahead of time, when an executable is created for some particular
platform. Without just-in-time (JIT) and hotspot compilers, Java's interpreted code is about 20
times slower than native C code. When this new technology is used, Java speeds begin to approach
native C.

Reusable Class Modules

The third part of the Java development environment is a set of predefined classes that implement
basic functionality. The "personal" version of the JDK includes, for example, an Abstract
Windowing Toolkit (AWT). These classes provide a set of graphical user interface (GUI) tools for
creating windows, dialogue boxes, scrollbars, buttons, and so forth. Java also includes classes for
full network support that provide application program interfaces (APIs) for sockets, streams, URLs,
and datagrams. A POSIX-like I/O system with APIs for files, streams, and pipes makes the
environment comfortable for experienced Unix programmers. Classes are grouped together into
packages according to their functionality. Table 1.1 lists the packages included in the Java
Developers' Kit (JDK) version 1.1. Note that Java's core classes have grown significantly in the last
few years.
 PACKAGE DESCRIPTION

java.applet The applet class.

Abstract Windowing Toolkit: The AWT provides graphics, GUI

java.awt components, and layout managers. A new event model was introduced
with JDK 1.1.

Inter-application data transfer support, including clipboard cut-and-

java.awt.datatransfer
paste.

java.awt.event Classes and interfaces for the new AWT event handler.

java.awt.image Image processing classes.

java.awt.peer Interface definitions for GUI components and platforms.

java.beans The JavaBeans API for creating reusable software components.

java.io Input/output classes: A relatively large number of classes for I/O.

Central Java language classes: Defines Object, Class, and primitive

java.lang
types.

Classes that allow a Java program to examine Java classes and to

java.lang.reflect
"reflect" on its own structure.

Two classes that support arithmetic on arbitrary-size integers and

java.math
arbitrary-precision floating-point numbers (important for cryptography).

java.net Networking classes.

java.rmi Classes and interfaces for Remote Method Invocation.

java.rmi.dgc Distributed garbage collection.

Classes and interfaces for tracking, naming, and advertising remote

java.rmi.registry
objects.

java.rmi.server The heart of the RMI system.

Classes and interfaces that define fundamental cryptographic services.

java.security
(See Chapter 3.)

java.security.acl Access control list interfaces.

 Interfaces required for the Java Security API's implementation-
java.security.interfaces
independent design.

java.sql Java Database Connectivity (JDBC) API.

java.text Classes and interfaces for internationalization.

Miscellaneous but critical classes. These classes are required for many
java.util
others.

java.util.zip Classes for manipulating zlib, ZIP, and GZIP file formats.

The predefined Java classes provide enough functionality to write full-fledged programs in Java.
Using the predefined classes as primitives, it is possible to construct higher-level classes and
packages. Many such home grown packages are available both commercially and for free on the
Net.

The World of Java Applications

In the early days of Java's popularity, most Java programs took the form of applets, small programs
that were attached to Web pages and loaded and run in Web browsers. As Java developed, people
began to write substantial applications in Java, using it simply as an improved version of traditional
languages such as C.

Java has always been good for more than writing applets, and the world is now catching on to that
fact. Java is really a good platform for any application that needs to be extended or customized,
perhaps across the network, after it is deployed. A browser is only one example of such an
application.

Another increasingly popular use of Java is in Web servers. Many servers have extension
mechanisms, but the Java Servlet API provides a particularly flexible and compelling vehicle for
extending a server with new application-specific or site-specific functions. Most major Web servers
now support the Java Servlet API. Compared to browsers, servers present more difficult security
challenges, since servers have more stringent reliability requirements and store more valuable data.

Java's features also make it a good platform for creating new server-type applications. With natural
support for multithreading, database access, and networking, Java gives developers a natural leg up
in designing such applications. For these reasons, Java is being used increasingly in enterprise
computing.

One common structure for such systems uses a "three-tier" architecture. A traditional database
server acts as the "back end" tier, storing and managing the data needed to support a business
application. The middle tier is a Java-enabled specialized server that interacts with the database and
implements the "business logic" needed to manage client interactions with the system. The "front
end" tier is a Java applet that runs in the client's Web browser and provides a convenient user
interface so that users can interact naturally with the system. Three-tier systems put together several
uses of Java and, as a result, face a wide array of security issues.

In addition to all of these applications in traditional computers, Java is being deployed in embedded
devices such as smart cards, key rings, and pagers. Embedded applications are often involved in
electronic commerce systems, adding yet another series of twists to our security story.

The growing variety of applications is reflected in the subject matter of this book. While the first
edition focused almost exclusively on applet security issues, this edition encompasses the full
breadth of today's Java applications. We want to provide you with the information you need to
know to maintain security while building, deploying, managing, and using up-to-date, Java-based
systems. As Java has gotten down to business, so has this book.

Trust, Applets, and Applications

Java is much more than simply a language for creating applets. In the early days of Java (less than a
handful of years ago), it was important to distinguish applet code (which was typically treated as
untrusted and relegated to the sandbox) and application code (which was typically treated as fully
trusted built-in code). This distinction is no longer a useful one.

An alternative way to carve up the Java program space is to think about code in terms of levels of
trust. Programs that are more trusted can be allowed to carry out potentially dangerous acts (like
writing files). Programs that are less trusted will have their powers and permissions curtailed.

If we think about Java programs this way, it is still possible to make sense of the old distinction
between applets and applications. Java applets are usually, though not necessarily, small programs
meant to be run in the context of a Web browser. Obviously, applets involve the most client-side
(or user) security concerns of any Java programs. In fact, Java's security policies originally existed
in order to make applets feasible. The Java runtime enforces severe limitations on the things that
applet classes may do [McGraw and Felten, 1996]. See www.javasoft.com/sfaq and Chapter 2 for
details. In terms of the new trust-based distinction, applets are clearly treated as untrusted. This
makes sense, since the origin of an applet is often unknown or unfamiliar.

In the early days of Java, Java applications had no such restrictions. In terms of our trust
distinction, applications in Java before Java 2 were treated as completely trusted code. That meant
applications could use the complete power of Java, including potentially dangerous functionality.

The reason the old distinction between applets and applications no longer makes sense is that today,
applets can be fully trusted and applications can be completely untrusted. (Note the use of the word
can in the previous sentence; we don't mean to say that applets are always trusted or that
applications are never trusted.) In fact, depending on the situation, each and every Java program
can be trusted, partially trusted, or untrusted. Sound complicated? That's because it is.
With the introduction of Java 2, Java includes the ability to create and manage security policies that
treat programs according to their trust level. The mechanisms making up the base sandbox are still
under there somewhere, but they serve merely as a default situation to handle code that warrants no
trust. The interesting thing is that code that is partially trusted can be placed in a specially
constructed custom sandbox. That means a partially trusted applet can be allowed to, say, read and
write a particular file or make a network connection to a particular server. This is good news for
Java developers who were chafing under the constraints of the restrictive original sandbox.

Figure 1.6 illustrates the way in which the old applet/application distinction can be recast in terms
of black-and-white trust. It also shows the impact that Java 2 has on the black-and-white trust
model, transforming it into a shades-of-gray trust model.

Figure 1.6 From black-and-white to shades-of-gray.

The distinction between applets and applications found to be useful during the JDK
1.0.2 days no longer applies to mobile Java code based on the Java 2 model. In
fact, all along the real distinction behind the scenes was between fully trusted code
and fully untrusted code. A black-and-white distinction between trusted code and
untrusted code underlies both JDK 1.0.2 and JDK 1.1. By contrast, the Java 2
approach to trust management implements a policy-oriented shades-of-gray
architecture. Under Java 2, code can be constrained or unconstrained regardless
of whether it is applet or application code.

The Many Flavors of Java

Currently, a large and growing number of Java systems are running the gamut from Java gizmos
(including Java rings), through smart cards with built-in Java interpreters, to complete Java
Development Kits and IDEs. As with any platform meant to interact in a networked world, there
are security concerns with each flavor of Java. This book discusses security risks that apply to all
flavors of Java, but will focus on Java 2 and Card Java 2.0.

Counterintuitively, Java is both growing and shrinking at the same time. The JDK, now up to Java
2, is doubling in size with each major release. At the same time, embedded Java systems like Card
Java 2.0 are stripping Java functionality down to bare bones. Both of these moves have important
security implications. Java 2 involves fundamental changes to the Java security model as the Java
sandbox is metamorphosing into a trust-based system built on code signing. Card Java 2.0 removes
much of the sandbox, leaving smart card applets more room to misbehave.

All of Java's built-in security functionality, including the recently added authentication and
encryption features (which began to appear with JDK 1.1), are available to Java application
developers. This functionality makes it possible for an application to establish its own security
policy. In fact, Java-enabled browsers do just that, determining the security policy by which all
applets that run inside them must abide. For obvious reasons, an applet is not allowed to change the
browser's (or for that matter, any application's) security model!

CHAPTER SECTION:6

Section 6 -- Securing Java

Security risks fall into four basic categories: system modification, invasion of privacy, denial of
service, and antagonism. These four categories of risk are discussed in detail in Chapter 2. The first
two of our risk categories are handled moderately well by Java; the second two are not. Risks are
particularly egregious in Java since exploiting vulnerabilities is simply a matter of booby-trapping a
Web page with a malicious applet or two. Chapter 4, "Malicious Applets: Avoiding a Common
Nuisance," and Chapter 5, "Attack Applets: Exploiting Holes in the Security Model," discuss two
distinct forms of hostile applets. Java applets with bad intentions-exploit scripts-are the equivalent
of every security administrator's nightmare [Garfinkel and Spafford, 1996].

Java's designers are well aware of many of the risks associated with mobile code. To combat these
risks, Java was specifically designed with security concerns in mind. The main goal was to address
the security issue head-on so that naïve users (most of the millions of Netscape Navigator and
Internet Explorer users) would not have to become security experts just to surf the Web.

In its default form, Java presents a multitiered approach to security. At a general level, the tiers
include:

• Restricted access to file systems and the network

• Restricted access to browser internals
• A set of load time and runtime checks to verify that byte code is following the rules
• A system for signing code and assigning it some level of capability

The Java security model will be detailed in Chapter 2 and Chapter 3. Many claims have been made
about the security of the Java language. We will try to separate reality from marketing hype in
order to better understand the Java security model. Java also provides a set of tools with which a
developer can produce security-critical code (for both applets and applications). In addition to a
number of advanced language features like array bounds checking and byte code validation, Java
provides:
 • A set of cryptographic APIs for standard algorithms
• Cryptography engines that provide the guts for a small subset of the APIs
• A strong, stack-based security system

Although this book is not just a guide to Java's security APIs, we will discuss Java's security
functionality in detail. In particular, we will emphasize that no computer language as powerful as
Java makes writing security-critical code automatic or easy.

CHAPTER SECTION:7

Section 7 -- How Does Java Security Stack Up?

As we have mentioned, Java is not the only game in town when it comes to mobile code. Other
mobile code systems include JavaScript, Safe-Tcl, Telescript, Word macros, Excel macros,
ActiveX, and Postscript. Of these systems, the one most often touted as a direct competitor to Java
is Microsoft's ActiveX (sometimes called DNA depending on the whim of Microsoft marketeers).
So what does ActiveX do for security, and how does it compare with Java's approach? Besides
ActiveX, what other mobile code systems present security risks?

ActiveX Security Issues

The first thing to know about ActiveX is that it does not have an enforcement-related security
model. It has a trust model that may be able to help you implement your own security policy. So
the real question is: How does a trust model like ActiveX's compare with a sandbox like Java's?

Sandboxes and Signatures

There are two major approaches addressing the security concerns raised by mobile code systems:
sandboxing and code signing. The first of these approaches, sandboxing, is an idea embraced by
early implementations of Java (say, JDK 1.0.2). We extensively cover the Java sandbox in Chapter
2. The idea is simple: Make untrusted code run inside a box and limit its ability to do risky things.
That is exactly what the Java security model aims to do.

The second approach, code signing, is how the ActiveX Authenticode system works. Binary files,
such as ActiveX controls or Java class files, can be digitally signed by someone who "vouches" for
the code. If you know and trust that person or organization, you may choose to trust the code that
they vouch for. It is important to stress the fact that code signing is completely a matter of trust;
there is no enforcement mechanism protecting you once you decide to trust a piece of code. The
trust model implements authentication and authorization. What this means is that there is no such
thing as ActiveX security enforcement! That's not to say signature-based trust models are not
useful. They are. In fact, trust models will play an integral role in future security models for mobile
code. Much more detail on code signing, especially as it relates to Java, is found in Chapter 3,
"Beyond The Sandbox: Signed Code and Java 2."

Code Signing and ActiveX

ActiveX is a high-profile form of mobile code promoted by Microsoft. Note that in practice its
"mobility" is completely constrained to one platform, however. As it is actually used today,
ActiveX is language independent, but not platform independent, meaning that real ActiveX controls
work only on Microsoft's Win32 platform (Windows 95, Windows 98, and Windows NT).
Technically, these controls could be recompiled for other platforms, but virtually nobody currently
produces controls for non-Win32 platforms.

One caveat: Comparing ActiveX and Java is somewhat like comparing apples and oranges, even
though everyone does it. ActiveX is a component-based software model while Java is a
language/platform. ActiveX should really be compared with Java components, JavaBeans. (In fact,
some argue that the real religious Holy War between Java and ActiveX is destined to take place in
the middleware arena and will be decided by the battle of component models [Lewis, 1998].)

ActiveX has been roundly criticized by computer security professionals since its approach to
security is seen as lacking. Unlike the base Java security situation, in which an applet has to run in
the sandbox and is limited in the sorts of things it can do, an ActiveX control has no limitations on
its behavior once it is invoked. The upshot is that users of ActiveX must be very careful only to run
completely trusted code. On the other hand, Java users have the luxury of running untrusted code
fairly safely.

The ActiveX approach relies on digital signatures, a kind of encryption technology in which
arbitrary binary files can be "signed" by a developer, distributor, or certifier. Because a digital
signature has special mathematical properties, it is very difficult to forge. That means a program
like your browser can verify a signature, allowing you to be fairly certain who vouched for a piece
of code (as long as people are carefully guarding and managing the private keys used to sign code).
To make things easy, you can instruct your browser always to accept code signed by some party
that you trust, or always to reject code signed by some party that you don't trust. The signature also
supplies data integrity, meaning it can ensure that the code you received is the same as the code that
was originally signed. Signed code cannot be easily hijacked and modified into a Trojan Horse.

The ActiveX system provides a black-and-white trust model: Either you trust the code completely
and allow it to run unhampered on your machine, or you don't. That means trusting the wrong sort
of code just once is all it takes. Once an attack control runs on your system, it can rewrite your
security policy in such a way that all future attacks will work. Of course, it can do anything at all,
so this is only one of zillions of attack scenarios. Serious attacks using ActiveX have been seen in
the wild (although their use is not widespread). For an explanation of these attacks and more on
ActiveX insecurity, see Anup Ghosh's book E-Commerce Security: Weak Links, Best Defenses
[Ghosh, 1998].
Sandboxes versus Signatures
Do digital signatures make ActiveX more attractive security-wise than Java? No, especially in light
of the fact that digital signature capability became available in Java's JDK 1.1 and, in combination
with fine-grained access control, plays a major role in Java 2 security. That means in Java, you get
everything that ActiveX is doing for security plus the ability to run untrusted code fairly safely.

Another significant factor is that the sandbox approach is more robust in the face of accidental bugs
in mobile programs. Even if the sandbox isn't bulletproof, it will most likely prevent a bug in a
mobile program from trouncing important data or programs by mistake.

As we shall see in Chapter 3, when combined with access control, code signing allows applets to
step outside the security sandbox gradually. In fact, the entire meaning of sandbox becomes a bit
vague. As an example of how Java code-signing might work, an applet designed for use in an
Intranet setting could be allowed to read and write to a particular company database as long as it
was signed by the system administrator. Such a relaxation of the security model is important for
developers who are chomping at the bit for their applets to do more. Writing code that works within
the tight restrictions of the sandbox is a pain, and the original sandbox is very restrictive.

Microsoft's Authenticode and Security Zones

When a signed ActiveX control is downloaded, the browser detaches the signature block (which is
a signed one-way hash of the control packaged together with a standard X.509 certificate issued by
a certificate authority) and performs checks on the identity of the signer using Authenticode. This is
a two-step process. First the certificate is examined by checking the certificate authority's identity.
Then the one-way hash is checked to ensure that the same code that was signed was the code that
arrived. Note that these checks say nothing at all about whether a control will or will not behave
maliciously. They only check the identity of the signer and that the code has not changed since
signing.

Microsoft Internet Explorer 4.x implements a security zone concept meant to ease the management
of security policies for signed content such as ActiveX controls and Java applets. The system
organizes Web sites into four "zones of trust" (or more if you customize): Local intranet zone,
Trusted sites zone, Internet zone, and Restricted sites zone. Each zone can be configured with
security levels of: High (most secure), Medium (more secure), Low, or Custom. The idea is to
divide Web sites into these zones and assign the zones varying levels of trust.

Figure 1.7 shows a dialog box from Microsoft Internet Explorer (MSIE) that allows a user to
manage Authenticode security zones.
 Figure 1.7 Authenticode's signature-based trust model
implements the concept of security zones in order to aid in
managing mobile code.

Microsoft Internet Explorer provides a dialog box that users can

access to manage security zones. Though the importance of powerful
policy management tools cannot be overstated, some security
professionals complain that allowing a user to set security levels is
not a good idea-especially if high security correlates with high level of
annoyance (through implementing, for example, too many security
queries).

Zones are a useful tool that can help make a security policy more coherent. The concept may be
particularly useful in non black-and-white policy situations currently beyond the scope of ActiveX.
We think security zones are a useful tool that Java security systems beyond Microsoft's should
support as well.

In ActiveX with security zones, the security policy itself remains black and white: A mobile
program is either fully privileged or completely banned from the system. Since most users are
inclined to run cool-sounding code just to check it out regardless of the risk, popping a dialog box
in front of a user and requiring an instant security decision is not a good idea. As one of the authors
(Felten) is known to say, "Given a choice between dancing pigs and security, users will pick
dancing pigs every time." The Princeton team correctly warns that relying completely on a human-
judgment-based approach to security in not likely to be as successful as blending judgment with
technology-based enforcement, as newer Java systems do. See Figure 1.8.
 Figure 1.8 Given the choice between dancing pigs and security, the world will pick dancing pigs
every time."

The dancing pigs applet, available through the book's Web site (www.securingjava.com), demonstrates
the use of digital signatures in Java. See Appendix C.

One way in which Authenticode addresses this problem is to put the security decisions in the hands
of a system administrator. Using the MSIE Administration Kit (IEAK), an administrator can
preinstall a list of permitted certificates and block the installation of others. This is a step toward
centralizing security policy management (which is something most corporate users demand).
However, in the end, the ActiveX model is still only a trust model. Just for the record, Netscape
now includes a similar site-wide policy administration system.

We discuss these issues of trust, identity, and signatures again in more detail in Chapter 3, though
the focus is on Java and not ActiveX.

More on ActiveX Security

The Princeton Team has written an FAQ, reprinted in Appendix A, called Security Tradeoffs: Java
versus ActiveX, in which a number of common questions about Java and ActiveX are answered.
On the Web, the FAQ can be found at www.cs.princeton.edu/sip/java-vs-activex.html.

Two other good places to look are in Chapter 2 of E-Commerce Security by Anup Ghosh [Ghosh,
1998] and page 18 of Web Security Sourcebook by Avi Rubin, Dan Geer, and Marcus Ranum
[Rubin, Geer, and Ranum, 1997].

JavaScript

Another mobile code system is JavaScript (Microsoft's version is called JScript). Note that other
than the four letters-J, A, V, and A-JavaScript has nothing in common with Java. In the early days,
JavaScript was known as LiveConnect, but once the marketing folks at Netscape saw the Java wave
building, they decided to ride along. JavaScript allows code to be directly contained in HTML
documents themselves, code that can dynamically change the HTML that a Web user ultimately
sees through a browser.

JavaScript has its own security headaches. Though it is not an ultra-powerful scripting language,
JavaScript can easily be used to carry out denial of service and invasion of privacy attacks. Much
more discussion about denial of service is found in Chapter 2. JavaScript was used extensively in
the Princeton Team's Web Spoofing attack [Felten, et. al., 1997].

To find out more about JavaScript security, a good place to start is at John LoVerso's JavaScript
security site:www.camb.opengroup.org/~loverso/javascript/. On his JavaScript Problems I've
Discovered page, LoVerso describes JavaScript attacks that:

• Track a surfer's history, secretly keeping tabs on all sites visited by a user and reporting back
to a collection site
• Read directory listings, learning about a Web surfer's file system and reporting back to a
collection site
• Steal files, mailing the stolen goods back to an attacker
• Construct Java tags, circumventing systems that attempt to block Java applets by removing
the <APPLET> tag. (For more on why this approach to stopping Java applets is silly,
seeChapter 6.)

Make sure that your mobile code security policy (you have one, right?) addresses JavaScript as well
as Java.

What Does All This Have to Do with Java?

The important take-home message of this section is that Java security concerns do not exist in a
vacuum. If someone tells you that you should disable Java, but pays no attention to these other
threats, he or she is not doing you much of a favor. The truth is, much scarier things than Java are
out there. In fact, many of the attacks we have touched on here pale in comparison to security
concerns raised by a Windows 95 PC connected to the Internet. Try to put all of the security
concerns relevant to you on the same scale, and address the biggest risks first.

CHAPTER SECTION:8

Section 8 -- Where to Find More Information on Java

Java is growing rapidly, and keeping up with it requires as much energy as looking after a herd of
two-year-olds (believe us, we know). Keeping up with the edge is just as important for security
purposes as it is for any other. Here are some resources that can help make a time investment worth
it.
 Java on the Web

An excellent place to start learning about Java is the Web itself. The first URL to check is JavaSoft
(java.sun.com). Also useful are developer.comand JavaWorld. MindQ sells a set of excellent CD-
ROMs that provides a multimedia introduction to programming Java applets and applications
(among other issues). See its Web page for details at www.mindq.com. (MindQ produced the
authors' Java Security CD-ROM as well.) To discover some of the many other Java resources on
the Net, search for Java at Yahoo! or on AltaVista. Also see two collections of security-related Java
links put together by the authors at www.securingjava.com and at www.cs.princeton.edu/sip. The
references section of this book includes a complete listing of all URLs cited throughout the book.

Java Books

The number of books on Java is growing almost as fast as the Web itself, and the Java shelf is
groaning under their combined weight. For a comprehensive list,
see lightyear.ncsa.uiuc.edu/~srp/java/javabooks.html. We have had a chance to use a few of them
as Java coders. Here are four, with a brief review for each:

Core Java Volume 1-Fundamentals [Horstmann and Cornell, 1997]. This is a good book; big,
but definitely useful. In fact, Core Java got so big that it split into two volumes for the JDK 1.1
edition. It is full of comparisons to C++ and Visual Basic, including useful pictures. The
authors provide implementations for other classes that are not in the Java libraries, but are
commonly used.

Inside the Java Virtual Machine Specification [Venners, 1997]. For anyone interested in the
inner workings of Java's Virtual Machine, this is the book to get. As we'll see, Java applet
security boils down to what byte code is allowed to do and how its behavior can be
constrained. That means that learning about how the VM does its thing is a useful exercise for
those people concerned about security.

Java in a Nutshell, second edition [Flanagan, 1997]. This book remains everyone's favorite
(well, every developer anyway), probably because it is so useful. O'Reilly is famous for its API
books and, true to form, this book provides an extensive API for the packages provided by
Java. This makes it excellent for a quick desk-side reference. There are some examples, but if
you learn best by examples, you should consider Java Examples in a Nutshell [Flanagan,
1997]. Both books are equally useful for beginners and more advanced Java programmers.

Java Network Programming [Hughes, Shoffner, and Winslow, 1997]. One of the best reasons
to use Java as a development platform is to take advantage of its built-in networking ability.
This excellent book is filled with hands-on examples that are included on a CD-ROM. Of
particular interest to security buffs, a number of cryptography algorithms are presented. Note
that there is an O'Reilly book of the same title (this one is from Manning); however, this is the
one to get.
Java Security Resources
We're glad to say the amount of information available on Java security is also growing. There are
both a number of books available and a large number of Web sites. On the Web, we provide the
most comprehensive and up-to-date hotlist-the Java Security Hotlist-at www.securingjava.com. The
hotlist, which has over 100 links divided into 9 categories, has been reproduced as Appendix B,
"The Java Security Hotlist." Of course URLs are notoriously dynamic, and Java security is a fast-
moving field. For the latest version of the hotlist, see the Web site.

The Secure Internet Programming Lab at Princeton also maintains a site with information on
security alerts and ongoing Java Security research atwww.cs.princeton.edu/sip/.

Java Security Books

For at least a year, the first edition of this book, Java Security: Hostile Applets, Holes, & Antidotes,
was the only available book on Java security. Since that time, a number of other books have come
out that address the topic. Of course, we are biased about which one is best, but we thought you
might appreciate our opinions about the others anyway: Java Security: Hostile Applets, Holes, &
Antidotes [McGraw and Felten, 1996]. The first book on Java security. This book was intended to
educate Web users about the risks of Java security. It includes a discussion of the base Java security
model and the original Java security holes. We're glad we wrote it.

Java Network Security [Macgregor, et al., 1998]. This book appeared in 1998 and includes
information on JDK 1.1, but nothing on Java 2. The book has a number of technical errors and
unintentionally misleading claims about security as well. If you want a copy of everything ever
written on Java security, get a copy; otherwise this one is skippable.

Java Security [Oaks, 1998]. O'Reilly is well known for its developer-oriented books. This book
fits the bill, as it provides both an API reference guide and a number of code samples. It is
almost up to date (the switch to the doPrivileged() API discussed in Chapter 3 is not covered
by Oaks) and carefully details Java 2 functionality. One caveat: Oaks is an employee of Sun
Microsystems and certainly toes the party line. The discussion of security risks and
implications reflects this fact. Also missing is any treatment of Java security holes.
Nevertheless, if you are a developer who wants to learn about the APIs and you don't care too
much about the bigger picture, this book is for you.

The Web Security Sourcebook [Rubin, Geer, and Ranum, 1997]. Although this is not a Java
security book per se, many of the lessons this book teaches are entirely relevant to people
interested in Java security. This is a practical, hands-on book that covers Web server security,
mobile code, CGI, and more, written by security experts of the highest caliber. E-Commerce
Security [Ghosh, 1998]. Java is often put to use in e-commerce systems, and of course, e-
commerce systems must take security very seriously. This book provides essential data for
securing your e-commerce system. It discusses common errors, real attack targets, and
solutions.

CHAPTER SECTION:9
 Section 9 -- Mobile Code Has Its Price
Having programs embedded in Web pages that can run on any platform is an excellent idea. But in
order to get this power, users take a great deal of risk.

A Web surfer can click over to a Web page with an embedded applet that immediately and
automatically begins executing. Often, the user doesn't even know this is happening. This situation
might not be so bad if the Java environment being used were 100-percent secure. However, to make
Java really secure would require making it completely impotent.8

There is a price that must be paid for the power of executable content. This price is very similar to
the price that must be paid in order to connect to the Internet in the first place. (In fact, if you
decide Java security risks are too much to bear, you should ask yourself what you are doing
connected to the Internet at all!) The bill is payable in terms of risk and exposure to attack. The
question is, how much risk are you willing to take? How critical is the information on your
machine? Our goal in writing this book is to arm the reader with the data that are needed to make
an informed, intelligent decision about Java, both as a system for mobile code and as a
development platform.

Downloading Mystery Code

How often do you download executable code from various unknown sites on the Net? Do you think
about where the code is coming from and who wrote it? Do you know what it will do before you
run it?

Even if you are particularly cautious about downloading binaries from the Net, the answers to the
questions raised will undoubtedly soon change. Applets are cropping up everywhere. At the
moment, surfing the Web with a Java-enabled browser is tantamount to downloading and running
arbitrary binaries, albeit with some level of security provided by Java. Deciding whether this is a
good idea is an important decision that is as personal as a financial investment strategy.

It is worth repeating that there is no such thing as perfect security. This is true for any system on
the Internet, not just systems using Java. Someone will always be probing Java security, trying to
find new ways around or through the existing system. In the real world, all you can expect is
reasonable security. The solution to this conundrum is finding an acceptable tradeoff between
functionality and security.

Playing the Cost/Benefit Game

The Internet can be a dangerous playground. Java offers an intriguing approach to the problem of
security by neither ignoring it entirely (as most languages do) nor being completely paralyzed by it.
Deciding what level of risk to incur is really a matter of weighing the potential costs of using Java
against the clear benefits of using Java. Making an informed and intelligent decision requires
understanding both aspects of the situation. Business people are always weighing costs and benefits
when making complicated decisions. The same sort of careful consideration that goes into forming
a business plan should also go into the formulation of a Java use policy.

The Java hype machine has been exceptionally good at broadcasting the benefits of Java. It has
been successful largely because Java really does have vast potential. On the other hand, the
advertising has been slightly less straightforward about the risks. (To this day we hear claims that
Java is 100-percent secure, or that there is no need to worry about Java security.) This may be
because the risks are complicated and sometimes difficult to understand. Computer security is a
new field to many users, and few people are aware of all the issues. As Java applets become
ubiquitous, it behooves us to become more aware of security issues. Ignorance is not bliss.

CHAPTER SECTION:10

Section 10 -- Assessing the Risks

Now that the basics of the Java environment have been covered, you are ready to examine Java
security in earnest. It is only after understanding what the security model is, how it works, and how
it doesn't, that you can truly begin to assess the security situation.

People should think carefully about using Java even casually with a Java-enabled browser. This
book will present some of the facts associated with Java security so that you may decide when,
where, and how to use Java. Unfortunately, there is no black-and-white answer to the question:
How and when should I use Java?

The Base Java Security Model:

The Original Applet Sandbox
Java is designed so that programs can be dynamically loaded over the network and run locally. This
very powerful paradigm promises to change the face of computing as we know it. A browser that
can interpret Java byte code (such as Netscape Navigator or Internet Explorer) can download and
locally execute applets that are embedded in a Web page. This activity of downloading and
executing is completely automatic, requires no user approval, and sometimes occurs without the
user even knowing. Remember, by simply pointing your browser at a Web page containing an
applet, you start Java. Any applet started in this fashion is not required to advertise its presence.
More and more Java applets appear on the Web every day. Applets are becoming ubiquitous. This
means that surfing the Web with a Java-enabled browser is a more risky activity than surfing the
Web in the days before Java.
It is extremely unlikely that all users of Java-enabled browsers will consider the security
implications of surfing a site before each Web page access. If the mobile code paradigm is going to
work, security concerns should be addressed in the language of the content itself. That way, users
will not need to worry too much about security. Java's designers took this task to heart. One of their
fundamental concerns was making the use of Java transparent, automatic, and above all, safe. As a
result, Java was developed with key security issues in mind.

It is clear that the Java development environment attempts to address the security problems
introduced by the idea of dynamically downloading and running external, untrusted code. To what
extent Java succeeds in this task is a subject of debate. Security concerns have always been one of
the major technical stumbling blocks to achieving safe mobile code. Java took these concerns
seriously and made a good effort to protect Web users. In this chapter, we present the original (or
base) Java security model and discuss how it mitigates some of the risks that applets introduce.

The original Java security model presented in this chapter implements a sandbox that imposes strict
controls on what certain kinds of Java programs can and cannot do. To the extent that the sandbox
works, it allows a user to run untrusted code safely. As we discussed in Chapter 1, "Mobile Code
and Security: Why Java Security Is Important," an alternative approach to handling mobile code is
to run only code that is trusted. ActiveX controls, for example, are omnipotent and should be run
only when you completely trust the entity (person or corporation) that signed the control. It is clear
that future mobile code systems will involve both a sandbox model and a trust model based on code
signing. In fact, the two will likely be so intertwined that they cannot be easily teased apart. This is
already happening in Java.

There are many ways to impose a sandbox model on executable content-Java presents just one.
Since the Java sandbox model has been widely distributed to millions of users with their Web
browsers, it is safe to say that the Java sandbox is today's most widely used sandbox model. Until
recently, it was correct to assume that a Java sandbox placed particular constraints on Java applets.
JDK 1.1 changed all that; and as we pointed out in Chapter 1, the notion of a sandbox is becoming
ever more complex.

With the introduction of JDK 1.1, Java's sandbox model underwent a state transition from a
required model applied equally to all Java applets to a malleable system that could be expanded and
personalized on an applet-by-applet basis. The addition of code signing to Java complicates things
immensely. As it now stands, the Java sandbox we detail in this chapter has been reduced to a
default. Chapter 3, "Beyond the Sandbox: Signed Code and Java 2," discusses how things work
when this default sandbox policy is not used.

Chapter Two Sections

1. Potential Threats
2. What Untrusted Java Code Can't Do
3. What Untrusted Java Code Can Do
4. The Java Language and Security
5. The Three Parts of the Default Sandbox
6. The Verifier
 7. The Class Loader Architecture
8. The Security Manager
9. Different Classes of Security
10. Type Safety
11. Browser-Specific Security Rules
12. The Fundamental Tradeoff
13. Is There Really a Java Security Policy?

The Base Java Security Model: The Original Applet

Sandbox
CHAPTER SECTION:1

Section 1 -- Potential Threats

Java applets are far more powerful than the usual HTML code served up on the Web. When not
restricted by applet-security measures, Java is a complete and powerful programming language
capable of sending information over the network; reading, altering, or deleting files; using system
resources; and so on. This is powerful stuff, and in the hands of a malicious programmer (or even
just a sloppy or incompetent programmer), Java code could do some damage to a user's system.
People surfing the Web should not be burdened with such worries (although developers and system
administrators unfortunately must be). So from a user's perspective, Java should put these worries
to rest by providing an automatic security solution. Java should restrict itself such that the full
power and potential of the Java language is not misused. After all, who wants to run a Java applet
that erases your hard disk? And who wants to develop or distribute an applet that accidentally
erases someone else's hard disk?

The design problem lies in the fact that programs running on a personal computer usually have
unlimited access to all of the machine's resources. (That's what we mean when we say that ActiveX
controls are omnipotent.) Most PC applications are total system tyrants while they run. But if the
Java applets you retrieve from the Web have been written by someone else, you should not trust
them to perform with integrity. Unless you grant Java code special privileges, Java downloaded
from the Net is automatically considered untrusted code. In order to ensure that untrusted code does
nothing mischievous, it is important to limit what that untrusted code can do. Of course, completely
limiting access to a system defeats the purpose of having executable content in the first place. After
all, who wants to run a program that is not allowed to do anything? And who wants to develop or
distribute such a program?
Somehow these two extremes need to be balanced. Java applets need enough power to do some
things and sufficient restrictions so that they can't do others. The solution is controlling access to
system resources carefully. This is what the Java security model aims to do.

Before we talk about the internals of the Java security model, it is important to discuss the potential
problems raised by mobile code. There are four basic categories of potential attacks Java applets
could facilitate:

• Attacks that modify the system

• Attacks that invade a user's privacy
• Attacks that deny legitimate use of the machine by hogging resources
• Attacks that antagonize a user

Table 2.1 lists the four classes in order of severity. There will be a brief discussion of each in turn.
Keep in mind that this list of attacks is meant only to give a flavor of the kinds of things possible; it
is by no means a complete list. Also note that the four attack classes overlap. As we shall see,
hostile applets often fall into more than one category.
ATTACK JAVA
EXPLANATION AND CONSEQUENCES
CLASS DEFENSE

The most severe class of attacks. Applets that implement

System
such attacks are attack applets. Consequences of these Strong
Modification
attacks: severe.

If you value your privacy, this attack class may be

Invasion of particularly odious. They are implemented by malicious
Strong
Privacy applets. Include mail forging. Consequences of these
attacks: moderate.

Also serious but not severely so, these attacks can bring
Denial of a machine to a standstill. Also implemented by
Weak
Service malicious applets. May require reboot. Consequences of
these attacks: moderate.

Merely annoying, this attack class is the most commonly

encountered. Implemented by malicious applets. May
Antagonism Weak
require restart of browser. Consequences of these
attacks: light to moderate.
Figure 2.1

The relative severity of the four attack classes varies depending on the situation. For a lone user
browsing on a personal computer, system modification attacks and privacy attacks are serious, but
the other two classes are only a mild inconvenience. For big enterprise servers, however, attacks
that antagonize employees and customers or deny them service altogether are serious issues.

System Modification
Java is a very powerful programming language, and with this power comes the potential for abuse.
Most programming languages give programs the ability to read and modify data on the system
where they are running. Java includes predefined classes with methods that can delete and
otherwise modify files, modify memory, and even kill processes and threads. System modification
attacks comprise the most critical risks. Java's designers have given much thought to preventing
this class of attack.

In the most serious cases, system modification involves intrusion into the system itself. Like many
parts of today's complex systems, Java can be misused as an avenue of attack. Given that crackers
will use any tool available to compromise the security of a machine, special care must be taken to
ensure that Java does not provide new ports of entry to a machine. That Java is designed to work on
many different platforms makes this task that much more important.1

The good news is that using Java to break into a machine is not easy. The bad news is that such
break-ins are certainly possible. This book refers to applets that implement system modification
attacks as attack applets. Attack applets are a serious concern. In Chapter 5, "Attack Applets:
Exploiting Holes in the Security Model," you will see how several such attacks have been
successfully discovered and applied in the laboratory. Patches have been developed that make these
attacks impossible, but the threat of other sophisticated attacks remains.

A good example of a system modification attack involves a security hole discovered in JDK 1.1.1
by the Princeton team in February 1997. The hole has since been fixed. The particular hole was a
problem in the way code signing was implemented. As a result of a simple error in the JDK 1.1.1
code signing system (returning a mutable array on a Class.getsigners() method call instead of a
copy of the array), an attack applet signed with a fake signature could escape the sandbox
completely and acquire all the privileges available to completely trusted code. Once outside the
sandbox, the attack applet could do anything at all, including installing a virus or a Trojan Horse.
Put in simple terms, any machine attacked through the code signing hole could be completely
compromised. More detail on the code signing hole and an attack applet called the Magic Coat is
found in Chapter 5.

With so many machines running mission-critical applications, system modification attacks could
lead to problems such as modified financial records in a database, which could in turn lead to
financial loss and corporate bankruptcy. Modified medical records could result in fatally incorrect
treatment. Care must be taken not to expose critical systems to new lines of attack. Crackers flock
to the latest and greatest vulnerabilities. It is important that Java not become a cracking vehicle.

It is important to emphasize that no system modification attacks using Java have been seen outside
the lab. That's lucky because if one of these attacks were invented by crackers, Java viruses could
become a reality. Attack applets designed to carry out system modification attacks are the subject
of Chapter 5.

Invasion of Privacy
A second general type of attack involves disclosing information about a user or host machine that
should not be publicized. Some files are meant to be kept confidential. For example, on Unix
machines, if someone gains access to the /etc/passwd file (which contains usernames and encrypted
passwords) he or she could mount a password-cracking attack. A successful password-cracking
attack is a complete invasion of a machine and can be escalated into a system-modification attack.

Sensitive information of other sorts can also be leaked from a system. Consider the implications of
an unscrupulous company being able to steal the secret business plans of a competitor through
corporate espionage. Or, if you are not a corporate user, consider your private email
correspondence or your financial records being made public. If such confidential information is
mailed or otherwise transferred off a system, the act can be called an invasion of privacy.

A particularly egregious risk, especially in today's e-commerce systems based on the use of
cryptography, is loss of a private key. Consider that in Utah, legislation can be enacted into law
through the application of a digital signature. If the governor's private key falls into the wrong
hands, legal ramifications would be interesting at best (and disastrous at worst). Private keys should
be among the most closely guarded secrets in existence.

Most modern workstations include sound capability. This opens up users to a new kind of
eavesdropping. If an attacker can gain control of the microphone, then it is possible to listen in on
the area immediately surrounding the workstation. More subtle eavesdropping includes monitoring
process tables and file access. A Web-based version of eavesdropping might include keeping track
of which links a user follows.

Forging mail could also be construed as a kind of invasion of privacy attack. If an outsider can gain
enough information to forge mail that appears to be from you, then you are exposed to a large
number of serious risks. As is discussed in Chapter 4, "Malicious Applets: Avoiding a Common
Nuisance," Java makes the standard mail-forging attack a much more serious threat. Java
successfully defends against some of these attacks. For example, file I/O is very closely guarded.
However, this good feature is countered by the fact that applets always have a channel open back to
their original host server. Should the applet somehow dig up some information, it would be very
easy to send that information back to the original host server. Non-file-related members of the
invasion of privacy class (such as mail forging) are harder to defend against. Short of defenses such
as disabling a system's network ports, the mail forging attack is likely to remain a threat.

Denial of Service

Denial of service attacks make system resources unavailable. They occur, for example, when a
process eats up more than the standard allotment of resources, essentially hogging the machine.
There are many subcategories of denial of service attacks. Some examples include:

• Completely filling a file system

• Using up all available file pointers
• Allocating all of a system's memory
 • Creating thousands of windows, effectively denying access to the output screen or window
event queue
• Using all of the machine's cycles (CPU time) by creating many high-priority threads

There are also some types of denial of service attacks that do not hog the systems resources, but
lock up the system in some other way; for example, by acquiring a lock on some critical system
resource, or by causing the system to wait for an input or output operation that can never complete.
Although denial of service attacks are a real concern, Java's designers were not able to protect users
from this class of attacks.

There is some debate over the relative importance of stopping denial of service attacks. In most
cases, denial of service is more closely related to the class of annoyance attacks than to anything
else. This is because recovering from a denial of service attack is usually not difficult (simply
reboot the machine). But some computer systems perform very important, even mission-critical
tasks. Denial of service to such a machine could be very serious. Consider the mayhem that would
erupt should a malicious program lock up the machines running the stock market. Losses could be
staggering.

Denial of service attacks are by far the most commonly encountered Java security concern.
Implementing such an attack is not hard, but stopping one is. Malicious applets, the subject of
Chapter 4, often make use of denial of service attacks. Unfortunately, the current security model
does not offer a good solution to the denial of service problem. Planned enhancements to the Java
security model promise to lessen the threat posed by denial of service attacks. Security experts
know, however, that denial of service attacks are very tough to prevent, so we expect Java will not
have strong defenses against denial of service any time soon.

If you are running a Java-enabled server application, you should be worried about denial of service
attacks. If your server is configured to allow untrusted clients to upload "servlets" into your server,
then any Internet user, anywhere in the world, can upload a denial of service servlet and crash your
server. Your best defense is to make sure your server is configured to accept servlets only if they
are written by people you trust. Remember, the Java sandbox does not protect you against denial of
service attacks. Figure 2.1 shows how servlets differ from applets.

Figure 2.1 Servlets in Java are the server-side equivalent of

applets for the client.

The idea is to provide a VM inside a Web server on which servlets can

 be run to carry out tasks once delegated to CGI scripts. When mobile
code runs on a Web server, the risk of denial-of-service attack carries
more importance. Servlets often access back-end databases on behalf
of a Web server.

Antagonism

Less odious, but still of some concern, are attacks that merely antagonize or annoy a user. Playing
unwanted sound files through a speaker or displaying obscene pictures on a monitor are two
examples. Sometimes seemingly antagonistic attacks may be the result of simple programming
errors. Chapter 4 contains some examples of antagonistic malicious applets.

Some denial of service attacks could be classified as merely antagonistic. A denial of service attack
that opens many windows simultaneously, for example, can be reduced to an annoyance depending
on the window manager in use. Many window managers require user intervention to place a
window and, thus, open only one window at a time. Judging the severity and category of a
particular attack is always a subjective and context-sensitive problem. This is no reason to pretend
that such categories do not exist. In order to more thoroughly understand the risks associated with
mobile code, these attacks need to be considered.

Java Risks in Perspective

It is important to emphasize that using Java is not the only way to carry out the four classes of
attack discussed previously (system modification, invasion of privacy, denial of service, and
antagonism). In fact, the risk of being hit with a non-Java-based system modification attack is much
greater than the risk of an attack applet exploiting a hole in the Java security model to modify your
system. There are countless non-Java examples of all four of attack classes sprinkled throughout
the computer security literature. If you are interested in these topics, one of the most encyclopedic
sources of information is the book Computer Related Risks by Peter G. Neumann [Neumann,
1995]. In any case, the book you're reading now is about Java security, so we will emphasize Java's
vulnerability to attacks and protections against these attacks.

Java's designers are primarily concerned with stopping the worst potential attacks that hostile
applets might carry out; that is, system modification and invasion of privacy attacks. One kind of
mobile code that everyone wants to avoid is a computer virus. Though viruses traditionally target
personal computers and have yet to make much of a dent in the networked Unix world, Java might
well have changed all that. Fortunately, Java's security model seems to have been successful so far
in thwarting the possibility of cross-platform viruses. Simply put, there have been no Java applet
viruses (yet).2

That is not to say, however, that a Java virus is impossible. Despite claims to the contrary, any hole
in the security sandbox would allow a Java virus to propagate. A system modification attack on a
user's browser could choose to modify that user's homepage (and any other Web pages it could
find), thereby propagating itself virus-like onto more Web pages.
The remaining attacks, denial of service and antagonism, are much harder to stop. Denial of service
can be as simple as using all system resources, and it is sometimes hard to decide what constitutes a
legitimate but taxing use of, say, your CPU, and what is an attack. The same thing goes for
annoyance. A thread that never dies in one applet may be useful (if the applet is doing something
like perpetually updating a stock quote in a window), while a thread that never dies in a hostile
applet may be doing something evil such as monitoring your Web usage.

For a number of reasons, the market appears to consider Java security risks important. It all started
when Sun included "secure" in the Java buzzwords list. The research community took this as a
challenge, and the holes described in this book began to be discovered. These days, perceived Java
security risks may, in fact, outstrip actual risks, though any such judgment needs to be made on a
case-by-case basis.

One side effect of the large amount of attention paid to Java security is the proliferation of Java
security vendors who market products that attempt to block all Java applets, scan applets for what
might be hostile behavior before they run, or banish Java applet code to a central "sacrificial"
server. If you are considering any of the many Java security enhancement products on the market,
one good exercise is to ask how successful such products are in practice against each of the four
attack classes introduced here. We will revisit this topic in Chapter 6, "Securing Java:
Improvements,Solutions, and Snake Oil."

CHAPTER SECTION:2

Section 2 -- What Untrusted Java Code Can't Do

Trusted Java applications do not have the same security implications as untrusted applications
(including a majority of applets found on the Web). Thus, with a trusted application, it is possible
to read and write files, communicate with devices, connect to sockets, and so on. But untrusted
code is different. Clearly, untrusted code needs to be stopped from doing some of these things.
Untrusted access to the more powerful features of Java must be properly restricted.

From the perspectives of both end users and system administrators, the most important Java
security issues crop up when we talk about applets. Applets are Java's most pervasive version of
mobile code (servlets have a bit of catching up to do). There are many things that untrusted Java
applets should not be allowed to do and many resources to which Java applets should have only
restricted access. The Java sandbox imposes these restrictions. With the introduction of Java 2, it is
possible to treat applications as untrusted as well-running them inside the sandbox.

Applets can be related to the traditional client/server model in a straightforward manner: The Web
server is the applet's server. It sends the applet to the client machine. The client is the machine on
which the applet eventually runs. That means when you are surfing the Web and come across an
applet, your machine is the client. This terminology is useful for explaining what applets are not
allowed to do.
Note that the following list of no-no's defines only one commonly encountered kind of Java
sandbox. Up until the advent of JDK 1.1, all Web-based applets were required to adhere to these
rules (although enforcement was up to the browser being used). These days, sandboxes come in
many assorted shapes and sizes. Untrusted applets that have not been granted special privileges are
relegated to the default sandbox of the old days. Partially trusted applets can be given more leeway
(or put another way, they can be given a larger sandbox to play in). As we shall see in Chapter 3,
the size and shape of a Java sandbox is now at a Java user's complete discretion. Though we present
the following list of constraints in terms of untrusted applets, untrusted applications can be run
within the default sandbox as well. The sandbox, which is the base Java security model,
implements the default constraints. If an untrusted applet has been loaded across the network and
the default security policies are intact, the applet is not allowed to:

• Read files on the client file system.

• Write files to the client file system.
• Delete files on the client file system, either by using the File.delete() method, or by calling
system-level rm or del commands.
• Rename files on the client file system, either by using the File.renameTo() method, or by
calling system-level mv or rename commands.
• Create a directory on the client file system, either by using the File.mkdirs() methods or by
calling the system-level mkdir command.
• List the contents of a directory.
• Check to see whether a file exists.
• Obtain information about a file, including size, type, and modification timestamp.
• Create a network connection to any computer other than the host from which it originated.
• Listen for or accept network connections on any port on the client system.
• Create a top-level window without an untrusted window banner.
• Obtain the user's username or home directory name through any means, including trying to
read the system properties: user.name, user.home, user.dir, java.home, and java.class.path.
• Define any system properties.
• Run any program on the client system using the Runtime.exec() methods.
• Make the Java interpreter exit, using either System.exit() or Runtime.exit().
• Load dynamic libraries on the client system using the load() or loadLibrary() methods of the
Runtime or System classes.
• Create or manipulate any thread that is not part of the same ThreadGroup as the applet.
• Create a ClassLoader.
• Create a SecurityManager.
• Specify any network control functions, including ContentHandlerFactory,
SocketImplFactory, or URLStreamHandlerFactory.
• Define classes that are part of packages on the client system.

Java applets are typically executed by Web browsers with embedded Java Virtual Machines (VMs)
and runtime class libraries. Applets are downloaded by the browser and then executed by the built-
in VM on the machine running the browser. The security of the system depends on these parts of
the model: the Java language itself, the runtime class libraries, and the Security Manager of the
browser. The next section examines how the Java compiler and runtime system restrict the creation
and distribution of malicious code.

CHAPTER SECTION:3

Section 3 -- What Untrusted Java Code Can Do

An alternative approach to presenting the sandbox is to define what untrusted applets can do. After
all, if applets were allowed to do nothing, security concerns would be completely alleviated. In
order to run, untrusted applets require access to the CPU of the client machine as well as access to
memory in which to build objects. Access to both of these resources is completely controlled by the
VM. The default sandbox for untrusted applets also includes access to the Web server from which
the applet was downloaded. Programmers not used to such constraints often complain that the
default sandbox is too restrictive; for example, the inability to read and write temporary files must
be designed around.

The good news (for developers, anyway) is that Java 2 allows the user to give a digitally signed
applet access to more local resources. The bad news (for users and administrators) is that in terms
of the usual tradeoff between functionality and security, more powerful applets present more risk.
In any case, applet developers are likely to code their applets to make use of local files, peripherals,
and networked resources. Then the applets will be digitally signed. In order for a signed applet to
run on a client machine, the administrator of the machine must set up a security policy that grants
the particular applet access to the resources it needs. Setting up and administering these policies is
not a trivial exercise. See Chapter 3 for more on these issues.

CHAPTER SECTION:4

Section 4 -- The Java Language and Security

Many of the features of Java as a language (as introduced in Chapter 1) have important security
implications. This is important for everyone: for developers charged with creating secure code; for
users who must in the end rely on developers' products; for system administrators who install,
configure, and manage the products; and for managers who decide which products are developed
and how they are deployed. It is a well-known fact in computer security that security problems are
very often a direct result of software bugs. That leads security researchers, including the authors, to
pay lots of attention to software engineering. The hope is to avoid the ever-present penetrate-and-
patch approach to security by developing more secure code in the first place. Although Java is no
silver bullet, it can certainly help.

Object-orientation and a modern memory model both turn out to have a positive impact on Java
security. The notions of data hiding, abstraction, and encapsulation, in particular, can help
encourage better design for security. In Java, objects cannot be directly manipulated by a
programmer; instead, they can only be accessed through their public interfaces. This is a good
thing. Programmers cannot directly access memory either, but must use object references. This fact
makes it much harder for a nasty program to trawl through memory looking for interesting data
such as passwords and credit card numbers.

All of these features also help to make Java programs a bit more robust (on average) than programs
written in other popular languages. After all, mechanisms that prevent programs from deliberately
accessing memory that should be off-limits will also prevent buggy programs from accidentally
accessing the wrong memory. Since most security flaws exist because of programming bugs,
anything that reduces the general level of bugginess in software is good for security. Java helps
conscientious programmers reduce the odds that their code contains security bugs.

Every object and primitive data element in Java has a built-in access level associated with it, either
the explicit private, protected, or public access level, or a default access level.

• Private variables and classes can only be accessed by the class that created them.
• Protected variables and classes can only be accessed by the class that created them, the
creator's subclasses, and classes in the same Java package.
• Public variables and classes are accessible by all classes.
• By default, entities in a class can be accessed by code within the class that defines them, or
by a class in the same package as the class that defines them.

The access levels should be mostly familiar to C++ developers, although the Java definitions differ
slightly. (Access levels star in one of Java's security holes, as we will see in Chapter 5.)

There is an essential difference between languages like C++ and Java that stems directly from
Java's requirement that objects can only be manipulated through standard interfaces. In C++, a
programmer could declare certain variables inside an object private, but then access these variables
in sneaky ways. Though the C++ compiler may stop obvious front-door operations (for example,
not allowing an arbitrary class to access private elements of another), the back door is wide open.
Using pointer arithmetic, casting, and other such means, a C++ programmer can scan through a
program's allocated memory (and in fact, manipulate memory) at will. Why anyone would
deliberately do such a thing inside his or her own code is an interesting question (although it might
be done accidentally), but this sort of thing matters in Java where distinct applets that don't trust
each other may share the same VM. The access levels described here help address this concern.
Also helping to safeguard memory in Java are the following:

• Objects and methods declared final cannot be changed or overridden (ignoring this rule
would seriously break the Security Manager, among other things).
• Array bounds are checked for all array accesses (putting to rest a very common mistake that
plagues C).
• Object casting is restricted (necessary to ensure type safety).
• Variables cannot be used before they are initialized (another memory-protection
mechanism).
• Garbage collection automatically frees memory when it is no longer needed.
Type safety is certainly a key language feature in Java. It is important enough to Java security that
it deserves its own section (see page 74). For now, suffice it to say that making sure the VM does
not become confused about the kinds of objects it is using is essential. This is pretty obvious if you
think about the fact that the security model itself is a collection of classes with certain types.

In this section, we have covered a nice set of features of Java that can help make it easier to write
secure code (and help you rest easier if you use such code). However, how are these rules
enforced? That is up to the Java sandbox.

CHAPTER SECTION:5

Section 5 -- The Three Parts of the Default Sandbox

In addition to many safety-related characteristics of the Java language, Java security relies on a
multipart defense. The default sandbox is made of three interrelated parts: the Verifier, the Class
Loader, and the Security Manager. In the early days (way back in 1996), people often referred to
the Java security model as a "three-layer" defense. Though such a label is still encountered at times
in the Java security literature, it is misleading. The layer terminology implies that if an applet
penetrates the first "layer," two layers are left to set things straight. Actually, the parts are more like
links in a chain: If any of the three parts breaks, the entire security system breaks. Figure 2.2
emphasizes that for the security model to work, each of its parts must work perfectly.

Figure 2.2 The original sandbox model has three parts.

The three parts are: the Verifier that helps ensure type safety, the Class
Loader that loads and unloads classes dynamically from the Java runtime
environment, and the Security Manager that acts as a security gatekeeper
guarding potentially dangerous functionality. This figure emphasizes that
each of the three parts must do its job properly for the sandbox to work. If
any of the three parts fails, the security model is completely compromised,
leaving the door wide open for attack.

With the introduction of JDK 1.1 and Java 2, the Java security model was extended to include more
parts. First came the java.security package. This package is an API that includes both a
cryptographic provider interface (by which different cryptography implementations can be added
into Java) and APIs for common cryptographic algorithms. (These are sometimes called the
"security" classes, though this is a misnomer. Security consists of much more than just
cryptography.) It is this functionality that allows the VM to authenticate signed Java classes.
Another part, the Access Controller, was introduced with JDK 1.1 and significantly enhanced with
Java 2. We learn more about the security package and the Access Controller in Chapter 3.

The next three sections are each devoted to one part of the base security model: the Verifier, the
Class Loader, and the Security Manager. Each of these parts depends in some way on the others.
For the security model to function properly, each part must do its job flawlessly, and the parts must
fit together perfectly. Between them, the three parts perform load time and runtime checks in order
to restrict file system and network access (as well as restricting access to browser internals).

CHAPTER SECTION:6

Section 6 -- The Verifier

Recall that when a Java program is compiled, it compiles down to platform-independent Java byte
code. As Figure 2.3 shows, Java byte code is verified before it can run. This verification scheme is
meant to ensure that the byte code, which may or may not have been created by a Java compiler,
plays by the rules. After all, byte code could well have been created by a "hostile compiler'' that
assembled byte code meant to violate the rules of the Java VM; created directly with an editor like
emacs; created almost directly with a Java byte code assembler like Jasmin; or compiled from
another source language like C++, Scheme, or Ada into Java byte code. The important thing is not
what the source code looked like or even what language it was written in, but what the byte code
(the code that actually ends up running) does. In this sense, the Verifier makes mystery code a bit
less mysterious.

Figure 2.3 The Verifier scrutinizes byte code before it is allowed

to be run on a local VM.

The Verifier plays an essential role in Java's language-based

approach to security, which is built on the foundation of type safety.

Verifying class files containing byte code is one way in which Java automatically checks untrusted
code before it is allowed to run. Once Java code has been verified, it can execute in uninterrupted
fashion on a VM (with much less need to make security-critical checks while the code runs). This
strategy leads to improvements in the efficiency of Java execution, which offset the speed concerns
raised by Java's security checking. The Verifier is built in to the VM and cannot be accessed by
Java programmers or Java users. In most Java implementations, when Java code arrives at the VM
and is formed into a Class by the Class Loader, the Verifier automatically examines it. The Verifier
checks byte code at a number of different levels. The simplest test makes sure that the format of a
code fragment is correct. On a less-basic level, a built-in theorem prover is applied to each code
fragment. The theorem prover helps to make sure that byte code does not forge pointers, violate
access restrictions, or access objects using incorrect type information. If the Verifier discovers a
problem with a class file, it throws an exception, loading ceases, and the class file never executes.
The verification process, in concert with the security features built into the language and checked at
runtime, helps to establish a base set of security guarantees.3

The Verifier also ensures that class files that refer to each other preserve binary compatibility.
Because of Java's ability to dynamically load classes, there is the possibility that a class file being
dynamically linked may not be compatible with a referring class. Binary incompatibility problems
could occur when a library of Java classes is updated or when a class from a large Java program is
not recompiled during development. There are rules of compatibility that govern the ability to
change use of classes and methods without breaking binary compatibility [Venners, 1998]. For
example, it is okay to add a method to a class that is used by other classes, but not okay to delete
methods from a class used by other classes. Compatibility rules are enforced by the Verifier.

Binary incompatibility also has security implications. If a malicious programmer can get your VM
to accept a set of mutually incompatible classes, the hostile code will probably be able to break out
of the sandbox. This problem happened several times with early VM implementations. (See, for
example, You're Not My Type, in Chapter 5.)

Java users and business people investigating the use of Java in their commercial enterprises often
complain about the length of time it takes for a Java applet to get started running in a browser. E-
commerce system designers paint startup delay as a business-side show stopper, citing the fact that
consumers do not react well even to a 20-second delay in their shopping experience. Many people
believe falsely that the main delay in starting applets is the time it takes to download the applet
itself. But given a reasonably fast connection to the Internet, what takes the longest is not
downloading the code, but verifying it. The inherent costs of verification fit the classic tradeoff
between functionality and security to a tee. As security researchers, we believe the security that
byte code verification provides is well worth the slight delay. We also think it is possible to speed
up the verification process so that its execution time is acceptable.

In order to work, the Verifier reconstructs type state information by looking through the byte code.
The types of all parameters of all byte code instructions must be checked, since the byte code may
have come from an untrustworthy source. Because of this possibility, the Verifier provides a first
line of defense against external code that may try to break the VM. Only code that passes the
Verifier's tests will be run.

The process of Verification in Java is defined to allow different implementations of the Java VM a
fair amount of flexibility. The VM specification lists what must be checked and what exceptions
and errors may result from failing a check, but it does not specify exactly when and how to verify
types. Nevertheless, most Java implementations (especially the most widely used commercial
VMs) take a similar approach to verification. The process is broken into two major steps: internal
checks that check everything that can be checked by looking only at the class file itself and runtime
checks that confirm the existence and compatibility of symbolically referenced classes, fields, and
methods.

Through the two kinds of checks, the Verifier assures a number of important properties. Once byte
code passes through verification, the following things are guaranteed:

The class file has the correct format, including the magic number (0xCAFEBABE) and
proper length. (Much of this trivial checking can take place as a class file loads.)

Stacks will not be overflowed or underflowed. Overflowing stacks is a common attack on

programs written in other languages such as C that has led to several of the most notorious
security vulnerabilities. For example, the Internet worm used stack overflow as part of its
arsenal [Spafford, 1989]. Java assigns each thread two stacks: a data stack and an operand
stack. The data stack is the kind of stack C programmers are all too familiar with. It includes a
series of frames that hold local variables and provide some storage needed for method
invocation. The Verifier cannot prevent overflow of the data stack, and a denial of service
attack that takes advantage of this fact can be trivially implemented with a recursive function.
(A demonstration applet that carries out this attack can be found
at www.cs.nps.navy.mil/research/languages/DynApplet.html.) The operand stack (which is
itself allocated on the data stack) holds the values that each method invocation in Java byte
code operates on. This is the stack that the Verifier tracks and evaluates.

Byte code instructions all have parameters of the correct type. For example, integers are
always used as integers and nothing else. Method descriptors, which include both a return type
and the number and types of parameters, are checked with a context-free grammar [Venners,
1998].

No illegal data conversions (casts) occur. For example, treating an integer as a pointer is not
allowed. Correctly handling all potential casting combinations is a tricky undertaking. The
rules are complex, making a perfect implementation nontrivial. Although many checks are
done by the Verifier, some are deferred until runtime.

Private, public, protected, and default accesses are legal. In other words, no improper
access to restricted classes, interfaces, variables, and methods will be allowed.

All register accesses and stores are valid. Computer scientists refer to the meaning of a
language as its semantics, and the structure of a language is its syntax. When you are thinking
about what a language can do, it is useful to talk about semantics. The semantics of the Java
language provide much of Java's built-in security. It is critical that the semantics of Java be
enforced in each and every Java program. Byte code is designed to contain enough symbolic
information that safety verification (double-checking the compiler-enforced safety rules) can
occur. Byte code specifies the methods of a class as a set of Java Virtual Machine instructions.
These instructions must pass a battery of tests before they can be run.

Class Files and Byte Code

When Java source code is compiled, the results of the compilation are put into Java class files,
whose names typically end with the .class or .cls extension. Java class files are made up of streams
of 8-bit bytes. Larger values requiring 16 or 32 bits are composed of multiple 8-bit bytes. Class
files contain several pieces of information in a particular format. Included in a class file are:

• The magic constant (0xCAFEBABE)

• Major and minor version information
• The constant pool (a heterogeneous array composed of five primitive types)
• Information about the class (name, superclass, etc.)
• Information about interfaces
• Information about the fields and methods in the class
• Debugging information

[Sun Microsystems, 1996b; Sun Microsystems, 1996c] Much more information on class file
formats and byte code syntax can be found in [Venners, 1998].

The byte code inside a class file is made up of instructions that can be divided into several
categories. Among other things, byte code instructions, called opcodes, implement:

• Pushing constants onto the stack

• Accessing and modifying the value of a VM register
• Accessing arrays
• Manipulating the stack
• Arithmetic instructions
• Logic instructions
• Conversion instructions
• Control transfer
• Function return
• Manipulating object fields
• Invoking methods
• Creating objects
• Type casting

Since it exists at the level of the VM, Java byte code is very similar to assembly language. Each
line of byte code is a one-byte opcode followed by zero or more bytes of operand information. All
instructions (with the exception of two table lookup instructions) are of fixed length.

Opcodes and their associated operands represent the fundamental operations of the VM. Every
method invocation in Java gets its own stack frame to use as local storage for variable values and
intermediate results. As discussed earlier, the intermediate storage area part of a frame is called the
operand stack. Opcodes refer to data stored either on the operand stack or in the local variables of a
method's frame. The VM uses these values as well as direct operand values from an instruction as
execution data.

Internal Checks
Considered one level above the nitty-gritty level, class verification (of which byte code verification
is a crucial step) is usually said to occur in four passes. The first three passes implement the
Verifier's internal checks. The last pass implements the runtime checks. (Why runtime checking is
considered a part of the load-time verification process is a mystery to us, but Sun seems to have
convinced everyone to call it a fourth verification pass, so we'll go along.) The passes are:

1. Ensure that the class file is in the proper format. This includes checking the magic number
and making sure that all attributes are of the right length. The byte code cannot be too short
or too long, and the constant pool is able to be parsed.
2. Verify anything that can be done without looking at the opcodes. This includes the following
checks:
1. final classes cannot be subclassed, and final methods cannot be overridden.
2. Every class must have a superclass (except the class java.lang.Object).
3. The constant pool must satisfy more stringent constraints.
4. All field references and method references in the constant pool must have legal
names, legal classes, and a legal type signature.
3. Verify the byte code using data-flow analysis. At any given point in the byte code program,
no matter how that point is reached, all of the following must hold:
1. The operand stack is always the same size and includes the same types.
2. Register access is checked for proper value type.
3. Methods are called with the appropriate number and types of arguments.
4. Fields are modified with values of the appropriate type.
5. All opcodes have proper type arguments on the stack and in the registers.
6. Variables are properly initialized. (See [Sun Microsystems, 1996c].)
4. Perform at runtime any checks that were not done at verification time. Some of these checks
might have been impossible at verification time since some aspects of Java's type system
cannot be statically checked, and some checks might have been deferred to runtime for
implementation convenience.

Step 3, in which the actual byte code is verified, is a complex process that is carried out in two
passes by Sun's Verifier. (Other vendors' Verifiers may behave differently.) The first pass identifies
individual opcodes and stores them in a table. Once all opcodes are identified, the second pass
parses each opcode's operands. During the second pass, a structure is built for each byte code
instruction. This structure is evaluated for syntactic correctness by checking that:

• Flow control related instructions branch to valid instructions.

• Local variable references are legal (associated with the proper method).
• Use of constant pool entries follows typing rules.
• Opcodes have the correct number of arguments.
• Exception handlers start and end with valid instructions, and the start point comes before the
end point.

These checks, along with data flow analysis that tracks behavior of the operand stack and local
variables, make up Step 3.

Runtime Checks and Dynamic Loading

In addition to the internal verification steps, some runtime checks occur during class execution. For
example, whenever an instruction calls a method, or modifies a field, the runtime checks ensure
that the method or field exists, check the call for the proper form, and check the executing method
for access privilege.

In practice, the internal checks performed by the Verifier occur very soon after the VM loads a
class file. Loading all possible classes that might be called in a particular execution of a class is not
the most efficient approach. Instead, Java loads each class only when it is actually needed at
runtime.

In order to verify a class, the VM must load in the definition of any not-yet-loaded class that is
referenced by the class being verified. More precisely, the class being verified refers to some other
classes by name, and the VM needs to decide exactly which class each name refers to, so it can
replace the reference-by-name with a reference to a specific class object. This process is known as
dynamic linking, and has proven to be a persistent source of security problems.

As in the Verifier's internal checking, dynamic linking can throw an error should it fail. An invalid
reference happens when a referenced class does not exist, or when a referenced class exists but
does not contain some referenced field or method. Once an error of this sort is thrown, the class file
doing the reference is no longer considered valid.

The main benefit that the Verifier provides is that it speeds up execution by removing much of the
checking that would otherwise have to occur at runtime. For example, there is no runtime check for
stack overflow since it has already been done by the Verifier.

Checking the Checker

The Verifier disallows many obvious approaches to byte code manipulation. Nonetheless, a number
of researchers have succeeded in creating byte code that should be illegal, but nevertheless passes
the Verifier. The Princeton Secure Internet Programming team was the first to sneak attacks
involving illegal byte code past the Verifiers. Mark LaDue, creator of the Hostile Applet Home
Page (www.rstcorp.com/hostile-applets), performs a number of interesting experiments in which he
creates byte code that does not play by the rules and yet passes verification. Other Java security
researchers, most notably the Kimera group at the University of Washington, have discovered
problems in commercial Verifiers. Their work places special emphasis on correct verification. We
have more to say about the Verifier and Java holes in later chapters.

The Java Runtime and the Verifier

The Verifier acts as the primary gatekeeper in the Java security model. It ensures that each piece of
byte code downloaded from the outside plays by the rules.4 That way, the Java VM can safely
execute byte code that may not have been created by a Java compiler. When the Verifier finds a
problem in a class, it rejects the malformed class and throws an exception. This is obviously a
much more reasonable behavior than running buggy or malicious code that crashes the VM.
In order for the Verifier to succeed in its role as gatekeeper, the Java runtime system must be
correctly implemented. Bugs in the runtime system will make byte code verification useless. Most
of the available Java implementations appear to be mostly correct (see Chapter 5), but behavior
may vary from one implementation to another.

It would be nice for Sun or other interested parties to create comprehensive validation and
verification test suites for the entire Java development environment and publish the results of
testing the various Java implementations. Existing test suites have neither been completely
developed nor verified by outside experts. From a security perspective, this certainly presents a
problem. It is especially critical to verify any third-party Java environment to ensure that it properly
implements the Java run time. Without a guarantee of bug-free run time, Java security falls to
pieces. Java users should think carefully about the Java run time product that they use.

We should note, though, that one cannot construct a test suite that will find all security problems.
Although testing technology is improving, it can never be perfect-not even in theory. All we can
hope for is that security testing technology will find most of the bugs in new code before it is
released.

CHAPTER SECTION:7

Section 7 -- The Class Loader Architecture

ne of the central tenets of Java is making code truly mobile. Every mobile code system requires the
ability to load code from outside a system into the system dynamically. In Java, code is loaded
(either from the disk or over the network) by a Class Loader. Java's class loader architecture is
complex, but it is a central security issue, so please bear with us as we explain it.

Recall that all Java objects belong to classes. Class loaders determine when and how classes can be
added to a running Java environment. Part of their job is to make sure that important parts of the
Java runtime environment are not replaced by impostor code. The fake Security Manager shown in
Figure 2.4 must be disallowed from loading into the Java environment and replacing the real
Security Manager. This is known as class spoofing.

Figure 2.4 Spoofing occurs when someone or something

pretends to be something it is not.

In this figure, an external class has arrived from the Internet and
declares itself to be the Security Manager (in order to replace the real
Security Manager). If external code were allowed to do this, Java's
security system would be trivial to break.
Class loaders perform two functions. First, when the VM needs to load the byte code for a
particular class, it asks a class loader to find the byte code. Each class loader can use its own
method for finding requested byte code files: It can load them from the local disk, fetch them across
the Net using any protocol, or it can just create the byte code on the spot. This flexibility is not a
security problem as long as the class loader is trusted by the party who wrote the code that is being
loaded. Second, class loaders define the namespaces seen by different classes and how those
namespaces relate to each other. Namespaces are a subtle and security-critical issue that we'll have
a lot more to say about later. Problems with namespace management have led to a number of
serious security holes.

It probably would have been better if Java's design had initially separated the two functions of class
loaders and provided lots of flexibility in finding byte code but not much flexibility in defining
namespaces. In a sense, this is what has come about as successive versions of Java have had
increasingly restrictive rules about how namespaces may be managed. Java's class loader
architecture was originally meant to be extensible, in the sense that new class loaders could be
added to a running system. It became clear early on, however, that malicious class loaders could
break Java's type system, and hence breach security. As a result, current Java implementations
prohibit untrusted code from making class loaders. This restriction may be relaxed in the future,
since there is some possibility that the Java 2 class loader specification is at last safe in the presence
of untrusted class loaders.

Varieties of Class Loaders

There are two basic varieties of class loaders: Primordial Class Loaders and Class Loader objects.
There is only one Primordial Class Loader, which is an essential part of each Java VM. It cannot be
overridden. The Primordial Class Loader is involved in bootstrapping the Java environment. Since
most VMs are written in C, it follows that the Primordial Class Loader is typically written in C.
This special class loader loads trusted classes, usually from the local disk. Figure 2.5 shows the
inheritance hierarchy of Class Loaders available in Java 2.

Figure 2.5 Class Loaders provide Java's dynamic loading

capability, which allows classes to arrive and depart from the
runtime environment.
 Java 2 implements a hierarchy of Class Loaders. This figure, after
Gong [Gong, 1998], shows the inheritance hierarchy of Class
Loaders.

The Primordial Class Loader

The Primordial Class Loader uses the native operating system's file access capabilities to open and
read Java class files from the disk into byte arrays.

This provides Java with the ability to bootstrap itself and provide essential functions. The Java API
class files (stored by default in the classes.zip file) are usually the first files loaded by the VM. The
Primordial Class Loader also typically loads any classes a user has located in the CLASSPATH.
Classes loaded by the Primordial Class Loader are not subjected to the Verifier prior to execution.

Sometimes the Primordial Class Loader is referred to as the "internal" class loader or the "default"
class loader. Just to make things overly complicated, some people refer to classes loaded by the
Primordial Class Loader as having no class loader at all.

Class Loader Objects

The second basic variety of class loader is made up of Class Loader objects. Class Loader objects
load classes that are not needed to bootstrap the VM into a running Java environment. The VM
treats classes loaded through Class Loader objects as untrusted by default. Class Loaders are
objects just like any other Java object-they are written in Java, compiled into byte code, and loaded
by the VM (with the help of some other class loader). These Class Loaders give Java its dynamic
loading capabilities.

There are three distinct types of Class Loader objects defined by the JDK itself: Applet Class
Loaders, RMI Class Loaders, and Secure Class Loaders. From the standpoint of a Java user or a
system administrator, Applet Class Loaders are the most important variety. Java developers who
are interested in rolling their own Class Loaders will likely subclass or otherwise use the RMI Class
Loader and Secure Class Loader classes.

Applet Class Loaders are responsible for loading classes into a browser and are defined by the
vendor of each Java-enabled browser. Vendors generally implement similar Applet Class Loaders,
but they do not have to. Sometimes seemingly subtle differences can have important security
ramifications. For example, Netscape now tracks a class not by its name, but by a pointer to actual
code, making attacks that leverage Class Loading complications harder to carry out.

Applet Class Loaders help to prevent external code from spoofing important pieces of the Java API.
They do this by attempting to load a class using the Primordial Class Loader before fetching a class
across the network. If the class is not found by the Primordial Class Loader, the Applet Class
Loader typically loads it via HTTP using methods of the URL class. Code is fetched from the
CODEBASE specified in the <APPLET> tag. If a fetch across the Web fails, a ClassNotFound
exception is thrown.
It should be clear why external code must be prevented from spoofing the trusted classes of the
Java API. Consider that the essential parts of the Java security model (including the Applet Class
Loader class itself) are simply Java classes. If an untrusted class from afar were able to set up shop
as a replacement for a trusted class, the entire security model would be toast!

The RMI Class Loader and Secure Class Loader classes were introduced with JDK 1.1 and Java 2,
respectively. RMI Class Loaders are very similar to Applet Class Loaders in that they load classes
from a remote machine. They also give the Primordial Class Loader a chance to load a class before
fetching it across the Net. The main difference is that RMI Class Loaders can only load classes
from the URL specified by Java's rmi.server.codebase property. Similar in nature to RMI Class
Loaders, Secure Class Loaders allow classes to be loaded only from those directories specified in
Java's java.app.class.path property. Secure Class Loaders can only be used by classes found in the
java.security package and are extensively used by the Java 2 access control mechanisms.

Roll-Your-Own Class Loaders

Developers are often called upon to write their own class loaders. This is an inherently dangerous
undertaking since class loading is an essential part of the Java security model. Homegrown class
loaders can cause no end of security trouble. The right approach to take in writing a class loader is
to avoid changing the structure of namespaces, and to change only the methods that find the byte
code for a not-yet-loaded class. This will allow you to fetch classes in new ways, such as through a
firewall or proxy, or from a special local code library, without taking the risk inherent in namespace
management. You can do this by overriding only the loadClass methods.

Namespaces

In general, a running Java environment can have many Class Loaders active, each defining its own
namespace. Namespaces allow Java classes to see different views of the world depending on where
they originate (see Figure 2.6). Simply put, a namespace is a set of unique names of classes loaded
by a particular Class Loader and a binding of each name to a specific class object. Though some
people say that namespaces are disjoint and do not overlap, this is not true in general. There is
nothing to stop namespaces from overlapping.

Figure 2.6 Class Loaders have two distinct jobs (which

we believe would have been better off separated): (1)
fetching and instantiating byte code as classes, and (2)
managing name spaces.

This figure shows how Class Loaders typically divide

classes into distinct name spaces according to origin. It is
especially important to keep local classes distinct from
external classes. This figure implies that name spaces do
 not overlap, which is not entirely accurate.

Most VM implementations have used different class loaders to load code from different origins.
This allowed these implementations to assign a single security policy to all code loaded by the
same class loader, and to make security decisions based on which class loader loaded the class that
is asking to perform a dangerous operation. With the addition of code signing in JDK 1.1, there are
now two characteristics for categorization of code: origin (usually represented as a URL) and signer
(the identity associated with the private key used to sign the file). Only the Class Loader that loaded
a piece of code knows for sure where the code was loaded from.

Applet Class Loaders, which are typically supplied by the browser vendor, load all applets and the
classes they reference, usually getting the classes from HTTP servers. When an applet loads across
the network, its Applet Class Loader receives the binary data and instantiates it as a new class.
Under normal operation, applets are forbidden to install a new Class Loader, so Applet Class
Loaders are the only game in town.

A trusted Java application (such as the Java interpreter built in to Netscape Navigator or Internet
Explorer) can, however, define its own class loaders. Sun Microsystems provides three template
class loader modules as part of the JDK (discussed earlier). If an untrusted applet could somehow
install a Class Loader, the applet would be free to define its own namespace. Prior to Java 2, this
would allow an attack applet to breach security (see Chapter 5).

If you are writing an application or built-in extension that defines its own Class Loader, you should
be very careful to follow the rules; otherwise, your Class Loader will almost certainly introduce a
security hole. It is unfortunate that in order to get the ability to use your own code-finding
mechanism, you must also take on responsibility for managing namespaces. One criticism often
raised against the Java security model is that because of the presence of objects like application-
definable class loaders, the security model is too distributed and lacks central control. Applet Class
Loaders install each applet in a separate namespace. This means that each applet sees its own
classes and all of the classes in the standard Java library API, but it doesn't see classes belonging to
other applets. Hiding applets from each other in this way has two advantages: It allows multiple
applets to define classes with the same name without ill effect, so applet writers don't have to worry
about name collisions. It also makes it harder, though not impossible, for applets to team up.

As an example, consider a class called laptop with no explicit package name (that is, laptop belongs
to the default package). Imagine that the laptop class is loaded by an Applet Class Loader
from www.rstcorp.com as you surf the Java Security Web Site. Then you surf over to java.sun.com
and load a different class named laptop (also in the default package). What we have here is two
different classes with the same name. How can the VM distinguish between them? The tagging of
classes according to which Class Loader loaded them provides the answer. Applets from different
CodeBases are loaded by different instances of the browser's Applet Class Loader class. (By the
way, distinct namespaces will be created even if the two sites use explicit package names that
happen to be the same.) Although the same class is involved in loading the two different classes
(i.e., the Applet Class Loader), two different instances of the Applet Class Loader class are
involved-one for each CodeBase.
Recall that the default object protection and encapsulation scheme covered earlier in this chapter
allows classes that are members of a package to access all other classes in the same package. That
means it is important for the VM to keep package membership straight. As a result, Class Loaders
have to keep track of packages as well as classes.

When a class is imported from the network, the Applet Class Loader places it into a namespace
labeled with information about its origin. Whenever one class tries to reference another, the Applet
Class Loader follows a particular order of search. The first place it looks for a class is in the set of
classes loaded by the Primordial Class Loader. If the Primordial Class Loader doesn't have a class
with the indicated name, the Applet Class Loader widens the search to include the namespace of
the class making the reference.

Because the Applet Class Loader searches for built-in classes first, it prevents imported classes
from pretending to be built-in classes (something known as "class name spoofing"). This policy
prevents such things as applets redefining file I/O classes to gain unrestricted access to the file
system. Clearly, the point is to protect fundamental primitives from outside corruption.

Since all applets from a particular source are put in the same namespace, they can reference each
other's methods. A source is defined as a particular directory on a particular Web server.

According to the Java specification, every Class Loader must keep an inventory of all the classes it
has previously loaded. When a class that has already been loaded is requested again, the class
loader must return the already loaded class.

Loading a Class

Class loading proceeds according to the following general algorithm:

• Determine whether the class has been loaded before. If so, return the previously loaded class.
• Consult the Primordial Class Loader to attempt to load the class from the CLASSPATH.
This prevents external classes from spoofing trusted Java classes.
• See whether the Class Loader is allowed to create the class being loaded. The Security
Manager makes this decision. If not, throw a security exception.
• Read the class file into an array of bytes. The way this happens differs according to
particular class loaders. Some class loaders may load classes from a local database. Others
may load classes across the network.
• Construct a Class object and its methods from the class file.
• Resolve classes immediately referenced by the class before it is used. These classes include
classes used by static initializers of the class and any classes that the class extends.
• Check the class file with the Verifier.

Summary
Each Java class begins as source code. This is then compiled into byte code and distributed to
machines anywhere on the Net. A Java-enabled browser automatically downloads a class when it
encounters the <APPLET> tag in an HTML document. The Verifier examines the byte code of a
class file to ensure that it follows Java's strict safety rules. The Java VM interprets byte code
declared safe by the Verifier. The Java specification allows classes to be unloaded when they are no
longer needed, but few current Java implementations unload classes.

Java's ability to dynamically load classes into a running Java environment is fraught with security
risks. The class-loading mechanisms mitigate these risks by providing separate namespaces set up
according to where mobile code originates. This capability ensures that essential Java classes
cannot be spoofed (replaced) by external, untrusted code. The Applet Class Loader in particular is a
key piece of the Java security model.

CHAPTER SECTION:8

Section 8 -- The Security Manager

The third part of the base Java security model is the Security Manager. This part of the security
model restricts the ways an applet uses visible interfaces (Java API calls). The Security Manager
implements a good portion of the entire security model and is the part of the security model most
often encountered (in terms of a SecurityException) by Java applet developers.

The job of the Security Manager is to keep track of who is allowed to do which dangerous
operations. A standard Security Manager will disallow most operations when they are requested by
untrusted code, and will allow trusted code to do whatever it wants. The old distinction between
applets and applications in JDK 1.0.2 used to directly affect which code the Security Manager
managed. Applets, being completely untrusted, were subject to the strict rules of the Security
Manager, while applications, being completely trusted, were not. This often led to confusion in the
past, especially among managers who believed that the way the Security Manager was set up
somehow made trusted Java applications more secure. The fact is, running trusted Java applications
is just as risky as running any other executable code written in any language. If the trusted code is
malicious or buggy, you could be in big trouble.

Although the browser vendors have designed very similar Security Managers for the most popular
Java-enabled browsers, there is no strict edict forcing them to do this. The fact that Security
Managers applied to untrusted applets generally enforce the same policies makes things easier to
understand and leads to a more uniform experience for both Java users and Java applet developers.
But Security Managers don't have to follow an all-or-nothing approach to controlling dangerous
resources. They could, for example, be written to give specialized access to particular classes. The
fact is, Security Managers can be as simple or as complicated as their authors decide to make them.
To the extent that applet security is a major concern to you (and it must be, or you would not be
reading this book), your choice of a browser should also be of great concern.
This discussion focuses on two central characteristics of Security Managers: how they work, and
how they are set up to restrict the activities of untrusted applets in most browsers. Before the
introduction of code signing with JDK 1.1, the security policy for untrusted applets was easy to
understand (although its enforcement was complicated), and the goal of a Security Manager was
thus straightforward. Now that applets come in myriad trust levels, talk of a single Security
Manager makes less sense. To be sure, the Security Manager's default rules do serve as the default
under there somewhere, but like the rest of the sandbox, they are only a default.

How the Security Manager Works

The Security Manager is a single Java object that performs runtime checks on dangerous methods.
Code in the Java library consults the Security Manager whenever a potentially dangerous operation
is attempted. The Security Manager can veto the operation by generating a SecurityException.
Decisions made by the Security Manager take into account the origin of the requesting class.
Obviously, built-in classes are usually given more privilege than classes loaded across the Net. The
Security Manager makes the final decision as to whether a particular operation is permitted or
rejected. See Figure 2.7.

Figure 2.7 The Security Manager keeps tabs on

potentially dangerous calls to the native operating
system (underlying the VM).

In this way, Java can encapsulate resources that could

otherwise be abused by mobile code.

For applet developers, the Security Manager is a behind-the-scenes player that need not be directly
invoked. (In any case, no self-respecting hostile applet would deliberately invoke a security check
on itself!) The Java API provides all calls necessary to interface to the operating system, thus
making isolation of all required security checks possible within the API. When a dangerous call is
made to the Java library, the library queries the Security Manager. These queries use a set of
methods that check access. For example, the Security Manager in most browsers contains the
methods checkWrite() and checkConnect(), which check whether to allow file writing and the
creation of network connections, respectively. If the check passes muster, the call quietly returns;
otherwise, a security exception is thrown.

The Java library's use of the Security Manager works as follows:

• A Java program makes a call to a potentially dangerous operation in the Java API.
 • The Java API code asks the Security Manager whether the operation should be allowed.
• The Security Manager throws a SecurityException back to the Java API if the operation is
denied. This exception propagates back to the Java program.
• If the operation is permitted, the Security Manager call returns without throwing an
exception, and the Java API performs the requested dangerous operation and returns
normally.

Each VM can have only one Security Manager installed at a time, and once a Security Manager has
been installed it cannot be uninstalled (except by restarting the VM). Java-enabled applications
such as Web browsers install a Security Manager as part of their initialization, thus locking in the
Security Manager before any potentially untrusted code has a chance to run.

Usually a security exception propagates up through all the methods of the thread that made the
disallowed call. When the topmost method finally gets the exception, the thread exits. A thread that
exits this way prints the exception and the stack trace of all the methods that led to it. These are the
sorts of messages often cut and pasted in comp.lang.java.security by Java developer newbies
wanting help with security problems.

One important thing to realize about security exceptions is that it is perfectly possible for a hostile
applet to catch any security exceptions it generates in a try/finally block. So don't count on security
exceptions to tip you off to hostile applet activities. Purported Java security products that count
security exceptions can easily be thwarted by this strategy. A hostile applet can thus probe your
Security Manager with impunity. (Besides, a cracker who has done his homework will know in
advance what your Security Manager will allow and disallow, so he will never bother trying to
make a call that causes a security exception.)

The Security Manager is completely customizable (through subclassing), although applets are not
allowed to install Security Managers. A default Security Manager is provided (like the Class
Loader) as a template from Sun Microsystems. Each Java-enabled application fills in the template
(by subclassing the template class) to meet its own security requirements. The Java runtime library
is written so that all requests to perform dangerous operations are referred to the Security Manager.
Access checks are used for thread access, OS access, network access, and Java component access.

What the Security Manager Is Set Up to Do for Untrusted Applets

The Security Manager has the following duties:

• Prevent installation of new class loaders. The job of class loaders is to keep the namespaces
properly organized. Because security checks are requested by classes in the Java library,
applets must be prevented from spoofing the library classes.
• Protect threads and thread groups from each other. (Unfortunately, JDK 1.0 implementations
of this piece of policy do not function properly. Some malicious applets, discussed in
Chapter 4, have been written to take advantage of this. Better thread protection is provided in
JDK 1.1 and above.)
• Control the execution of other application programs.
 • Control the ability to shut down the VM.
• Control access to other application processes.
• Control access to system resources such as print queues, clipboards, event queues, system
properties, and windows.
• Control file system operations such as read, write, and delete. Access to local files is strictly
controlled.
• Control network socket operations such as connect and accept.
• Control access to Java packages (or groups of classes), including access to security
enforcement classes.

Sun's Security Manager can be customized. The appletviewer, part of the JDK, reads a
configuration file with several user-determined security options. These configuration files declare
low-level details, such as "myfile.txt should be writable by applets." Such configuration files
appear again for use with JDK 1.1 and Java 2, allowing a user to define a security policy that
interacts with the code signing system.

The job of the Security Manager has been deeply affected by many of the new code-signing and
access-control features now found in the Java security architecture (see Chapter 3). Using
encryption-based authentication methods, the Security Manager in concert with other mechanisms
can set up much more sophisticated rules for trusted, partially trusted, and untrusted applets.

CHAPTER SECTION:9

Section 9 -- Different Classes of Security

In the early days of Java, life was simple, security policy was black and white, and external code
was summarily untrusted. Since then, life has become more complex, security policy is now made
to order, and code runs the gamut from trusted to untrusted (encompassing every state in between).
Figure 1.6 in Chapter 1 illustrates the difference in trust models. It is easiest to get a grasp on the
notion of trust assigned to Java classes by harkening back to ancient Java history circa 1996.

JDK 1.0

As Figure 2.8 shows, in JDK 1.0 there are only three possible paths that byte code can take through
the Java security model. The path taken is determined by the origin of the byte code. Built-in byte
code from the JDK 1.0 distribution (off the local disk) is allowed to bypass the verification stage.
This means that built-in classes are assumed to be both correct and well behaved. All other JDK 1.0
byte code classes must pass through the strict security checks.
 Figure 2.8 There are three possible paths that Java byte code may follow
through the JDK 1.0.2/JDK 1.1 security models.

The path chosen depends on where the byte code originates and (in the case of
JDK 1.1) what signatures the code carries. External byte code (loaded across the
network) that is not signed by a trusted party (1) must be Verified and is subject to
the Class Loader and the Security Manager. Locally developed byte code (2) is
subject to the same checks (unless it is placed on the CLASSPATH). Byte code
from the JDK distribution (including other packages placed on the CLASSPATH)
and any class that is signed by a trusted party (3) does not pass through the
Verifier and may be subject to further optional security checks.

Built-In Classes: The Privileged Few

The JDK includes a class library that makes Java as powerful as it is. Since this code is part of Java
itself, it is considered trustworthy. The fact that built-in Java classes bypass security measures has
many implications. The system makes sense when you consider that this code is part of the Virtual
Machine itself. If the VM is loaded before the Verifier, there is no choice but to consider the built-
in Java classes trustworthy.

It is not just JDK classes that can bypass security. In JDK 1.0, any class stored on the local file
system and made part of the local approved set of classes will be considered a built-in class. Such
classes are, however, only subject to automatic loading if they are placed in one of the
subdirectories in the CLASSPATH. Making a change to the CLASSPATH, or placing a new class
in one of these subdirectories is tantamount to making a fundamental change in your security
policy. A good example of classes given built-in status is the set of class files included with
Netscape Navigator: classes.zip.

Under JDK 1.0, it is essential that you never install classes of unknown origin as built-in classes by
putting them in the CLASSPATH. Since the security checks are bypassed for this kind of byte
code, granting such classes built-in status is very dangerous. Install only vendor-supplied classes as
built-in classes.

The file system loader (aka the Primordial Class Loader) shown in Figure 2.8 sets up the
namespace for built-in classes. This namespace is special. The local namespace is exclusively
reserved for built-in classes. This helps protect built-in classes (including essential classes like the
Security Manager) from being spoofed by outside classes.
Built-in classes may or may not be subjected to the Security Manager, depending on the policy of
the site. Vendor-supplied classes often require unhindered access to system resources. Classes like
the ClassLoader must be trusted in order to bootstrap the system.

Non-Built-In Classes: The Unwashed Masses

In JDK 1.0, all classes not considered built-in are subject to more strict security checks. Paths (1)
and (2) of Figure 2.8 both apply to non-built-in classes. Classes in path (1) include all applets
loaded from the network. Classes in path (2) include all applets loaded locally, but not specified in
the CLASSPATH. It is not possible to stress heavily enough how important it is to consider
carefully which classes you grant built-in status. If you install a Java class in your CLASSPATH it
will no longer be subject to security checks. Only completely trusted code should be given this
privilege.

In summary, under JDK 1.0, built-in classes and classes loaded from the CLASSPATH are trusted
classes. Classes loaded from a URL (either a file: type or an http: type) are untrusted classes.

JDK 1.1

Under JDK 1.1 the same system applies as was the case in JDK 1.0. However, a class loaded from
the network can become trusted if it is digitally signed by a party whom the user has decided to
trust. The idea is to allow code signed by a trusted party to attain the same level of privilege as is
usually afforded to built-in code. This is a decision not to be taken lightly. Security ramifications
are just as critical as those raised when adding classes to the CLASSPATH. Note that the way JDK
1.1 is used in practice, the resulting trust model is still black and white. Code is still either
completely trusted, or it's not trusted at all.

Java 2

With Java 2, things get even more complicated. Built-in classes are still completely trusted, but
external, digitally signed classes can become partially trusted at the whim of the user. By adding
partial trust and access control to the VM, Java 2 opens the door for complex, fine-grained security
policies that grant privileges according to identity. See Figure 2.9.

Figure 2.9 In Java 2, all code is distinctly identified by

where it comes from and what signatures it carries.

Byte code may make calls to potentially dangerous

 functionality. When such calls are made, the
AccessController (new to Java 2) consults policy and uses
stack inspection to decide whether to allow or disallow a call.
The distinction between applets and applications no longer
applies.

Chapter 3 is devoted to understanding the subtleties of this new approach to Java security.

CHAPTER SECTION:10

Section 10 -- Type Safety

The Java language is designed to enforce type safety. This means that programs are prevented from
accessing memory in inappropriate ways. More specifically, every piece of memory is part of some
Java object. Each object has some class. For example, a calendar-management applet might use
classes like Date, Appointment, Alarm, and GroupCalendar. Each class defines both a set of objects
and operations to be performed on the objects of that class. In our calendar management example,
the Alarm class might define a turnOn operation, but the Date class would neither need nor allow
turnOn. Type safety means that a program cannot perform an operation on an object unless that
operation is valid for that object.

Why Type Safety Matters

Type safety is the most essential element of Java's security. To understand why, consider the
following slightly contrived example. A calendar-management applet defines a class called Alarm.
This class is represented in memory as shown in Figure 2.10. Alarm defines an operation turnOn,
which sets the first field to true. The Java runtime library defines another class called Applet,
whose memory layout is also shown in Figure 2.10. Note that the first field of Applet is
fileAccessAllowed, which determines whether the applet is allowed access to files on the hard disk.

Figure 2.10 Type safety provides an important foundation for the

Java security model.

In this figure, two classes, Alarm and Applet, each include a number of
fields. Setting the first field in these classes to "true" is not equivalent.
Type safety checks ensure that any object a method may try to
manipulate is of the proper type.
Suppose a program tried to apply the turnOn operation to an Applet object. If the operation were
allowed to go ahead, it would do what turnOn was supposed to do, and set the first field of the
object to true. Since the object was really in the Applet class, setting the first field to true allows the
applet to access the hard disk. The applet would then be allowed (incorrectly) to delete files.

This example shows what can go wrong if type safety is violated. In our experience, every type
safety violation has created an opportunity for an untrusted applet to break out of Java's security
restrictions. Given the importance of type safety, the next section explains Java's strategy for
ensuring type safety.

How Java Enforces Type Safety

Every Java object is stored in some region of the computer's memory. Java labels every object by
putting a class tag next to the object. One simple way to enforce type safety is to check the class tag
of the object before every operation on the object. This will help make sure the object's class allows
the operation. This approach is called dynamic type checking.

Though dynamic type checking works, it is inefficient. The more time a system spends checking
class tags, the more slowly programs run. To improve performance, Java uses static type checking
whenever it can. Java looks at the program before it is run and carefully tries to determine which
way the tag checking operations will come out. This is more complicated, but more efficient than
dynamic type checking. If Java can figure out that a particular tag checking operation will always
succeed, then there is no reason to do it more than once. The check can safely be removed,
speeding up the program. Similarly, if Java can figure out that a particular tag checking operation
will always fail, then it can generate an error before the program is even loaded.

The designers of Java carefully crafted the Java language and byte code formats to facilitate static
type checking. The byte code Verifier is a very effective static type checker, eliminating almost all
of the tag checking operations from Java programs. The result is a type safe program that runs quite
efficiently.

Static type checking has other advantages, too. For example, static type checking can be done at
compile time, thus informing the software developer of any type errors before the code is shipped.

Type Confusion

There is only one problem with Java's static type checking strategy: It's complicated. Though Java's
designers obviously got the overall strategy right, there are a great many details that have to be
perfect for type safety to be enforced. An error in any of these details would be a tiny but crucial
hole in Java's type safety enforcement dike.

A clever cracker who finds such a hole can launch a type confusion attack. Such an attacker could
write a Java applet designed to trigger a tiny type enforcement error. The attacker could then create
a situation like our Alarm/Applet example in which the program has one kind of object but Java
thinks that object has some other kind. As in the example, this seemingly harmless confusion can
be exploited to breach Java's security. If you recall that two of the three parts of the base Java
security sandbox are themselves Java classes, it becomes immediately apparent what sorts of havoc
type confusion can cause. Several real-life type confusion attacks are discussed in Chapter 5.

Type Safety and Encapsulation

Type safety is the cornerstone of Java security. There is much more to the rest of the edifice, of
course, but without type safety the entire building would be unsound.

Type safety guarantees that programs will not do terrible and dangerous things such as treating
pointers as integers (or vice versa) or falling off the end of an array. These are the sorts of things
that make it very easy to write insecure code in C and C++.

The typing constraints in Java exist to prevent arbitrary access to memory. This in turn makes it
possible for a software module to encapsulate its state. This encapsulation takes the form of
allowing a software module to declare that some of its methods and variables may not be accessed
by anything outside the code itself. The more control is placed on access points (and the fewer
access points there are), the better a module can control access to its state.

It is this idea that permeates the design of the Security Manager. The VM controls access to
potentially dangerous operating system calls by wrapping the calls in an API that invokes a security
check before making the call. Only the VM can make a direct system call. All other code must call
into the VM through explicit entry points that implement security checks.

As we will see in the next chapter, encapsulation turns out to be essential to the design of the Java 2
access control system as well.

CHAPTER SECTION:11

Section 11 -- Browser-Specific Security Rules

Security Manager, are meant to be defined by application authors (including browser vendors)
through subclassing. The rules that Web browsers enforce make up the security policy defined by a
particular vendor. Ultimately, Netscape could decide to implement different rules than Microsoft.

Of course, every browser's security implementation depends entirely on the rest of the security
model being properly defined. Critical pieces of the Java environment directly affecting security
include the Java VM, and the built-in libraries. If any of these pieces have errors, the entire security
system will break, regardless of which vendor does the other parts.
 Netscape Navigator and Microsoft Internet Explorer

All Netscape Navigator versions subsequent to 2.0 are Java enabled. All Microsoft Internet
Explorer versions subsequent to 3.0 also include Java. It is, however, very easy to disable Java in
both kinds of browsers as long as you can find the right dialog box (see Chapter 4). There is a
toggle switch for the entire Java environment. In both Netscape Navigator and Internet Explorer,
Java is enabled by default.

The two browsers' security policies are, at the present time, very similar. Both are somewhat strict.
The following rules apply to all untrusted applets running under Netscape Navigator and Internet
Explorer:

• Applets cannot read or write files locally.

• Applets cannot open a client-side network connection to any machine other than the applet's
origin host. Applets after JDK 1.1 can open a server socket as long as the port number is
greater than the privileged port number on the machine (usually 1024).
• Applets can read only nine system properties. This allows an applet to access information
such as the vendor who created the Java VM, the VM version number, the file separation
character (either \ or /), the character used to separate lines, and so on. Applets are not
permitted to read any other system properties.
• If an applet is loaded using the file: URL, and it does not reside in a directory in
CLASSPATH, it is loaded by an Applet Class Loader.

There is no reason that all future browser vendors will choose to implement similar security
policies. That two major vendors now do so is probably an artifact of Java's short history. Once
browsers begin to implement different policies, security issues will become more complex.

We can see a split among vendors happening already with the 4.x versions of Netscape Navigator
and Internet Explorer. Both products offer complex security models based on digital signatures and
partial trust. Although the models are quite similar to each other and to the model defined by Java
2, there are many detailed differences that annoy developers and users.

One side effect of the common ground between different vendors' Java security implementations
was that early on in Java's history, security holes often cut across all Java implementations. That is,
the same problem would be exploitable in all Java VMs, regardless of the browser. These days, it is
more common for errors to be relegated to one browser or another. We have more to say about
vendors, implementations, and security holes inChapter 5.

CHAPTER SECTION:12

Section 12 -- The Fundamental Tradeoff

In Chapter 1, we pointed out that there is no such thing as 100-percent security. Where security is
concerned, there is a fundamental tradeoff between power (functionality) and security. Java
attempts to be both powerful and secure. Java is trying to manage complex security issues
proactively. Despite such efforts, some flaws in the model still need to be addressed.

Functionality and security will always exist in an inverse relationship. Currently, Net users choose
functionality over security. Java designers are attempting to increase security without paying too
high a price in functionality.

CHAPTER SECTION:13

Section 13 -- Is There Really a Java Security Policy?

The base Java Security sandbox is comprised of three major components: the byte code Verifier,
the Class Loader, and the Security Manager. Each of these components must work properly in
order for Java to perform in a secure fashion. The Security Manager depends on Class Loaders to
correctly label code as trusted or untrusted. Class Loaders also shield the Security Manager from
spoofing attacks by protecting local trusted classes making up the Java API. On the other hand, the
class loader system is protected by the Security Manager, which ensures that an applet cannot
create and use its own Class Loader. The Verifier protects both the Class Loaders and the Security
Manager against language-based attacks meant to break the VM. All in all, the three parts
intertwine to create a default sandbox. However, the three parts are not created or specified by a
standards committee. Java applications, including Java-enabled Web browsers, are allowed to
customize two of the fundamental portions of the security model to suit their needs (the Class
Loader and the Security Manager).

The security model is much more distributed than many computer security experts would like
[Badger and Kohli, 1995]. In the end, a great deal of faith is placed in the ability of VM
implementations to ensure that untrusted code remains properly contained. Bugs in the system will
compromise the entire security model.

In 1996, we complained that there was no formal, high-level security model in Java. Instead, the
security policy is derived from a collection of low-level detail checking. This is difficult because
without a formal model it is impossible to say what secure means. With no standardized model,
each vendor is free to define the term secure. In addition, no particular implementation can be
verified. A little progress towards a more formal description of the security model was made when
Sun commissioned a report entitled Security Reference Model for JDK 1.0.2 [Erdos, et al, 1996].
This sort of work is what users of security-critical consumerware should demand. Unfortunately,
the SRM is now seriously out of date. Once again, Internet-time-compressed development
schedules have outstripped the need for rigorous security design and analysis. This is a common
trend in consumer software, and one that is destined to flame out under the rigorous security
demands of e-commerce.
Programming language researchers have also done some work trying to prove the soundness of the
Java language and the VM definition [Drossopoulou and Eisenbach, 1998; Stata and Abadi, 1998].
Although this work is still in preliminary stages, some interesting and suggestive results are
available. The bottom line is that the definition of Java will probably turn out to be sound, once
many more details have been filled in.

The Java runtime system is large (upwards of 28,000 lines of code, not including the VM). This
raises important security assurance questions. Generally speaking, programs as large and complex
as that are extremely hard to verify. It is common knowledge that buggy software causes many
security vulnerabilities [Garfinkel and Spafford, 1996]. There is no centralized authority ensuring
that Java's security code is bug free.

The Java security system has seen the benefit of external peer review (some solicited and some
not). JavaSoft has put together a Security Advisory Board (including one of the authors) and now
includes prominent security researchers among its staff. Outsiders have done their best to keep
security claims honest, and a number of security researchers (including the authors of this book) are
spending a fair amount of effort still trying to find its weaknesses. Later in the book, we discuss
some of the problems researchers have found, and what Java vendors are doing to address them.
Before we dig into that topic, we introduce the new security mechanisms found in Java 2 and
discuss why the Java security model is a completely new beast.

Beyond the Sandbox

Signed Code and Java 2
Java has outgrown the original restrictive sandbox. The anticipated future of mobile code security,
a complex mix of sandboxing and code signing, is now upon us with Java 2. In essence, the three
parts of the sandbox explained in the previous chapter implement a language-based security
enforcer. This enforcement model has been hybridized and expanded to include fine-grained
notions of trust and permission built on digital signatures. That means major changes to Java
security. This chapter centers on those changes.

Chapter 1, "Mobile Code and Security: Why Java Security Is Important," briefly introduced the
notion of code signing and mobile code policy through the discussion of ActiveX. The ActiveX
trust model is suited only to run completely trusted code. At the core of that kind of trust model is a
black-and-white decision either to trust the code or not. Such a decision can be influenced by
determining who vouches for the code. Digital signatures are used for the vouching.

Java's approach to trust is also based on digital signatures. However, instead of allowing only
black-and-white trust decisions à la ActiveX, Java 2 allows fine-grained access control decisions to
be made. With the introduction of code signing in JDK 1.1, Java's sandbox model underwent a state
transition from a required model applied equally to all Java applets to a malleable system that could
be expanded and personalized on an applet-by-applet basis. Java 2 further complicates the picture
with the addition of access control.

When combined with access control, code signing allows applets to step outside the security
sandbox gradually. In fact, the entire meaning of sandbox becomes a bit vague. As an example of
how Java code signing might work, an applet designed for use in an Intranet setting could be
allowed to read and write to a particular company database as long as it was signed by the system
administrator. Such a relaxation of the security model is important for developers who have
complained about Java's restrictive sandbox. Writing code that works within the tight restrictions of
the sandbox is a pain, and the original sandbox is very restrictive.

The addition of code signing to Java complicates things. As it now stands, the Java sandbox has
been reduced to a default. The whole game has changed. Tracing the history of this change as we
do in this chapter can lend some important perspective.

Before we dig into the complex issues of code signing and trust models, it does us good to review
what it is we're trying to achieve in the first place. After all, the point of all this highfalutin'
architecture is not to make the world's most complicated system. The real objective is securing
mobile code.

After we remind ourselves of the main goal of the new security model, we are ready to trace its
evolution. We will begin by explaining the enhancements added to Java with the release of JDK
1.1, and go on to discuss the Java 2 model in detail.

Chapter Three Sections

1. What's the Main Goal?
2. Security Enhancements in JDK 1.1
3. Signed Code
4. Trust
5. An Introduction to Java 2 Security
6. Access Control and Stack Inspection
7. New Security Mechanisms in Sun's Java 2
8. Outside the Sandbox

Beyond the Sandbox: Signed Code and Java 2

CHAPTER SECTION:1

Section 1 -- What's the Main Goal?

Everyone agrees that code signing makes the Java security model a lot more complicated, not to
mention actually using the new system. Where security is concerned, complexity is bad since it
increases the odds of an error in the system's design or implementation. If we're going to add all of
this complexity, what exactly is it that we are gaining? What's the main goal?

The main goal is to gain better control over the security of mobile code. We can achieve this goal
by winning the battle on three fronts. By adding code signing and expanding beyond a black-and-
white trust model, we hope to gain:

1. The ability to grant privileges when they're needed.

2. The ability to have code operate with the minimum necessary privileges.
3. The ability to closely manage the system's security configuration.

We can judge the JDK 1.1 and Java 2 security models by how well they meet these objectives.

The first objective is simple: We want to give trusted code the privileges it needs to get its job
done. A word-processing applet needs the ability to read and write files, so we want to grant this
privilege if we have enough faith that the applet won't misbehave. In general, users want to be able
to grant any privileges at all to any code they choose, as long as the benefits of doing so outweigh
the risks.

The second objective is to have code that operates with the minimum necessary privileges at all
times. Security experts call this the "principle of least privilege." This is a common-sense idea-why
use a chain saw when a butter knife is sharp enough for the job-but it has profound implications if
we carry it to its logical conclusion. One simple implication is that we want programmers to have a
way to renounce their privileges when they aren't needed and reenable the privileges when they are
needed. The principle of least privilege can be applied in many places throughout the system:

• We want to grant each applet or application the minimum privileges it needs.

• Rather than assigning a given applet's entire collection of privileges to all of its classes, we
want each class to get just what it needs.
• We want a class's privileges to be "turned off" except for brief periods of time.
• We even want to reduce the privileges of some of the built-in system classes.

The third objective is manageability. This is a tricky one. Some might think that the ultimate in
management power is when all possible options are presented to the user. (Power users, developers,
and other gurus tend to think along these lines.) But in reality, users are overwhelmed and irritated
when they are confronted with too many big complicated dialog boxes. Somehow the choices must
be boiled down so that users get just the control they need without being asked any unnecessary
questions.

As we see in the rest of this chapter, the Java security model is still a work in progress. Nobody
knows yet how to achieve all of these goals, or even how they trade off against each other. Today's
models are pretty good, but they are a far cry from perfect.

CHAPTER SECTION:2
 Section 2 -- Security Enhancements in JDK 1.1
JDK 1.1 appeared in the early Spring of 1997 and included a number of improvements and changes
to the base Java security model of JDK 1.0.2. Fortunately, none of the material about the base Java
security model covered in the last chapter (or for that matter, things you learned from the previous
edition of this book) was outdated or replaced; rather, the Java security architecture was changed
through a process of enhancement and addition.

From a security perspective, the most important changes introduced in JDK 1.1 were the addition
of authentication and simple access-control mechanisms that rely on the use of cryptography.
Remember, security is much more than just cryptography. Think of cryptography as a means to an
end-an important part of the puzzle, but only a part. A side effect of the need for cryptographic
functionality inside the model itself was the creation of a crypto API. The crypto API, also
introduced with JDK 1.1, provides a basic toolkit of cryptography algorithms that developers can
use in their programs.

The Crypto API

Today, Java includes a cryptography toolkit that includes both an API and some packages
implementing a portion of the functionality behind the API. Classes in the java.security package,
the package implementing the cryptographic functionality, have a dual purpose. One purpose is to
provide the cryptographic methods that Java's designers used to implement the JDK 1.1 and Java 2
security models. The second purpose is to provide cryptography functionality to Java developers
charged with creating secure applications.

Parts of a crypto API were released with JDK 1.1. The parts included both one-way hash functions
and digital signature capability. DES encryption tools were released only as an extension to North
American users.

Encryption tools and their mathematically related cousins (such as digital signing) change the way
Java use policies are managed. Digital signatures, which are discussed next, make it possible to
authenticate who has vouched for a piece of code, and potentially check it for tampering. If you
decide to trust a particular person, you can set things up so that you automatically trust programs
that person signs. (Note that with the right tools, anyone can sign any piece of code. Whether or not
a piece of code is written, released, or supported by the person who signed it is not something
digital signatures can tell you.) Because the signature is a mechanism for vouching and spreading
trust around, if you trust some experts in the field who agree to approve Java programs based on
their analysis, you can trust any code that they sign as well. Digital signing paves the way for a true
community of trust to develop. We think digital signing is important enough to warrant an entire
section itself. See page 88.

Beyond digital signatures, the crypto API released with JDK 1.1 includes a couple of other
capabilities. One-way hash functions provide a way to fingerprint a program or data so that you can
verify that it has not been changed since being created. Fingerprinting hash functions such as MD5
and SHA make distribution over the Net easier to swallow. If you are certain that a program you
are downloading from the Net is the original program (and not a Trojan Horse masquerading as the
original), you will probably be more likely to use it. Many archives on the Web today make use of
MD5.

Fingerprinting, also called message digesting, works by performing a one-way hash over a series of
bytes. Given a program (which is really just a bunch of ones and zeros), it is possible to compute a
hash that ends up being many times smaller than the original program, but (hopefully) represents
only that program. The main trick is to avoid collisions, whereby the same fingerprint is computed
for different programs, and to come up with a hash function that can't be run in the opposite
direction. MD5 and SHA are systems for computing one-way hashes over a binary file. The crypto
API provides a way for Java programs to include this functionality.

MD5 and SHA are useful when it comes to signing code because the act of signing is actually a
complicated function of a secret crypto key and the data to be signed. The math is hairy enough that
it is a much better idea to compute it using a program's hash instead of the program itself.
Remember, the hash is many times smaller than the program it represents. Figure 3.1 shows the
important role that one-way hash functions play in code signing.

Figure 3.1 How code is digitally signed (A) and digital signatures are
verified (B).

(A) Signing code takes several distinct operations: (1) a one-way hash
calculation is run on a piece of binary code, resulting in a small "thumbprint" of
the code; (2) the hash is signed using the signer's private key; (3) the signed
hash and the original binary code are placed together (potentially along with
other signed and unsigned code) in an archive JAR. Now the JAR can be
shipped around as mobile code.
(B) Validating signed code also takes several steps: (1) a piece of binary code
 and its associated signed hash are removed from the JAR; (2) a new hash is
calculated using the same one-way hash algorithm that the signer used to create
the signed hash; (3) the signature carried by the signed hash is cryptographically
validated with the signer's public key (possibly with reference to certificate
authorities and trust chains); (4) if the signature checks out, the now decrypted
original hash is available for comparison with the new hash. Though all three
Java code signing schemes (Sun, Microsoft, and Netscape) share these two
processes, there are enough differences that the systems do not inter-operate.
See Appendix C for examples of how to sign Java code under each
implementation.

Another function that appeared as part of the crypto API (at least in the package available only in
the United States, and known as the Java Cryptography Extension, or JCE) was DES encryption.
DES, an acronym for Digital Encryption Standard, is a venerable old encryption algorithm that can
in some cases be deciphered (given enough effort and a small enough key). DES is certainly much
more secure than plain text, but does not provide the best available security. In 1998, the EFF
created a special-purpose machine to crack DES messages. The purpose of the machine was to
emphasize just how vulnerable DES really is. (For more on the DES cracker,
see www.eff.org/descracker/.)

Most Unix machines use a variant of DES to encrypt user passwords stored in the /etc/passwd file.
If 56-bit (or smaller) keys are used for DES, then the U.S. government will allow its export and use
outside the United States. There is also a variant called triple DES that effectively has a 112-bit
key, which will be safe against brute-force searching for a long time. The ease of "breaking'' DES is
directly related to the length of its key.

Certificates

Another feature that appeared in JDK 1.1 is certificate technology based on the X.509v3 open
standard. Certificates provide an authentication mechanism by which one site can securely
recognize another. Sites that recognize each other have an opportunity to trust each other as well.
When a secure socket layer (SSL) connection initializes between two machines, they handshake by
exchanging certificates. SSL is discussed in the next section.

A certificate is a piece of identification (credential) much like a driver's license. Information stored
inside a typical certificate file includes the subject's name, the subject's public key, the certificate's
issuer, the issuer's digital signature, an expiration date, and a serial number.

So the question is, who gives out these certificates? Someone (or some thing) called a certification
authority (CA). There are a handful of companies that have set themselves up as CAs in the world.
These include Netscape, GTE, Verisign, and a few others. But why should you trust them? Good
question. (See page 92.)

Secure Communication

Java 2 now includes a package for secure socket layer (SSL) communication. Similar to Netscape's
SSL, the Java SSL provides a secure communications channel by using encryption. SSL works by
providing a mechanism for encrypting packets on the sending end, sending them over an untrusted
channel, and decrypting them at the receiving end. SSL is useful for many business applications,
including the transmission of proprietary information and electronic currency.

Most Web servers and browsers now support SSL, allowing a browser to communicate with a Web
server without anyone else overhearing the conversation. (Well, an outsider might overhear a
conversation, but he or she certainly won't understand it.) Though SSL is commonly used over the
Web, it can actually be used to protect virtually any sort of network transaction.

Most browsers support SSL by providing a "Secure HTTP Connection" service that looks to the
user just like a normal Web connection, but uses SSL underneath. This allows you to reap the
benefits of SSL without having to learn anything except how the browser tells you whether a
connection is secure.

The encryption technology underlying SSL is generally believed to be secure, but there are two
potential problems. First, the U.S. government restricts the export of strong cryptography software.
If your browser version includes dumbed-down exportable cryptography software, your
communications might not be as secure as you think. Second, SSL is good at providing secure
communications, but it is not as good at establishing who you are communicating with. This leads
into all the problems of authentication and key distribution discussed on page 90.

CHAPTER SECTION:3

Section 3 -- Signed Code

The capability to digitally sign Java byte code (at least byte code files placed in a Java archive,
called a JAR file) was introduced with JDK 1.1 and greatly expanded with Java 2. Digital signing
capability is an important part of the new Java security regimen. This is exciting because digital
signing radically alters the amount of trust you can place in a piece of code. A Tutorial on signing
Java code with the current tools from Microsoft, Netscape, and Sun can be found in Appendix C.

One particular kind of cryptography tool allows a chunk of digital information (including, of
course, Java byte code) to be signed by a person or organization. See Figure 3.1. Because a digital
signature has special mathematical properties, it is difficult to forge. Your browser can verify a
signature, allowing you to be fairly certain that a particular person or organization vouches for the
code. That means you can instruct your browser always to accept applets signed by some party that
you trust, or always to reject applets signed by some party that you don't trust. Same thing goes for
a nonbrowser-based VM, which can be instructed (through policy) how to treat application code
signed by particular entities.

It is important to recognize that even if you know exactly which Web pages you are visiting and
who created them, you probably don't know who wrote each applet that appears on the pages you
visit. Applets are shuffled around on the Net like Beanie Babies in a fifth-grade classroom.
Contrary to popular belief, you don't always know where information is coming from on the
Internet. A nasty attack called IP spoofing allows a bad guy to send you network traffic that claims
to come from someplace else. For instance, you might think the traffic is coming from
"whitehouse.gov", when it's really coming from "cracker.org". IP spoofing used to be considered
just a theoretical possibility, but it has actually happened in recent years. The best-known example
is an attack by the infamous cracker Kevin Mitnick on a machine managed by computer security
worker Tsutomu Shimomura. Mitnick's attack led to his eventual capture and conviction
[Shimomura and Markoff, 1996].

An attack known as Web spoofing shows that even in the absence of IP spoofing, it is not always
clear that you are visiting the site you may think you're visiting [Felten, et al., 1997]. An attacker
can lure you into a "false Web" that looks just like the real one, except that the attacker can see
everything you do, including anything you type into a form, and the attacker can modify the traffic
between you and any Web server. All of this is possible even if your browser tells you that you
have a "secure" connection. See Figure 3.2.

Figure 3.2 A Web Spoofing attack can be carried out with extensive use of a
browser's mobile code capability.

The Princeton Team has implemented a demonstration of Web Spoofing that

makes extensive use of JavaScript. Once an attacker has lured the victim to the
attack server (shown as www.attacker.org), the attacker can control the victim's
view of the Web by acting as a rewriting proxy. Clever use of JavaScript makes all
changes invisible to the victim and can even appear to offer encrypted traffic.

Even if you ignore the possibility of spoofing, using the return address of an applet (that is,
knowing the Web site where you got the applet code) still isn't good enough to base a trust decision
on. A digital signature holds much more information. For example, such a signature could tell you
that although the applet is being redistributed by a site you don't trust, it was originally signed by
someone you do trust. Or it can tell you that although the applet was written and distributed by
someone you don't know, your friend has signed the applet, attesting that it is safe. Or perhaps it
can simply tell you which of the thousands of users at aol.com signed the applet.

Digital Signatures

So how do you sign a piece of code? The key to certification and authentication is the use of digital
signatures. The idea is simple: to provide a way for people to sign electronic documents so that
these signatures can be used in the same way we use signatures on paper documents. In order to be
useful, a digital signature should satisfy five properties [Schneier, 1995]. It should be:

1. Verifiable: Anyone should be able to validate a signature.

2. Unforgeable: It should be impossible for anyone but you to attach your signature to a
document.
3. Nonreusable: It should be impossible to "lift'' a signature off one document and attach it to
another.
4. Unalterable: It should be impossible for anyone to change the document after it has been
signed, without making the signature invalid.
5. Nondeniable: It should be impossible for the signer to disavow the signature once it is
created.

Mathematicians and computer scientists have devised several digital signature schemes that appear
to work quite well. The full details are very technical. If you're interested in learning more about
such schemes, Bruce Schneier's excellent book, Applied Cryptography, is a good place to start
[Schneier, 1995].

The digital signatures used for Java code are based on public-key cryptography. If Alice wants to
be able to sign documents, she must first use a special mathematical technique to generate two
large numbers: her own private key, and her public key. As the names suggest, Alice keeps her
private key to herself. Keeping it secret is essential. Her public key, however, is announced to the
world.

Alice's private key is used for signing electronic documents. Her public key is used to verify those
signatures. See Figure 3.1. Anyone who knows the private key (hopefully only Alice!) can run a
special computation involving the document and Alice's private key. The result of this process is a
digitally signed version of the document.

Anyone who knows Alice's public key can verify her signature by running a special computation
involving the signed document and Alice's public key. Since only Alice knows the private key, she
is the only one who can put her signature on documents. Since everyone knows her public key,
anyone can verify that the signature is hers.

Everything sounds great. You tell your browser to trust applets signed by Alice by registering
Alice's public key. Whenever applets claim to come from Alice, the browser can verify that claim
by comparing the registered public key to the signed applet. If the applet is not from Alice, it can be
rejected.

Key Distribution

But how do you know what Alice's public key is?

If you know Alice, she can call you on the phone and tell you her public key. In this case, you will
know the key is valid because you recognize Alice's voice. This doesn't work if you don't know
Alice. How do you know the person on the other end of the phone is Alice? Maybe it's Alice's evil
twin Zelda, trying to pass off Zelda's public key as Alice's so she can forge Alice's signature.

One way around this problem is to ask Alice's twin brother Allan to help. Alice can create a
document containing her public key and have Allan sign that document. If you trust Allan and you
know Allan's public key, then the document tells you reliably what Alice's public key is.

But how do you know Allan's public key? You can't ask Alice and Allan to vouch for each other's
public keys, because Zelda could create a false Alice key and a false Allan key and use them to sign
documents vouching for each other! This leaves us stuck with a chicken-and-egg problem.

The usual solution is to use a certification authority (CA). The CA, Claire in our example, is in the
business of certifying keys. Alice goes to the CA's office with her birth certificate, passport, driver's
license, and DNA sample. Once she has convinced Claire that she really is Alice, she tells Claire
her public key, and Claire signs an electronic document that contains Alice's public key. That
document serves as an electronic credential for Alice.

After Alice has a credential, key distribution is much easier. Alice can plaster copies of her
credential everywhere: on bulletin boards, on her homepage, and at the end of every email message
she sends. Better yet, whenever Alice signs a document, she can attach a copy of her credential to
the signed document. On receiving the document, you can first check the credential by verifying
Claire's signature, and then verify Alice's signature using the public key included with the
document. Zelda can't trick you into accepting a bogus public key for Alice, because she can't forge
Claire's signature. Figure 3.3 shows the process by which a signature on a piece of signed code can
be validated.

Figure 3.3 Validating a signature on signed code.

In this example, a piece of code is signed by the private key of thing1.

The corresponding public key, available on thing1's certificate can be
used to validate the signature carried by the code. For added security
and to make key management more reasonable, browsers typically
validate the CA signature carried on the certificate.

The beauty of this approach is that if everyone can visit Claire and get a credential, then no one has
to remember any keys except for his or her own private key (to sign documents), and Claire's
public key (to verify credentials). There are still two problems, though. Everyone must trust Claire.
As the authority, she can impersonate anyone. And you still need a reliable way to get Claire's
public key. It doesn't help to have Claire get a credential from Claire's mom, Elena. You would
have no more reliable way of knowing who Elena is.

There is no technological solution to this. Claire's key will probably be hard-wired into your
browser software, or entered by support staff at install time. As long as you get a valid copy of the
browser, and no one has messed with your hard disk, everything will be okay. How do you know
you have a valid copy of the browser? It will be signed by the browser vendor. How do you know
the browser vendor's signature is valid? Don't ask-there lies madness.

What Signing Can't Do

Even if the signing and signature-checking mechanisms work perfectly and are able to reveal who
signed each applet, a huge unsolved problem still remains. Technology can tell you who signed an
applet, but it can't tell you whether that person is trustworthy. That's a decision you have to make
based on human judgment. And you'd better make the right decision.

CHAPTER SECTION:4

Section 4 – Trust
Once a code signing infrastructure is in place, you will be able to know reliably who vouches for
each Java program. The next link in the chain is figuring out what to do with that knowledge.

One thing you can certainly do is to relax Java's security rules for applets that you trust. For
example, with the default sandbox Java normally prohibits any access to files in order to prevent an
applet from corrupting your hard drive or reading your private data. If you trust applets from
particular sources, though, you might want to allow them to read files. Introducing permissions
granted according to trust level opens up vast new application areas, including things like
spreadsheet applets, games with stored high scores, Web sites that recall your preferences, a host of
different remote management possibilities, and so on.

Besides access to files, there are many other capabilities you might want to grant a trusted applet or
application: access to your machine's microphone and camera, freedom to make network
connections, and maybe even freedom to label other code as trusted. It all depends on your decision
to trust and how much to trust a signed program. There are several ways you can make these
decisions.

Who Do You Trust?

The first decision is whether to use a black-and-white or a shades-of-gray policy. A black-and-

white policy is one that divides all programs into two groups: trusted and untrusted. This was the
only sort of trust policy that was easy to implement using JDK 1.1. Java 2, however, changed all
that. Java 2 makes it possible to create a shades-of-gray policy, allowing you to assign any degree
of partial trust to a Java program. (Recall Figure 1.6 in Chapter 1.)

Before Java came along, most Internet software worked on a black-and-white model. If someone
offered to let you download a program, you had two choices: either you downloaded the program
or you didn't. If you did, you were trusting the program completely since there was nothing to stop
it from running wild on your machine. If you didn't download the program, you were treating it as
completely untrusted. Java, with its security policies as implemented in the base sandbox, changed
the rules a bit by making it easier to decide what to download in the first place. If an untrusted
applet can't bite you, you might as well check it out.

The black-and-white model is sometimes called the shrink-wrap model because it's similar to
software you purchase. If you buy a software package from a reputable software store, you can
reasonably assume that the software is safe to load on to your machine. People who use the term
shrink-wrap model tend to assume that no one would ever want to run software that wasn't written
by a large software company. We don't agree with that implication, so we'll stick with the term
black-and-white.

It might seem that the shades-of-gray model is better than the black-and-white model, because
black-and-white only allows you to label programs as completely trusted or completely untrusted.
On the other hand, shades-of-gray gives you more choices. You may still label an applet as
completely trusted or completely untrusted if you wish.

Choices are not always good, as anyone who has encountered the cereal aisle of a large
supermarket can attest. Making choices takes up time that you would probably rather spend doing
something else. Frequent decision-making saps your attention span, so you are more likely to make
a mistake, thus opening yourself up to attack. Finally, having more options saddles your browser
with more complicated record-keeping duties to keep track of all of your decisions. This extra
complexity might lead to bugs in the browser, possibly jeopardizing security yet again.

Which model is better, black-and-white or shades-of-gray? It depends on how people react to the
two systems, which is hard to predict. Mostly likely, competing browsers will offer different
models, and the models will fight it out in the marketplace. The decision is ultimately one of user
preference.

Free the Trusted Code!

Once you've decided who to trust, the next issue is what you allow trusted programs to do. If you're
using the black-and-white model, then you have to decide whether to allow untrusted programs,
like applets off unknown Web sites, to run at all. You also have to decide what extra capabilities, if
any, you want to give to trusted programs. You might decide to let trusted programs do whatever
they want, with no restrictions at all. Or you might decide to run trusted programs under the
restrictive Java security rules of JDK 1.0.2. The choices depend on your taste for risk, and what
kinds of programs you want to run. With black-and-white security, however, all the programs you
trust receive the same level of trust.

If you're using a shades-of-gray model, you face more choices. You may decide on a program-by-
program (or signer-by-signer) basis exactly which capabilities to grant. Rather than presenting you
with a huge laundry list of possible capabilities for each program and forcing you to tick items off
the list, a good browser will probably provide a way for you to grant certain prepackaged sets of
capabilities. For example, there might be a set of permissions for videoconferencing applets, which
would include things like permission to use the camera, the microphone, the speaker, the display,
and networking access. Perhaps there would be another set of document-editing applet permissions,
which would include file-creation, file-reading, and file-modification capabilities.

There are two basic ways to group the mapping of program (or programs) to permission (or
permissions). Microsoft's Authenticode system, introduced in Chapter 1, defines security zones,
which are ways of grouping programs together. For example, all programs from a company intranet
signed by the system administrator's key might comprise a zone. (These zones might well involve
multiple keys and origins.) Policies can then be defined on a per-zone basis. Netscape defines
macro targets, which are groups of permissions (as sketched in the previous paragraph). For
example, a macro target might be called "typical game privileges" and define the permissions
typically needed by a network-enabled game.

Sun has a system of implication in which permission for code to use one resource can imply
permission to use another resource. In their model, each resource is required to define an implies()
method that can be used to ask a resource whether it implies a particular other permission. (More
detail is provided later in this chapter.)

All of these are examples of grouping signers or privileges together and treating the group as a unit.
Grouping is generally a good idea in security management because it reduces the number of
decisions that the user (or other policy-maker) faces. Fewer decisions means more attention paid to
each decision and hence, better decisions.

JDK 1.1, which introduced the concept of a signed applet, provides a black-and-white model. A
digitally signed applet can be treated as trusted local code as long as the signature key is recognized
as trusted by the system finally running the code. Java 2 provides a shades-of-gray model.

CHAPTER SECTION:5

Section 5 -- An Introduction to Java 2 Security

Signatures alone don't provide the infrastructure needed to allow Java code out of the sandbox
gradually. Access control mechanisms are required as well. In JDK 1.1, for example, applet code
signed by a trusted party can be treated as trusted local code, but not as partially trusted code
(without an inordinate amount of extra programming). There is no notion of access control beyond
the one-and-only trust decision made per class. That means in practice, JDK 1.1 offers a black-and-
white trust model much like ActiveX (although with the clear advantage that untrusted code must
stay in the sandbox).

The new security architecture in Java 2 has four central capabilities [Gong and Schemers, 1998]:
 Fine-grained access control: The ability to specify that code with proper permissions is
allowed to step outside the sandbox constraints gradually (for example, an applet signed by a
trusted key might be allowed to open arbitrary network connections).

Configurable security policy: The ability for application builders and Java users to configure
and manage complex security policies.

Extensible access control structure: The ability to allow typed permissions and to group such
permissions in logical, policy-oriented constructs.

Security checks for all Java programs: A departure from the concept that built-in code
should be completely trusted. (It is this capability that serves to erase the once-important
distinction between applets and applications.)

It is important to note that the first three of these four capabilities are not really new to Java. Java is
a powerful programming language, and it has always been possible to implement complex,
configurable, extensible security policies based on fine-grained access control. It was just
exceptionally tricky. Java 2 serves to make this task possible for mere mortals.

A View from 50,000 Feet

At its heart, the Java 2 security model has a simple idea: Make all code run under a security policy
that grants different amounts of privilege to different programs. While the idea may be simple, in
practice, creating a coherent policy is quite difficult. Figure 3.4 shows the role that mobile code
identity and policy play in Java 2.

Figure 3.4 Mobile code in Java 2 interacts with user

defined policy through the AccessController.

Byte code may make calls to potentially-dangerous

functionality. When such calls are made, the
AccessController (new to Java 2) consults policy and uses
stack inspection to decide whether to allow or disallow a call.
Decisions are based on the identity of the code.

Java 2 code running on the new Java VMs can be granted special permissions and have its access
checked against policy as it runs. The cornerstone of the system is policy (something that will not
surprise security practitioners in the least). Policy can be set by the user (usually a bad idea) or by
the system administrator, and is represented in the class java.security.Policy. Herein rests the
Achilles' Heel of Java 2 security. Setting up a coherent policy at a fine-grained level takes
experience and security expertise. Today's harried system administrators are not likely to enjoy this
added responsibility. On the other hand, if policy management is left up to users, mistakes are
bound to be made. Users have a tendency to prefer "cool" to "secure." (Recall the dancing pigs
of Chapter 1.)

Executable code is categorized based on its URL of origin and the private keys used to sign the
code. The security policy maps a set of access permissions to code characterized by particular
origin/signature information. Protection domains can be created on demand and are tied to code
with particular CodeBase and SignedBy properties. If this paragraph confuses you, imagine trying
to create and manage a coherent mobile code security policy!

Code can be signed with multiple keys and can potentially match multiple policy entries. In this
case, permissions are granted in an additive fashion.

A Simple Example
An easy example of how this works in practice is helpful. First, imagine a policy representing the
statement "code from "www.rstcorp.com/" applet signed by 'self' is given permission to read and
write files in the directory /applet/tmp and connect to any host in the rstcorp.com domain." Next, a
class that is signed by "self" and that originates from "www.rstcorp.com/" applet arrives. As the
code runs, access control decisions are made based on the permissions defined in the policy. The
permissions are stored in permission objects tracked by the Java runtime system. Technically,
access control decisions are made with reference to the runtime call stack associated with a thread
of computation (more on this later).

CHAPTER SECTION:6

Section 6 -- Access Control and Stack Inspection

The idea of access control is not a new one in computer security. For decades, researchers have
built on the fundamental concept of grouping and permissions. The idea is to define a logical
system in which entities known as principals (often corresponding one to one with code owned by
users or groups of users) are authorized to access a number of particular protected objects (often
system resources such as files). To make this less esoteric, consider that the familiar JDK 1.0.2 Java
sandbox is a primitive kind of access control. In the default case, applets (which serve as principals
in our example) are allowed to access all objects inside the sandbox, but none outside the sandbox.

So what we're talking about here is a way of setting up logical groupings. Then we can start talking
about separating groups from each other and granting groups particular permissions. Security is all
about separation. Readers familiar with the Unix or NT file system will see clear similarities to the
notion of user IDs and file permissions.

Sometimes a Java application (like, say, a Web browser) needs to run untrusted code within itself.
In this case, Java system libraries need some way of distinguishing between calls originating in
untrusted code and calls originating from the trusted application itself. Clearly, the calls originating
in untrusted code need to be restricted to prevent hostile activities. By contrast, calls originating in
the application itself should be allowed to proceed (as long as they follow any security rules that
the operating system mandates). The question is, how can we implement a system that does this?

Java implements such a system by allowing security-checking code to examine the runtime stack
for frames executing untrusted code. Each thread of execution has its own runtime stack (see Figure
3.5). Security decisions can be made with reference to this check. This is called stack inspection
[Wallach, et al., 1997]. All the major vendors have adopted stack inspection to meet the demand for
more flexible security policies than those originally allowed under the old sandbox model. Stack
inspection is used by Netscape Navigator 4.0, Microsoft Internet Explorer 4.0, and Sun
Microsystems' Java 2. (Interestingly, Java is thus the most widespread use of stack inspection for
security ever. You can think of it as a very big security-critical experiment.)

Figure 3.5 Each Java program

thread includes a runtime stack
that tracks method calls.

The purpose of the stack is to keep

track of which method calls which
other method in order to be able to
return to the appropriate program
location when an invoked method
has finished its work. The stack
grows and shrinks during typical
program operation. Java 2 inspects
the stack in order to make access
control decisions. In this example,
each stack frame includes both a
method call and a trust label (T for
trusted, U for untrusted).

Simple Stack Inspection

Netscape 3.0's stack-inspection-based model (and every other black-and-white security model) is a
simple access control system with two principals: system and untrusted. Just to keep things simple,
the only privilege available is full.

In this model, every stack frame is labeled with a principal (system if the frame is executing code
that is part of the VM or the built-in libraries and untrusted otherwise). Each stack frame also
includes a flag that specifies whether privilege is full. A system class can set this flag, thus enabling
its privilege. This need only be done when something dangerous must occur-something that not
every piece of code should be allowed to do. Untrusted code is not allowed to set the flag.
Whenever a stack frame completes its work, its flag (if it has one) disappears.

Every method about to do something potentially dangerous is forced to submit to a stack

inspection. The stack inspection is used to decide whether the dangerous activity should be
allowed. The stack inspection algorithm searches the frames on the caller's stack in sequence from
the newest to the oldest. If the search encounters an untrusted stack frame (which as we know can
never get a privilege flag) the search terminates, access is forbidden, and an exception is thrown.
The search also terminates if a system stack frame with a privilege flag is encountered. In this case,
access is allowed (see Figure 3.6).

Figure 3.6 Two examples of simple stack inspection.

Each stack is made of frames with three parts: a privilege flag (where full privilege is
denoted by an X), a principal entry (untrusted or system), and a method. In STACK
A, an untrusted applet is attempting to use the url.open() method to access a file in
the browser's cache. The VM makes a decision regarding whether to set the privilege
flag (which it does) by looking at the parameters in the actual method invocation.
Since the file in this case is a cache file, access is allowed. In short, a system-level
method is doing something potentially-dangerous on the behalf of untrusted code. In
STACK B, an untrusted applet is also attempting to use the url.open() method,
however in this case, the file argument is not a browser cache file but a normal file in
the filesystem. Untrusted code is not allowed to do this, so the privilege flag is not set
by the VM and access is denied.

Real Stack Inspection

The simple example of stack inspection just given is only powerful enough to implement black-
and-white trust models. Code is either fully trusted (and granted full permission at the same level as
the application) or untrusted (and allowed no permission to carry out dangerous operations).
However, what we want is the ability to create a shades-of-gray trust model. How can we do that?

It turns out that if we generalize the simple model we get what we need. The first step is to add the
ability to have multiple principals. Then we need to have many more specific permissions than full.
These two capabilities allow us to have a complex system in which different principals can have
different degrees of permission in (and hence, access to) the system.

Research into stack inspection shows that four basic primitives are all that are required to
implement a real stack inspection system. In particular, see Dan Wallach's Ph.D. thesis at Princeton
and the paper Understanding Java Stack Inspection [Wallach and Felten, 1998]. Each of the major
vendors uses different names for these primitives, but they all boil down to the same four essential
operations (all explained more fully in the following discussions):

enablePrivilege()
disablePrivilege()
checkPrivilege()
revertPrivilege()

Some resources such as the file system or network sockets need to be protected from use (and
possible abuse) by untrusted code. These resources are protected by permissions. Before code
(trusted or otherwise) is allowed access to one of these resources, say, R, the system must make
sure to call checkPrivilege(R).
If you recall our discussion of the Security Manager from the previous chapter, you'll remember
that the Java libraries are set up in such a way that dangerous operations must go through a Security
Manager check before they can occur. As we said, the Java API provides all calls necessary to
implement a virtual OS, thus making isolation of all required security checks possible within the
API. When a dangerous call is made to the Java API, the Security Manager is queried by the code
defining the base classes. The checkPrivilege() method is used to help make behind-the-scenes
access control decisions in a very similar fashion. To achieve backwards compatibility, the Security
Manager can be implemented using the four stack inspection primitives.

When code wants to make use of some resource R, it must first call enablePrivilege(R). When this
method is invoked, a check of local policy occurs that determines whether the caller is permitted to
use R. If the use is permitted, the current stack frame is annotated with an enabled-privilege(R)
mark. This allows the code to use the resource normally.

Permission to use the resource does not last forever; if it did, the system would not work. There are
two ways in which the privilege annotation is discarded. One way is for the call to return. In this
case, the annotation is discarded along with the stack frame. The second way is for the code to
make an explicit call to revertPrivilege(R) or disablePrivilege(R). The latter call creates a stack
annotation that can hide an earlier enabled privilege. The former simply removes annotations from
the current stack frame.

All three major Java vendors implement a very similar (and simple) stack inspection algorithm. A
generalization of this algorithm, after Wallach, is shown in Listing 3.1 [Wallach and Felten, 1998].

The algorithm searches stack frames on the caller's stack in order from newest to oldest. If the
search finds a stack frame with the appropriate enabled-privilege annotation, it terminates, allowing
access. If the search finds a stack frame that is forbidden from accessing the target by local policy,
or has explicitly disabled its privileges, the search terminates, forbidding access.

It may seem strange that the vendors take different actions when the search reaches the end of the
stack without meeting any of the conditions (sometimes called falling off the end of the stack).
Netscape denies permission, while both Microsoft and Sun allow permission. This difference has to
do with backward compatibility. The Netscape choice causes legacy code to be treated like an old-
fashioned applet, and confined to the sandbox. The Microsoft/Sun choice allows a signed Java
application to use its privileges even without explicitly marking its stack frames, thus making it
easy to migrate existing applications. Since Netscape did not support applications, they felt no need
to follow the Microsoft/Sun approach and instead chose the more conservative course of denying
permission. For more implementation detail on the three vendors' different code signing schemes,
see Appendix C.

Formalizing Stack Inspection

Members of Princeton's Secure Internet Programming team (in particular, Dan Wallach and
Edward Felten) have created a formal model of Java's stack inspection system in a belief logic
known as ABPL (designed by Abadi, Burrows, Lampson, and Plotkin) [Abadi, et al., 1993]. Using
the model, the Princeton team demonstrates how Java's access control decisions correspond to
proving statements in ABPL. Besides putting Java's stack inspection system on solid theoretical
footing, the work demonstrates a very efficient way to implement stack inspection systems as
pushdown automata using security-passing style. Interested readers should see [Wallach and Felten,
1998], which is available through the Princeton Web site
atcs.princeton.edu/sip/pub/oakland98.html. A more recent paper on how to implement stack
inspection more efficiently is also available on the Princeton site.

CHAPTER SECTION:7

Section 7 -- New Security Mechanisms in Sun's Java 2

Now that we have covered the basic concepts and the underlying mechanisms of Java 2 security,
we can delve into the details of the system. Essential mechanisms include many of the things we
have already discussed: identity, permissions, implies, policy, protection domains, access control,
and privilege. Sources for the information presented here include [Gong, et. al., 1997; Gong and
Schemers, 1998].

This section describes Sun's version of stack inspection. Netscape and Microsoft each have their
own version, but we decided to forgo a lengthy discussion of all three systems. Though the vendors
claim they are very different, we think the three systems are really quite similar. Perhaps one day
they will all converge, making developers' and managers' lives much easier.

Identity

Every piece of code needs a specific identity that serves as a basis for security decisions. In Java 2,
each piece of code has two identity-defining characteristics: origin and signature. These two
characteristics are represented in the class java.security.CodeSource, which allows the use of
wildcard entries to denote "anywhere" for origin and "unsigned" for signature.

Origin boils down to the location the code came from specified as a URL. This is the same sort of
identity used in separation of applets in the JDK 1.0.2 class loading scheme. In fact, Java 2 identity
is really an extension of that idea.

Signature is a bit more complicated. Remember, public/private keys come in pairs. As we know,
code can be digitally signed by a person or organization who vouches for it. The key used to
actually sign the code is the signer's private key. The key used to check the signature for validity is
the signer's public key. So, the public key corresponding to the private key used to sign a piece of
code is the second identity characteristic. (In practice, implementations actually use an alias for the
public key corresponding to the private key used to sign the code.)

Many people say that a signature on code tells you "who wrote the code" or "where the code came
from" (we've been guilty of this faux pas ourselves in days gone by), but this is not true. All a
signature tells you is who signed the code. The author, distributor, and signer of the code may all be
different parties. All you know for sure is that the signer vouches for the code. And since it makes
perfect sense for several people to vouch for the same piece of code, a good signature scheme ought
to allow a piece of code to carry several signatures; then each recipient can decide which of the
signers (if any) should be trusted.

Permissions

Requests to perform a particular operation (most notably a dangerous one) can be encapsulated as a
permission. A policy says which permissions are granted to which principals. The abstract class
java.security.Permission types and parameterizes a set of access permissions granted to classes.
Permissions can be subclassed from this class (and its subclasses). Good practice dictates that a
permission class should belong to the package in which it is used. Java 2 defines access methods
and parameters for many of the resources controlled by the VM.

Permissions include:

java.io.FilePermission for file system access

java.net.SocketPermission for network access
java.lang.PropertyPermission for Java properties
java.lang.RuntimePermission for access to runtime system resources
java.security.NetPermission for authentication
java.awt.AWTPermission for access to graphical resources such as windows

Permissions usually include a target and an action. For file access, a target can be a file or a
directory specified as file, directory, directory/file, directory/*, or directory/-. The * denotes all files
in the specified directory. The - denotes all files under the associated file system subtree (meaning
all by itself, - denotes all files in the entire system). Actions for file access include read, write,
execute, and delete.

An example of a file permission is:

p = new FilePermission("/applets/tmp/scratch", "read");

For network access, a target can be an IP address, hostname, or generalized set of hostnames and a
range of port numbers. The target argument takes the form "hostname:port-range". Actions for
network access include: connect, listen, and accept. An example of a socket permission is:
 p = new SocketPermission("bigbrother.rstcorp.com:-1023", "connect")

For getting and setting properties, a target is the property (where * denotes all properties). Actions
are get and set. Runtime system resource targets include createClassLoader, exit, setFactory,
thread, multicast, fileDescriptor.read, fileDescriptor.write, and so on. AWT permission targets
include topLevelWindow, systemClipboard, and eventQueue.

Fully trusted Java applications can add new categories of permissions.

Implies

Each Permission class must include the abstract method implies. The idea is straightforward:
having permission x automatically implies having permission y. We denote this x.implies(y) ==
true in code. A permission x implies another permission y if and only if both the target of x implies
the target of y and the action of x implies the action of y. Consider the permission "read file
/applets/tmp/scratch," which can be written as:
p = new FilePermission("/applets/tmp/scratch", "read");

A permission allowing a read on any file in /applets/tmp; that is, a permission denoted by the pair
(/applets/tmp/*, read) implies our example permission p, but not vice versa. Similarly, a given
socket permission s implies another socket permission t if and only if t covers the same IP address
and port numbers for the same set of actions.

Alert readers might have noticed something funny about the implies method: Each permission class
says which other permissions it implies. This is a bit like Johnny writing himself a note saying he
can drive Dad's car. It seems safer to require Dad's signature on the note. Similarly, it would be
safer if permission for A to imply B had to be granted by B.

Policy

Security policy in Java 2 can be set by a user (which is a bad idea since, as we know, users like
dancing pigs) or a system administrator (which in a Catch-22-like situation is also a bad idea since
system administrators are severely overworked). The policy is represented by a policy object as
instantiated from the class java.security.Policy.

The policy is a mapping from identity (as defined earlier) to a set of access permissions granted to
the code. The policy object is a runtime representation of policy usually set up by the VM at startup
time (much like the Security Manager). An example policy object (in plaintext form) is shown here:

grant CodeBase "https://www.rstcorp.com/users/gem", SignedBy "*" {

permission java.io.FilePermission "read,write", "/applets/tmp/*";
permission java.net.SocketPermission "connect", "*.rstcorp.com";
};
This policy states that any applet that arrives from the Web URL "www.rstcorp.com/users/gem",
whether signed or unsigned, can read and write any file in the directory /applets/tmp/* as well as
make a socket connection to any host in the domain rstcorp.com. Policies are usually made of many
grant clauses.

In practice, policy is set in a plaintext configuration file and is loaded into the VM at startup. In
these policies, a public key (usually a very long string of bits) is signified by an alias. The alias is
the name of a signer represented as a string. For example, a popular alias is the string "self",
meaning your own private key. Primitive mechanisms are included to create and import public keys
and certificates into the Java 2 system. (See Appendix C for the details.)

By default, Sun's VM expects to find a system policy in the file

<java.home>/lib/security/java.policy (where <java.home> is a configurable Java property). This
policy can be extended on a per-user basis. User policy files can be found in a user's home directory
in the file .java.policy. The VM loads the system policy at startup and then loads any relevant user's
policy. If neither policy can be found, a built-in default is used. The built-in default policy
implements the base Java sandbox model.

It is possible to specify a particular policy to use when invoking an application. This is carried out
by using the Java-property-defining -D flag as follows (for the example, our application is the
appletviewer):
appletviewer -Djava.policy=/home/users/gem/policy <applet>

Note that when application policy is defined in this way, neither the system policy nor any user
policy is enforced.

Mapping Policy

Code's identity is checked against the entries of a policy object to determine what permission(s) a
piece of code should be given. At the most basic level of understanding, a match is made when both
the origin and the signature match. In terms of origin, this means the URL defining the origin for a
piece of code is a prefix of a policy entry's CodeBase pair. In terms of signature, this means one
public key corresponding to the signature carried by the code matches the key of a signer in the
policy. Verification of signatures makes use of functionality in the java.security.cert package,
which is a Java implementation of X.509v3 certificates.

Code can be signed with multiple signatures. In case the signatures a piece of code carries have
different policy entries, all entries apply in an additive fashion. That means code is given the union
of all permissions in every match (see Figure 3.7).
 Figure 3.7 The danger of additive policy.

Consider the program X shown here. In one case, X is signed by thing1. In

another, code is signed by both thing1 and thing2. In the second case, the policies
of both thing1 and thing2 apply to the code (meaning in this case that it has more
permission to do dangerous activities). A policy administrator may forget to
anticipate what happens when code is signed by multiple keys.

Consider the program X shown here. In one case, X is signed only by thing1. In another, code is
signed by both thing1 and thing2. In the second case, the policies of both thing1 and thing2 apply to
the code (meaning in this case that it has more permission to do dangerous activities). A policy
administrator may forget to anticipate what happens when code is signed by multiple keys.

Protection Domains

Sun says that classes and objects in Java 2 Java belong to protection domains. In fact, protection
domain is just a fancy name for a bunch of classes that should be treated alike because they came
from the same place and were signed by the same people. (The fact that protection domain means
something completely different to people familiar with the security literature is reason enough to
avoid the term.) An object or class belongs to one and only one protection domain. This should ring
a bell, since classes can have one and only one class loader (the one that loaded them). So really
this is a new way of describing a somewhat familiar logical construct for grouping classes together.
A class belongs to the protection domain associated with the class loader that loaded the class.

Permissions are granted to protection domains and not directly to classes and objects, as Figure 3.8
reflects. The class java.security.ProtectionDomain is private in its package and is used internally to
implement protection domains. As we discussed earlier, a domain is made up of a set of objects
belonging to a principal. In Java 2, protection domains are based on identity and can be created "on
demand." The Java runtime maintains a mapping from code to protection domains to permissions
(see Figure 3.8).

Figure 3.8 Grouping classes together to map them to

policy.

Classes map into what Sun calls protection domains which

in turn map to permissions. Policy is defined in terms of
protection domains.
System security policy specifies which protection domains should be created and which protection
domains should be granted what permissions.

There is one protection domain that is special: the system domain. The system domain includes all
system code loaded with the Primordial Class Loader. This includes classes in the CLASSPATH.
The system domain is given special privileges.

Access Control

The java.security.AccessController class implements a stack inspection algorithm similar to the one
we described earlier. Any code is allowed to query this class, which performs a dynamic inspection
of the relevant thread's runtime stack. The method used to implement the check is
checkPermission(), which takes as its argument a Permission object. If the call returns silently,
permission is granted and the potentially dangerous computation can proceed. If the call fails, an
AccessControlException is thrown.

Using the Access Controller

Access control under JDKs previous to Java 2 typically used the Class Loader and Security
Manager to make access control decisions. For example, the following code snippet checks whether
a file /tmp/junk can be read in the old-fashioned way:

ClassLoader loader = this.getClass().getClassLoader();

if (loader != null) {
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkread("/tmp/junk");
}
}

Here's how to do the same thing in Java 2 fashion (using the Access Controller):

FilePermission p = new FilePermission("/tmp/junk", "read");

AccessController.checkPermission(p);

The Access Controller call performs the appropriate stack inspection.

Privilege

Up through JDK 1.2beta3, Sun's JDK used the primitives beginPrivileged and endPrivileged as
versions of the stack inspection primitives enablePrivilege and disablePrivilege we described in our
discussion of stack inspection. These are the calls that a piece of privileged system code (that is
allowed to do things like perform file access) was supposed to use to grant temporary permission to
less-trusted code. These calls were featured in a number of technical publications from Sun [Gong,
et. al., 1997; Gong and Schemers, 1998].
The idea is to encapsulate potentially dangerous operations that require extra privilege into the
smallest possible self-contained code blocks. The Java libraries make extensive use of these calls
internally, but partially trusted application code written using the Java 2 model will be required to
make use of them, too.

Correct use of the JDK primitives required using a standard try/finally block is as follows:

<normal code>
try {
AccessController.beginPrivileged();
<insert dangerous code here>
} finally {
AccessController.endPrivileged();
}
<more normal code>

This usage was required to address the problem of asynchronous exceptions (though there was still
some possibility of an asynchronous exception being thrown in the finally clause sometime before
the endPrivileged() call).

Wallach and Felten first explained a particularly efficient way to implement stack inspection
algorithms in [Wallach and Felten, 1998]. Unfortunately, Sun decided to abandon the
multiprimitive approach to stack inspection (which could benefit from Princeton's security-passing
style implementation). In fact, JDK 1.2beta4 introduced a completely new API for privileged
blocks. The new API removes the need for a developer to: 1) make sure to use try/finally properly,
and 2) remember to call endPrivileged(). The try/finally usage was symptomatic of a problem that
could only really be fixed with some changes to the VM specification and its resulting
implementations.

In order to properly implement the early API, VMs would have been forced to keep track of the
beginPrivileged() call (unless they adopted a security-passing style approach). This requires
tracking a stack frame (the one where the beginPrivilege is mentioned) and matching the beginning
of a privileged block to its corresponding end-every time a privileged block is used. Doing all this
bookkeeping is inefficient and thwarts optimization tricks that compilers like to play. For example,
just in time (JIT) compilation approaches are hard to adapt to this model. Plus it turns out that
security boundaries are crossed many thousands of times a second, so even a slight delay gets
magnified quickly.

Bookkeeping would slow the VM down, which is about the last thing Java VMs need now as they
near native C speeds. A Sun document explaining the change (from which some of the material
here was drawn) is on the Web at www.javasoft
.com/products/jdk/1.2/docs/guide/security/doprivileged.html.

The new API interface wraps the complete enable-disable cycle in a single interface accessed
through a new AccessController method called doPrivileged(). That means the VM can efficiently
guarantee that privileges are revoked once the method has completed, even in the face of
asynchronous exceptions.

Here's what the new usage looks like. Note the use of Java's new inner classes capability:
 somemethod() {
<normal code>
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
<insert dangerous code here>
return null;
}
});
<more normal code>
}

Ironically, one of our developer rules for writing more secure Java code is to avoid using inner
classes (see Chapter 7, "Java Security Guidelines: Developing and Using Java More Securely")!
But if you want to include privileged blocks in your Java 2 code, you are encouraged to use them.
In addition to the inner-class problem, verbosity is also a problem with the new API.

It turns out that using the new API is not always straightforward. That's because anonymous inner
classes require any local variables that are accessed to be final. A small diversion can help explain
why this is.

Closures
The new API is doing its best to simulate what programming languages researchers call closures.
The problem is, Java doesn't have closures. So what are they anyway? And why are they useful?

Functions in most programming language use variables. For example, the function f(x)=x+y adds
the value of the formal parameter x to the value of variable y. The function f has one free variable,
y. That means f may be evaluated (run) in different environments in which the variable y takes on
different values. In one environment, E1, y could be bound to 2. In another environment, E2, y
could be bound to 40. If we evaluate f(2) in E1, we get the answer 4. If we evaluate f(2) in E2, we
get the answer 42.

Sometimes we want a function to retain certain bindings that its free variables had when it was
created. That way we can always get the same answer from the expression. In terms of our
example, we need to make sure y always takes on a certain value. What we want is a closed
package that can be used independent of the environment in which it is eventually used. That is
what a closure is. In order to be self-contained, a closure must contain a function body, a list of
variables, and the bindings of its variables. A closure for our second example might look like this:
[{y=40;} f(2)=2+y]

Closure is particularly useful in languages with first-class functions (like Scheme and ML). In these
and other related languages, functions can be passed to and returned from other functions, as well
as stored in data structures. Closure makes it possible to evaluate a function in a location and
external environment that may differ from where it was created. For more on this issue, see
[Friedman, et al., 1992; Fellisen and Friedman, 1998].

As we said before, Java does not have closures. Java's anonymous inner classes come as close to
being closures as Java gets. A real closure might include bindings for the variables that can be
evaluated sometime in the future. In an anonymous inner class, however, all state must be made
final (frozen) before it is passed in. That is, the final state is the only visible state inside the inner
class. This is one reason anonymous inner classes are not true closures. The problem of making
everything final turns out to have strong implications for the use of the new privileged block API.

Local Variables
For example, in the following code, the variable lib must be declared final if it is to be used inside
the privileged block:

randommethod() {
<normal code>
final String lib = "awt";
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
System.loadLibrary(lib);
return null;
}
});
<more normal code>
}

Making all local variables that are to be accessed in the block final is a pain, especially if an
existing variable can't be made final. In the latter case, the trick is to create a new final variable and
set it to the non-final variable just before the call to doPrivileged. We predict this will be a source
of both headaches and errors. Errors may lead to security problems.

What Comes Out

Another problematic issue with the new interface is the fact that the inner class always returns an
Object (a return type seen throughout the Java language). That means if a call to a piece of
privileged code (for example, a call to System.getProperty()) usually returns something other than
an Object (for example a String), it will have to be dynamically cast to the usual type. Using a final
variable to pass types out is possible, too. Unfortunately, both of these operations will incur a
runtime performance hit (especially casting). The returns-only-Object problem is another source of
potential errors.

Whence the Change

It is good that VM vendors want their machines to be fast and efficient; however, purely in terms of
security, it is unclear whether the decision to change the API was a good one. Not that the previous
API was perfect, but the new one seems to introduce several places in which errors are bound to be
made by developers charged with actually using VMs. The real answer to the problem is
introducing closures to Java. Closures are something to look for in future JDK versions.

The Security Manager Revisited

As we described in Chapter 2, "The Base Java Security Model: The Original Applet Sandbox," the
Security Manager up until JDK 1.1 invoked a direct check() method for dangerous resource access
control. This method was responsible for evaluating the request and denying or granting access.
The new Security Manager in Java 2 still supports the use of check() methods, but now many of
these calls are actually implemented to make use of the Access Controller and Permission objects
(whenever possible).

It would be best to dispense entirely with the Security Manager, but history dictates that it remain
available for reasons of backwards compatibility. Breaking all existing JDK 1.1 code in order to
introduce a new security design is not an economically viable approach for Java.

The Secure Class Loader

Java 2 introduces the class java.security.SecureClassLoader, which is a concrete implementation of

the abstract ClassLoader class. It tracks the code source and signatures of each class, and hence
assigns classes to protection domains. All Java code is loaded by a Secure Class Loader (except for
code loaded by the Primordial Class Loader) either directly or indirectly (that is, by another class
loader that was itself loaded by the Secure Class Loader). For more on class loading, refer
to Chapter 2.

Sandboxing Java Applications

Now that the security enforcement mechanisms are more complex and do not rely on the distinction
between applet code and built-in code (as in the early days), it is possible (and desirable!) to force
Java applications, in addition to applets, to run within the (highly mutable) sandbox. This means
application code can be made to cohere with locally defined security policy. Java 2 provides a
mechanism for doing this with the class java.security.Main. The implementation ensures that local
applications stored in the java.app.class.path are loaded with the Secure Class Loader. It is a good
idea to have applications run from this location as opposed to placing them in the CLASSPATH
where they will be treated as built-in code.

Adding Permissions

It is possible to add new permissions to Java that are tailored to your specific needs. This is done by
subclassing and extending the java.security.Permission class we detailed earlier. The new
permission classes that you create should be stored in the application package where they apply.

Next, a representation of the permission (that is, a string representing a policy entry) needs to be
added to the policy file. This ensures that the permission is "automatically" configured for each
domain.
Finally, the application code itself may include a section that manages resources. This section of
code should make use of the checkPermission() method of the AccessController class (explained
earlier). Use of this method obviates the need to think about Class Loaders and Security Managers.

CHAPTER SECTION:8

Section 8 -- Outside the Sandbox

Java 2 clearly introduces significant changes to the Java security landscape. It is likely that the days
of black-and-white security policy for mobile code are numbered. With the major changes to Java's
security architecture come a number of important responsibilities, the most important of which is
mobile code policy creation and management. The tools are still primitive, but the policy itself is
essential.

Also essential to any mobile code system that makes use of code signing is solid key management
capability. Although the subject of public key infrastructure (PKI) is really beyond the scope of this
book, we at least invoke some important concepts. Managers responsible for setting and
maintaining policies based on signed code will encounter issues including choice of certificate
authority, who to issue keys to, how to ensure that private keys are kept private, whether to get a
corporate key and how to protect it, how to disable keys of employees who leave an organization,
where to store keys, and so on. These are nontrivial issues that have yet to be worked out in the real
world.

Hopefully, widespread support for code-signing systems will quickly appear on consumer desktops
worldwide. Truthfully, the PKI is much less mature than many security researchers and pundits
predicted it would be by now. This is partly because deploying an effective PKI is much more
difficult than it sounds. But it is also at least partially due to the greed of certificate authorities who
chose to charge developers for identities (public/private key pairs) instead of issuing them for free
and charging elsewhere for their use. Without a solid PKI, systems like Java 2 Java may take a
while to catch on. We predict that signed mobile code will find its most pervasive use among early
adopters as an intranet technology (as opposed to an Internet technology). Of course, we're very
well prepared to be wrong about that.

For a long time, Java developers have wanted some way in which less restriction could be placed
on their applets. At the same time, managers in many enterprises have been searching for ways to
manage code (not just mobile code, but any code) more securely. In its Java 2 guise, Java offers a
powerful answer to these needs.

We would be irresponsible not to note that with code signing comes a host of new risks to manage.
Most notable among the risks are two: first, that the implementation will have holes (JDK 1.1 code
signing has already fallen prey to this risk); and second, that security policies will get too
complicated to understand and manage.
 Malicious Applets:
Avoiding a Common Nuisance
Chapter 2, "The Base Java Security Model: The Original Applet Sandbox," and Chapter 3, "Beyond
the Sandbox: Signed Code and Java 2," explain how Java 2's security system works. This chapter
and the next explain how it doesn't. Unfortunately, it is entirely possible to (mis)use Java,
especially in its applet form, as a vehicle for attacking systems. Language-based security controls
like those found in Java make writing a hostile applet more difficult than it might be otherwise, but
they don't make it impossible. (Recall that Java security stacks up favorably against competing
mobile code systems like ActiveX, as we discussed in Chapter 1, "Mobile Code and Security: Why
Java Security Is Important.") Applets that misbehave and do something that their users don't want
to happen are called hostile applets.

There are two varieties of hostile applets: malicious applets and attack applets. The names of the
two classes make it clear which is the more serious variety. Fortunately, attack applets are not
commonly encountered on the Web; in fact, no attack applets have been seen to date in the wild
(that is, outside the labs in which they were created). That's not to say that attack applets are not
real. They are. Attack applets are real applets, written in everyday Java, that work against popular
browsers such as the one you use. Attack applets have been created and extensively tested in the
laboratory. (We return to the subject of attack applets in Chapter 5, "Attack Applets: Exploiting
Holes in the Security Model.") There is, however, another more pervasive kind of hostile applet,
not as serious a security concern, but still worthy of attention-the malicious applet.

Unlike their attack applet cousins, malicious applets have escaped the lab. Such realities make it
necessary for all users of Java-enabled browsers (and their trusty system administrators) to be
aware of Java security threats. Simply surfing over to a Web page containing a hostile applet allows
it to invade your machine with its malicious code. This chapter explores many malicious applets,
ranging from the merely annoying to the more seriously disturbing.

Near the beginning of Chapter 2, classes of potential Java threats were discussed. The four classes
of attacks named were system modification attacks, invasion of privacy attacks, denial of service
attacks, and antagonistic attacks. Java is a powerful enough language that, without security
constraints placed on applets, it is possible to implement all four such classes of attacks. The Java
security model was designed to thwart those threats perceived to be the greatest dangers.

Much ado has been made over Java security problems, and there have in fact been a number of
serious flaws. We detail the truly serious problems in Chapter 5. Such problems result in intrusions
that allow arbitrary system modification (effectively, unlimited access). An attack applet based on
one of these strategies constitutes a cracker breaking into your machine.

It is true that the very serious attacks of the next chapter require an in-depth understanding of both
Java and the Internet. It has been argued that we should feel fairly confident that few people will be
able to exploit such esoteric vulnerabilities. That position is a dangerous one to take. One instance
of a cracker discovering a novel attack applet will change such statements considerably. Once
loose, attack applet information would quickly spread throughout the cracker community. Our job
as security researchers is to find security holes and plug them before they are used by dishonest
people. Security researchers also work to create such a secure model that holes are very rare.
Fortunately, none of the serious attacks have shown up in the form of attack applets, although the
possibility looms ominously.

Don't breathe a sigh of relief yet. Tampering with Java security does not always require wizardry.
In fact, writing Java code to breach security can be easy. This chapter discusses some simple Java
applets gone bad. Such applets are known on the Net as malicious applets. Entire collections are
available for anyone interested to see, to adapt, and to use. See, for example:

• The Hostile Applets Home Page at www.rstcorp.com/hostile-applets

• DigiCrime at www.digicrime.com
• The Java Security Hotlist: Hostile Applets and Other Toys
at www.rstcorp.com/javasecurity/applets.html

The best first defense against these sorts of applets is to learn about them.

Chapter Four Sections

1. What Is a Malicious Applet?
2. Annoying Applets
3. Denial of Service
4. Opening Untrusted Windows
5. Stealing Cycles
6. Forging Mail
7. Killing Off the Competition
8. Malicious Applets on the Web
9. The Implications

Malicious Applets: Avoiding a Common Nuisance

CHAPTER SECTION:1

Section 1 -- What Is a Malicious Applet?

A malicious applet is any applet that attacks the local system of a Web surfer using one of the three
less-serious classes of attacks discussed inChapter 2. Malicious applets involve denial of service,
invasion of privacy, and/or annoyance. Malicious applets are written by researchers, crackers, and
Net miscreants to harass, annoy, and damage Java users. They can even seriously damage a Java
user's machine. Any applet that performs an action against the will of the user who invoked it
should be considered malicious.

It is important to emphasize again that use of the term Java user applies equally to Java developers
and people surfing the Web with a Java-enabled browser. Using Java does not require any
programming, or even possession of the JDK; it is enough to use a Java-enabled browser. Under
this definition, most people who surf the Web with Java on are Java users. Malicious applets exist
on the Web today that do the following bad things:

• Forge mail from you to whomever the evil applet's author chooses, saying whatever they
wish while masquerading as you
• Steal your CPU cycles to perform their own work while your legitimate processes languish
• Crash your local system by using all available system resources

These activities are both impressive and daunting, and we have only scratched the surface.

There are also malicious applets created simply to annoy. These applets go only a bit too far,
lingering at the edge of respectability. These sorts of applets do things like play sound files
continuously, set up threads that monitor your Web use, and display unwanted graphics on your
screen.

Stopping Malicious Applets before They Start

What can be done to stop malicious applets from doing their evil deeds? The best alternative now is
to set a security policy that allows only applets signed by trusted parties to run. But if you want to
surf with a Java-enabled browser and run every Java applet you come across on the Web, the safest
thing to do is to avoid unknown and untrusted Web sites unless you first disable Java. Just by using
a Java-enabled browser to surf the Web, you are open to attack by both attack applets and malicious
applets. This danger, combined with the serious attacks discussed in Chapter 5, has caused the
CERT Coordination Center to recommend disabling Java when surfing untrusted sites [CERT,
1996a; CERT, 1996b].

What can be done to stop these applets from doing their evil deeds in the future? There are many
possibilities. One interesting approach would be to write detectors for bad applets based on known
vulnerabilities. That way, they could be screened out by the byte code Verifier (or some similar
extension). Princeton's Secure Internet Programming team has investigated this possibility
extensively, and research at Reliable Software Technologies continues. (It turns out that the
problem is harder than it may seem on first consideration.) A number of commercial enterprises
now sell products that claim to screen byte code for malicious characteristics. We investigate these
products in Chapter 6, "Securing Java: Improvements, Solutions, and Snake Oil."

Another way to protect against malicious applets is by improving Java's security model. To the
extent that any holes identified by researchers have been quickly and thoroughly patched, the
security model can be said to be improving. However, the practice of patching software after
exploits have been demonstrated is backwards. This unfortunately common strategy is known as
penetrate and patch, and has been criticized for many years by security practitioners. (For more on
this issue, see [McGraw, 1998].) Better software engineering and more thorough software
assurance practices are much more appealing. It is even possible to write your own code
defensively so it makes a much harder target for bad guys to attack (see both the guidelines
of Chapter 7, "Java Security Guidelines: Developing and Using Java More Securely," and Chapter
9, "The Future of Java Security: Challenges Facing Mobile Code").

The addition of code signing to Java in JDK 1.1 and its extension with access control in Java 2
allow for the creation of complex security policies based on authentication of applet signers. Using
this technology, a Web surfer could specify a list of trusted sites whose applets should be allowed
to run without restrictions. The trick is creating a sound security policy and correctly coding it into
your browser.

The next few sections discuss various kinds of malicious applets. Starting with the least worrisome
category-the merely annoying-the text progresses through the truly malicious machine-hangers.
Possible motives for creating these applets are discussed along the way. Keep in mind while you
read this chapter that the malicious applets described here pale in comparison with the attack
applets described in Chapter 5. Fortunately, the security researchers who discovered those
vulnerabilities are the good guys.

Disabling Java

Certainly, many unsavory characters are on the Net, and many of them have created similarly
unsavory Web pages. If for some reason you wish to check such sites out, it would be a good idea
to disable Java first.

The best way to protect yourself from malicious applets is to create a policy that allows only code
you trust to run. It is quicker and easier, however, to disable Java when surfing dangerous Web
sites. Much like being street-wise in a big city, your choice to use or disable Java depends on what
browsing you will be doing. If you keep to the sites of big business, you are less likely to find
dangerous applets, just as the finance districts of New York and Chicago are less dangerous than
the housing projects. Know where you are on the Web and take precautions accordingly.

Disabling Java in Netscape Navigator 4.x

Disabling Java under Netscape Navigator 4.x is easy and can be done in the midst of a session.
Reenabling Java is also possible, should you change your mind. Figures 4.1 and 4.2 explain how
Java can be disabled in Netscape Navigator 4.x.
 Figure 4.1 Disabling Java in Netscape Navigator under Solaris.

From the Edit menu, select Preferences. Click on the word Advanced, which will
appear in the window entitled "Category" (as shown here). To the right of that
window, a series of radio buttons will appear, one of them labeled Enable Java. Click
the button so it appears to be sticking out. Finally, click OK, and Java will be
disabled.

Figure 4.2 Disabling Java in Netscape Navigator under Windows NT.

From the Edit menu, select Preferences. Click on the word Advanced, which will
appear in the window entitled "Category" (as shown here). To the right of that
window, a series of checkboxes will appear, one of them labeled Enable Java. Click
on the check box, removing the check mark. Finally, click OK, and Java will be
disabled.

Disabling Java in Internet Explorer 4.x

Internet Explorer also allows Java to be disabled. Figure 4.3 explains how Java can be disabled in
Internet Explorer 4.x.
 Figure 4.3 Disabling Java in Microsoft Internet Explorer.

Unfortunately, under MSIE you can only disable Java on a per-zone basis. From
the View menu, select Internet Options. Click on the Security tab. Select the
zone for which you want to disable Java (for example, the Internet zone). (For
more on zones, see Chapter 1.) Then select the Custom radio button and click
on the Settings button. A dialog will come up called Security Settings. This is the
dialog shown here. Scroll down until you see the Java category. It will have an
expanded sub-category called Java permissions. The sub-category will have a
list of options. Click on the circle labeled Disable Java, then click OK. You'll then
be back at the Security tab. Click OK again, and Java will be disabled.

Snagging Malicious Code

Running malicious code, especially code that explicitly claims to be malicious, is always an
interesting conundrum. You may want to check a malicious applet out to see how it works against
your machine, but at the same time, you don't want your machine to be compromised by an attack.
Although it is advisable to avoid running malicious code at all, some people can't resist. The
following strategy may help.

With Java off, surf to the Web page with a suspected malicious applet; for example, the DigiCrime
site includes a malicious applet called "bluescreen" at www.digicrime.com/exploits/javawin. A
quick look at the HTML source for the page shows that the malicious applet is invoked with the
following code snippet:
<APPLET CODE="bluescreen.class"
CODEBASE="http://www.digicrime.com/surprise" width=1 height=1>

This gives you all the information you need to snag the class file (without running it) and bring it
home for dissection.
The next step is to point your browser directly at the class file by opening
URL www.digicrime.com/surprise/bluescreen.class. Your browser will display some gobbledygook
like Ê_°_me`, which is actually the byte code of the class file as shown in "human readable" form.
Use the Save As feature of your browser to save the file bluescreen.class on your disk.

Now that you have the file, you can use a Java decompiler to turn it back into readable Java source
code. The once-popular Mocha decompiler is now out of date as its author, Han Peter van Vliet,
died an untimely death. However, there are other decompilers available. The best is the
SourceAgain decompiler from Ahpah Software. After decompiling the byte code, you can inspect
the resulting Java source code for malicious behavior.

Note that the decompilation issue is a complex political football. Laws have been proposed that
make decompiling copyrighted code illegal, even if it is done by security researchers for the
purposes of code analysis. The intent of the laws is to prevent software piracy, but they are overly
broad in their language. The bottom line is to educate yourself about such laws before you begin
decompiling code to analyze it.

Once you know what a malicious applet is going to do, you may feel more comfortable running it.
Keep in mind that there is no guarantee that the class file that you grab and decompile will be the
same as the one you eventually run from a Web site. The Web server can easily be programmed to
bait and switch so that it changes the class file that it distributes unpredictably. Unless you run your
grabbed copy of the class file from your own Web server, all bets are off.

CHAPTER SECTION:2

Section 2 -- Annoying Applets

The simplest kind of malicious applet is only annoying. Malicious applets of this type do things just
beyond acceptable. Because Java has powerful multimedia packages, annoying applets can do a
large variety of things, ranging from playing sound files continuously to displaying obscene
pictures.

Java has attracted its share of bad programmers and, depending on your point of view, bad Java
code can be annoying. To be counted as a hostile applet, some malicious intent on the part of the
author is usually required; therefore, unintentionally lousy Java code may not count. Just for the
record, a poorly written Java applet may aid a real cracker in breaking your Java security system.
Avoid running crummy code, and if you're developing code, use sound software engineering
practices and follow the guidelines provided in Chapter 7.
One particularly humorous annoying applet opens a dialog box with the message "April Fools" and
an OK button. Users naturally think the applet is supposed to exit when you click OK as it says on
the screen. But the dialog box zips around the screen, avoiding the mouse as the user tries to click
OK. This quirk renders the applet difficult to stop through normal means. The easiest way to get rid
of it is to exit the browser.

Listing 4.1 provides the code for another annoying applet based on an idea from Mark
LaDue.1 This applet appears to be well-behaved, at first. All it does is display a nice little picture of
one of the author's dogs (and baby Jack). It also plays some appropriate background sound (the dog
barking). Not all that exciting for an applet. The code is shown in Listing 4.1.

Listing 4.1 NoisyApplet sustains a thread past the time its creating class is unloaded.

/* NoisyApplet.java */
/* Adapted from the NoisyBear applet of Mark LaDue. */
/* You will need a sound file and a picture to make */
/* this work. */
/* This applet is provided solely as an example and */
/* is not guaranteed to do anything. */
/* Use it at your own risk. */

import java.applet.AudioClip;
import java.awt.*;

public class NoisyApplet extends java.applet.Applet implements Runnable {

Font msgFont = new Font("TimesRoman", Font.PLAIN, 36);
Thread noisethread = null; // thread to run sound in
Image jackImage;
Image offscreenImage;
Graphics offscreenGraphics;
AudioClip bark; // sound file variable

// the init() runs to set things up

public void init() {
// first, set up the picture
jackImage = getImage(getCodeBase(), "jack+waldog.jpg");
offscreenImage = createImage(this.size().width,
this.size().height);
offscreenGraphics = offscreenImage.getGraphics();
// then load the audio file
bark = getAudioClip(getCodeBase(), "bark.au");
}

// the start() method runs whenever you enter the

// applet's page. it also runs after init()
public void start() {
// start a thread to run the audio clip in
if (noisethread == null) {
noisethread = new Thread(this);
noisethread.start();
}
}

// the stop() method runs when you exit

// the applet's page
public void stop() {
if (noisethread != null) {
// uncommenting the following 2 lines will stop
 // the sound
// if (bark != null)
// bark.stop();
noisethread.stop();
noisethread = null;
}
}

// this starts the ball rolling by telling the sound

// to "go"
public void run() {
if (bark != null) bark.loop();
}

// the paint() method draws the graphics

public void paint(Graphics g) {
int jack_width = jackImage.getWidth(this);
int jack_height = jackImage.getHeight(this);

offscreenGraphics.drawImage(jackImage, 0, 0,
jack_width, jack_height, this);

offscreenGraphics.setColor(Color.red);
offscreenGraphics.setFont(msgFont);
offscreenGraphics.drawString(
"Walnut says HI HI HI ...", 150, 225);
// actually draw the image
g.drawImage(offscreenImage, 0, 0, this);
}
}

This applet has been tested and proven to be annoying on a large number of platform/browser
combinations.

What makes the NoisyApplet annoying is that the sound never stops, even if the user surfs to
another Web page. How could this happen? Simple; the applet starts a thread that never stops!

Listing 4.2 Spinning a thread forever.

public void stop() {

if (noisethread != null) {
// uncommenting the following 2 lines will
// stop the sound
// if (bark != null)
// bark.stop();
noisethread.stop();
noisethread = null;
}
}

Why does the sound keep on going? As you can see in the Listing 4.2, the stop() method of the
NoisyApplet class has been redefined. The redefinition makes the thread live until the user either
figures out how to kill the thread, disable audio on the target machine, or quit the browser.2None of
these options are particularly convenient.

The lines commented out would silence our NoisyApplet by installing a more normal stop()
method. By commenting out these lines you can turn our somewhat-typical applet into a malicious
annoyance. Clearly, the line between an honest mistake and an antagonistic programming practice
is very fine indeed.

There are some interesting implications that our simple annoying applet introduces. Any thread can
employ the same strategy of redefining the stop() method in order to run ad infinitum. Depending
on the way a Security Manager is written, Java may not require a programmer to stop all threads.
Overriding the default stop() method is, as we have shown, a trivial exercise. Threads can run even
in the absence of the applet that spawned them, meaning that it is possible to write threads that
monitor what the user is doing.

Going beyond stop()

Redefining the stop() method is an easy thing to do, but it is sometimes possible to determine that
an applet is doing this by inspecting its byte code. An alternative to redefining the stop() method is
wrapping an attack in a try/finally block. This technique is often seen in malicious applets. In fact,
today's slickest malicious applets both redefine stop() and use a try/finally strategy. An example is
shown in Listing 4.3.

Listing 4.3 Using try/finally to defeat ThreadDeath.

public void run() {

try { //do somthing interesting here
}
catch(ThreadDeath td){System.out.println("Can't touch this!");}
// Return from the dead
finally{
Thread.reborn = new Thread(, "new");
reborn.start();
}
}

The idea is to catch any exceptions that might be sent to an applet thread to try to kill it (for
example, a ThreadDeath exception, which is what is thrown when Thread.stop() is called). These
exceptions are caught in the body of the block. In the finally block, a malicious applet can include
code to resurrect itself in case of a problem.

Note that the same sort of thing can be done using an applet's finalize() method, which gets invoked
during garbage collection.

This technique counters all attempts to kill a thread and can be used to defeat a majority of
commercial Java security packages that claim to be able to kill hostile applets. Stopping an applet
that does not want to be stopped is a nontrivial undertaking. One approach might be to hook deeply
into the Java runtime and terminate an actual OS thread, but this is problematic since it would
sometimes destabilize the entire browser.

Since stopping applets is difficult, making monitoring applets is easy.

 The Business Assassin Applet

One such monitoring applet (possibly an armchair exercise) is called the Business Assassin applet
[Dean, et al., 1996; LaDue, 1996]. The Business Assassin targets the applets of a particular Web
site, such as applets from Gamelan.

If you place this applet on your homepage, it will start up threads on the remote machine of anyone
who surfs your site with Java enabled. These threads silently watch for other applets being loaded
from Gamelan. If the monitoring threads detect the user surfing the Gamelan Web site, they begin
the attack. The malicious threads make useless any applets coming in from Gamelan. They kill the
threads of Gamelan applets (something discussed in more detail on page 135). Another feature of
the Business Assassin applet (code disabled by default) goes on to launch a denial-of-service attack
against anyone who visits Gamelan after running the Assassin.

On the surface, the Business Assassin applet appears to be harmless; that is because it uses threads
to do all the dirty work. Threads are not required to stop running when an applet's Web page is
exited. This means that threads can keep running in the browser after an applet has appeared to
finish. In order to have the blame pinned on some other applet, hostile threads can be programmed
to delay their attack until some future time. In the case of the Assassin's threads, an apparent
problem in the Security Manager (only addressed recently by Java 2) allows the Assassin threads to
attack thread groups that belong to applets other than their own. It waits for the target threads from
Gamelan to appear and only then initiates hostile activity.

Applets like the Business Assassin will certainly have a chilling effect on Web-based commerce.
Even if applets that use never-ending threads are not used for annoying things like these, they still
have the potential to be used for information gathering. If an applet can spawn a monitoring thread,
there is no reason that it could not report information it finds interesting back to its server. Such
information could include lists of sites a user has visited, files that he or she has downloaded, the
names of other competing applets run, or a host of other things. Such monitoring applets should be
named BigBrother.

CHAPTER SECTION:3

Section 3 -- Denial of Service

In a cracker's world, the next-best thing to breaking in to your computer is locking you out of it.
After all, if the cracker cannot use your computer, then neither should you! Attacks that prevent
someone from using his or her machine are called denial-of-service attacks in the security
community. Denial of service comes in many guises. Attacks may involve consuming all available
CPU cycles, allocating every last bit of memory, hogging all possible screen space, or causing a
system to hang while it waits for something impossible to happen. The one common requirement is
that the user being attacked is effectively locked out of his or her machine. An effective denial-of-
service attack happens so quickly that it's usually impossible to stop it. Experiencing such an attack
is a sobering event.

There are many ways to write applets initiating denial-of-service attacks. We think these attacks are
serious enough that code for them is not listed here. Examining some attacks through high-level
description and occasional code fragments should be enough to illustrate a point. Realistically, the
sorts of malicious applets being described are not too difficult to dream up. People who are
interested will be able to either create the code or find it, as they see fit.

Consider the denial-of-service attack presented in Listing 4.4. It recycles an idea from the
NoisyApplet making use of nonterminating threads. Quite simple to formulate, it looks something
like this:

1. Create an applet that starts a thread with its priority set to MAX_PRIORITY. This makes the
thread run as quickly as possible and gives it a leg up in the ongoing competition between
threads for CPU time.
2. Redefine the stop() method to null for the thread.
3. Do something silly in the main part of the applet so that it appears to be harmless. Show a
picture or display some cute animation.
4. Have the thread sleep for a while to delay its malicious activities. Such sleight of hand will
have the effect of placing the blame somewhere else when the thread wakes back up to
perform its dirty work.
5. When the thread wakes up, have it begin calculating in an infinite loop (or some other CPU-
intensive activity that eats cycles). Such a computation will, in effect, bring the browser
down by taking away all available computational resources. One particularly worthy
function for intense calculation overload is the Ackerman function shown in Listing 4.4.
Listing 4.4 The Ackerman function implemented as a Java application.
Ackerman takes integer n and exponentiates n by itself n times. This means that Ackerman(3) is equivalent to three cubed, cubed. The program can be run by
typing the command java Ackerman n, where n is an integer. Computing anything greater than Ackerman(3) takes a long time and many CPU cycles. This code
was written to be as inefficient as possible. This version of Ackerman could easily be used in a denial-of-service attack.
import java.lang.System;
import java.io.IOException;
import java.lang.Math;

class Ackerman {
public static void main(String[] args) {
long ackValue = 1;
long exp = 0;

if (args.length >= 1) {
try { exp = Integer.parseInt(args[0]); }
catch (NumberFormatException e) { exp = 0; }
}

if (exp > 1) {
ackValue = exp;
int numLoops = (int)exp;
for (int i = 1; i < numLoops; i++) {
exp = ackValue;
for (int j = 1; j < numLoops; j++) {
ackValue = ackValue * exp;
System.out.println("current value is " + ackValue);
}
 }
System.out.println("Ackerman vlue: " + ackValue);
}
}

This denial-of-service approach is simple and elegant. There are literally hundreds of things that
can be done in Step 5. Other possibilities include endlessly appending to a StringBuffer and using
drawString to display its entire contents. This ends up as a double whammy, eating both CPU
cycles and memory. Another possibility would be calculating p using the most inefficient algorithm
possible. If you have trouble remembering how to code poorly, just teach an introductory
programming course to jog your memory.

On a more serious note, this line of attack is both very simple and very successful. Most browsers
seize up and die under such an attack.

Applets that implement these strategies exist on the Web now. Skeptical readers are welcome to
surf over and kill their browsers personally (www.rstcorp.com/hostile-applets/). Just surf to a Web
page containing hostile applets using a Java-enabled browser, and they will automatically be
invoked. Short of creating and enforcing a mobile code policy based on code-signing, nothing can
be done to prevent them. Chapter 6 examines some strategies for protection, but they are all still in
early development. Just to complicate matters, such a hostile applet can implicate other Web pages
by using delay tactics discussed previously.

Is Denial of Service All That Bad?

There is no doubt that denial-of-service attacks are less serious than security breaches of the sort we
discuss in Chapter 5. Although a browser might be crashed with such attacks, intruders do not gain
entry into a system. This has led some people at JavaSoft to dismiss this class of attacks as
unimportant. Before Arthur van Hoff (one of the original designers of Java) left JavaSoft for
Marimba, he posted a note to comp.lang.java that dismissed such problems as either not very
serious or a concern for browser vendors-not JavaSoft. Although the most serious security
problems should be addressed first, denial-of-service applets should also be addressed. Using
resource allocation limitations-for example, placing upper limits on CPU usage, number of
instructions that can run, or number of windows allowed-is one line of defense. Threads should not
be able to override the stop() method so easily, either. (The ability to override stop, or not, is now
enforced by policy.)

It is ironic that some of the most Java-heavy Web pages almost go as far as denial of service in
doing what their programmers intended. Some Java-enhanced sites take quite a while to load (we
have heard of some applets that take 10 minutes to start up, even over a very fast T1 connection).
The bottleneck likely involves the byte code Verification process and not the network transmission
time. Of course, slow loading/verifying really doesn't constitute a true denial-of-service attack.

Even a denial-of-service attack that is no big deal when embedded in an applet becomes a serious
problem if it can be launched against a Web server. Sites that use Java-enabled Web servers and
configure those servers to allow anyone to upload a servlet are exposing themselves to easy denial-
of-service attacks. In short, anyone, anywhere in the world, can bring down such a server whenever
he or she feels like it. That's why we recommend that Java-enabled servers only accept servlets
from clients that they really trust.

CHAPTER SECTION:4

Section 4 -- Opening Untrusted Windows

A more serious denial-of-service attack than browser-killers involves opening large numbers of
very large windows. There are a couple of reasons why this kind of attack should be considered
more severe. The side effects of this attack tend to freeze access to the keyboard and mouse while
the applet runs. This makes the applet harder to control. Also, the way these windows are created
and mapped makes it possible to pop up untrusted Java applet windows without the mandatory
warning they are supposedly required to display.

A denial-of-service applet based on this idea would be very similar to the ones we discussed
on page 128, with the addition of the window-popping code shown here:

// In the code below, littleWindow is of type Frame

// Adapted from an idea by Mark LaDue
try {
// create a window
littleWindow = new bigFrame("Whocares");
// make it very big
littleWindow.resize(1000000, 1000000);
// position it to cover everything
littleWindow.move(-1000, -1000);
// finally, open the window
littleWindow.show();
}
catch (OutOfMemoryError o) {
repaint();
}
class bigFrame extends Frame { // constructor method
Label 1;
bigFrame(String title) {
super(title);
setLayout(new GridLayout(1, 1));
Canvas whiteCanvas = new Canvas();
whiteCanvas.setBackground(Color.white);
add(whiteCanvas);
}
}

This code opens a very large (1-million x 1-million pixel) white window without the supposedly
mandatory untrusted Java applet window message. Put this code in a loop so many windows pile on
top of each other, and voilá, an applet that consumes major resources in an interesting new way.
The act of generating many windows all at the same time causes many window events to fill the
window manager's event queue. This effectively disables the mouse and keyboard, since they talk
to the machine through window events themselves. The console of the workstation displaying these
very large windows freezes up. There are two things users can do when an attack like this is leveled
against them: Go to another machine on the same network to kill the offending browser processes,
or reboot (usually with the three-fingered salute).

The ability to open a window without the mandatory untrusted window banner is interesting in its
own right. Using variants of such code, it is possible to spoof Web site password panels. This leads
to interesting social engineering attacks, wherein an unsuspecting user is asked to provide his or her
password due to a spurious security alert event. Many users fall for such schemes. After collecting
login and password information, a malicious applet can mail off the information to a collection site
for later use by a cracker.

Spoofing Web site password panels is an interesting illustration of how an attacker can whip up a
serious attack out of a set of holes that each look fairly innocuous. An adversary could create an
applet that appears to stop when the user leaves its page, but really keeps a thread lurking in the
browser. That thread could use monitoring techniques to determine when the user has visited a
particular target site. It could then display a spoof of the target site's log-in panel. The user would
probably be fooled, since the bogus log-in panel would appear at the "right" time.

Applets that use a social engineering attack to collect possibly sensitive information can be found at
the DigiCrime Web site. Surf there at your own risk.

CHAPTER SECTION:5

Section 5 -- Stealing Cycles

Theoretical computer science teaches that some computational problems are much more difficult
than others. Very hard problems scale exponentially. Other problems are solvable in Polynomial
time, but only using an oracle that can correctly decide which path to follow each time a choice is
encountered. The second set of problems is termed NP. One of the most perplexing problems in
computer science was introduced in 1977 by three cryptography researchers named Rivest, Shamir,
and Adelman. They invented a sophisticated encryption algorithm called RSA, (after their initials).
The only known Achilles Heel of the RSA cryptosystem rests on the ability (or rather, inability) to
factor a very large integer into a product of prime numbers in a reasonable length of time. The
exact complexity of prime factoring is not known, but it is expected to be difficult and has proven
to be so thus far.

One particular instance of the RSA problem involves factoring a specific 129-digit number into its
prime factors. Using theoretical computer science as a guide, Rivest, Shamir, and Adelman
estimated that it would take 4 x 1016 years to factor RSA-129. However, applying the quadratic
sieve algorithm along with the collaboration of thousands of volunteers (who donated CPU time on
their workstations), researchers solved RSA-129 in 1994 after less than a year of work. The key to
the solution was using thousands of computers at the same time to attack the factoring problem. To
prove that they had discovered the proper solution, the distributed-factoring researchers used their
solution to break a secret coded message that Rivest, Shamir, and Adelman had created in 1977 as a
test. The message read, "The magic words are squeamish ossifrage."

Java offers a unique opportunity for use in cooperative projects such as factoring RSA-129. Some
of the researchers involved in factoring RSA-129 recently announced they had also factored RSA-
130-in a fraction of the time. Java would make cooperative efforts much easier through platform
independence.

So what does this have to do with malicious applets? One critical feature of the RSA efforts was the
voluntary participation. That is what made them cooperative efforts. The same sort of factoring
could be accomplished using a malicious applet. Such an applet would surreptitiously steal CPU
cycles from the machine of any Web user who hit its Web page. The applet would spin a thread on
the remote machine to run part of a factoring solution on that machine's CPU. After a sufficient
amount of work, a partial solution could be mailed back to a collection site for collation with
similar results from elsewhere.

There is no reason a CPU-cycle-stealing applet needs to work on factoring. It can perform any
work. Using such an applet, a Web miscreant could instantly upgrade his or her 486-DX2/66 into a
huge collective machine with the combined power of hundreds of workstations. Workstations
around the world could be automatically pressed into service. Imagine the dismay of a CEO who
discovers that her new Whiz-bang 4200+ has been helping compute results for a competitor. Or
imagine the legal ramifications in store for the owner of a government machine that inadvertently
helps a foreign national break an encryption algorithm. Or imagine a computer hardware
manufacturer who specs out a competitor's machine using a stealthy benchmark applet. The
possibilities are many.

CHAPTER SECTION:6

Section 6 -- Forging Mail

Many Net-savvy people are aware of a simple trick that allows users to forge electronic mail. This
is accomplished by talking directly to the SMTP daemon on port 25 of a server machine. The mail-
forging attack takes advantage of the fact that mail-serving hosts monitor port 25 for incoming
Simple Mail Transfer Protocol (SMTP) messages.

One of the Internet rites of passage is to telnet to port 25 and send fake mail to a friend. This game
is very well known; however, the scheme is easily debunked. The SMTP daemon actually marks
the forged mail with the IP number of the machine that connected to port 25, which makes it very
easy to discern which machine sent the mail.3 Spammers often forge mail headers so that the true
source of a spam message is hard to discern.
It is usually easy to detect forged mail by looking carefully at the header. The machine listed in the
From line should be the same as the Received: line. Most users and mail readers look only at the
From line; systems people know to look at both. Note that some legitimate mail may have differing
From and Received: lines, depending on how people send their mail. Here is an example of mail
forged by an author on his home machine (tigger.mediasoft.net) to his own work account. Note
how the From and Received: lines differ.

From god@heaven.com Wed Jul 24 19:33:56 1996

Return-Path: <god@heaven.com>
Received: from tigger.mediasoft.net by rstcorp.com (4.1/SMI-4.1)
id AA21199; Wed, 24 Jul 96 19:33:54 EDT
Received: from rstcorp.com (gem@tigger.mediasoft.net[205.139.200.246])
by tigger.mediasoft.net (8.6.12/8.6.9) with SMTP id SAA00966
for gem@rstcorp.com; Wed, 24 Jul 1996 18:30:31 -0400
Date: Wed, 24 Jul 1996 18:30:31 -0400
From: god@heaven.com
Message-Id: <199607242230.SAA00966@tigger.mediasoft.net>
Apparently-To: gem@rstcorp.com
Status: RO

This is forged mail.

Applets provide an interesting new twist on the standard approach to mail forging. Because applets
load across the network and run on a Web surfer's machine, a mail forging applet can cause the
standard SMTP daemon monitoring port 25 to report mail coming from the Web surfer's machine-
not the machine serving the applet. This can be leveraged to doubly forge mail. Imagine that Alice
hits a Web page and an applet is consequently run on her machine. By using Alice's machine to
forge mail from Alice-that is, to forge mail apparently both from her machine and from her account
on that machine-the doubly forged mail appears not to have been forged at all! With many standard
server configurations, this forging attack is possible. Figure 4.4 illustrates the difference between
the standard port 25 attack and the revised applet attack.

Figure 4.4 The usual mail-forging approach versus the applet-based

sendmail approach.

Because an applet runs on another host, it is possible to doubly forge mail so the
 resulting message does not appear to be forged.

Forged mail of this sort can be sent to any email address that the applet's author chooses. The
message could, of course, be anything at all. To make this more concrete, imagine an applet that
sends an email death threat to the president of the United States (a felony) from the account and
machine of anyone naïve enough to browse a malicious Web page with Java enabled. Or, imagine
an applet that uses mail to spam hundreds of Usenet newsgroups with a fake legal advertisement
apparently posted from the victim's machine and account, immediately spawning a mail bomb
attack against the applet's victim from angry Usenet users bent on retaliation. There are many
variations on this theme.

Using threads, it is possible to forge mail in the background while doing something seemingly
innocuous in the foreground. This forging activity is currently possible; in fact, there are multiple
examples to be found on the Web. The possibly surprising fact is that the attack we have described
is completely within the security bounds of what SMTP and Java are allowed to do. Forging mail
like this is neither particularly sophisticated nor hard to implement. On the other hand, the havoc
that could be wreaked with a malicious applet of this sort is serious.

CHAPTER SECTION:7

Section 7 -- Killing Off the Competition

The Business Assassin applet discussed earlier combines two dirty tricks. The first trick is to spawn
a monitoring thread to watch for applets from another site. The second trick is to kill the threads of
any incoming applets. According to the rules, an applet should not be allowed to kill the threads of
other applets. Unfortunately, what should not be allowed to happen and what actually can happen
are not always the same. Implementation bugs in the security check for thread access for all JDKs
through 1.1.5 allow downloaded applets to access threads outside their own thread group. Killing a
thread is easy. Here is a code fragment that does it:

private static void ThreadMurder(Thread t){

t.stop();
}

You may wonder why the t.stop() method is inside the ThreadMurder() method. This code will kill
any thread t. It would be wise for the thread calling ThreadMurder() not to kill itself. A test inside
ThreadMurder() is an obvious way to protect the calling thread. All that is needed is a simple name
check. If the thread turns out to be checking itself, a decision is made to do nothing.
To make an applet that kills all threads not belonging to itself requires a bit more work. For clarity,
let's call this applet AssassinApplet. A recursive approach to AssassinApplet is probably best. The
basic outline is:

1. Starting with the current thread group, ascend to the root thread group.
2. From the root, recursively descend through all threads and thread groups below.
3. Kill each thread encountered (but not self).

This approach is both very nasty and very effective.

If coded as just shown, an AssassinApplet would be able to kill all other applets running when it
starts (a nice way to shut the NoisyApplet up!). It would also kill all applets that it comes across
after that. Since it is possible within our framework for the applet to name who should not be killed,
the AssassinApplet could run in tandem with other chosen applets. In fact, using the
AssassinApplet at all times is a half-baked alternative to turning Java off! Just run the
AssassinApplet once at the beginning of a session and after that, all applets encountered from then
on are guaranteed to be killed soon after arrival.

The good news is that we can defeat the ThreadMurder attack shown here using the try/finally
approach discussed earlier. The bad news is any hostile applet can, too.

CHAPTER SECTION:8

Section 8 -- Malicious Applets on the Web

The most extensive collection of malicious applets can be found on Mark LaDue's Hostile Applets
Home Page. LaDue does not follow our naming convention, which separates attack applets from
malicious applets. But in any case, all of the applets that LaDue has created are malicious applets.
In July 1998, a group of LaDue's newer malicious applets, those that allow creation of a
ClassLoader in Netscape 4.04 and 4.05, were leveraged to create an attack applet. LaDue's
ClassLoader subclassing when combined with the discovery of a ClassLoader bug by the Princeton
team (see Chapter 5) made possible a real attack.

LaDue's malicious applets perform the following hostile activities:

• Play a sound file forever (our NoisyApplet is adapted from this one).
• Kill a browser with a CPU-hogging attack.
• Consume all available memory on your machine.
• Spin endless threads to consume resources.
• Display many hundreds of large black windows.
• Combine many denial-of-service attacks (windows, threads, and sounds) into one payload.
• Pop a fake dialog box requesting sensitive information (username and password).
• Surreptitiously perform remote calculation and report results back to the server.
• Forge mail.
 • Kill all applet threads (except for self).
• Send your browser to a URL over and over again.
• Obtain your username.
• Fill all disk space available to the browser.
• Create an AppletClassLoader (a good staging ground for more serious attacks).
• Exercise mystery methods (undocumented but available) that crash a browser.
• Misuse native methods through the Java API, resulting in a crash.
• Deny legitimate use of the audio system by retaining control over it.
• Steal information about the SystemPrincipal and create an impostor.
• Determine exactly which plugins a browser has with help from JavaScript.
• Steal information from a Java Wallet (including username and password).
• Carry out some social engineering in order to rewire the Help button of the Java Wallet.
• Cause a modem connected to an arbitrary serial port to dial.

The most interesting feature of LaDue's malicious applets is that source code is made available.
LaDue is clearly no proponent of keeping secrets!

No other author of malicious applets has been as prolific as LaDue, but notable among available
malicious applets are:

• An extremely simple recursive applet that pops the stack and crashes the VM (Naval
Postgraduate School)
• A mail forger and a file scanner written by Jim Buzbee
• An applet that abuses the redirect capability written by Ben Messander

Links to known malicious applets on the Web are maintained on the Java Security Hotlist.

CHAPTER SECTION:9

Section 9 -- The Implications

Unlike the technically adept attacks to be revealed in Chapter 5, these malicious applets are very
easy to write. There are malicious applets that play background sounds endlessly. There are
malicious applets that consume system resources, implementing denial-of-service attacks. There are
applets that forge electronic mail. There are even applets that kill other applets' threads.

Now that techniques are widely available on the Hostile Applets Home Page (among other places),
it is only a matter of time before malicious applets spread. Because malicious applet source code
has been put on the Web, hundreds of people can start to use and adapt the ideas. We have been
lucky that this has not happened yet. Perhaps we will continue to be lucky, or perhaps not.

As we have seen, an applet need not break into your machine in order to do malicious things.
Sometimes it is good enough to steal CPU cycles, or deny access to other sites. Malicious applets
come in all shapes and sizes. Defending against all of the possibilities is at best a daunting task.
Malicious applets may even play a role in undermining business on the Net. Recall the Business
Assassin applet that targets Gamelan. Other anti-business applets might send forged mail with
thousands of seemingly legitimate orders (resulting in thousands of expensive returns). Another
malicious applet could spam the Net with ads supposedly from you, should you be from the site of
a competitor. This could effectively cut your business off the Net when people respond with mail
bombs. It does not take too much foresight to fear the implications that these applets have for Net
commerce.

At least for the moment, malicious applets are not widespread; however, it is only a matter of time
before they are. Now is the time to look into ways to defend ourselves against them. Sun
Microsystems agrees: "We recognize the importance of providing people with some mechanism to
help them deal with hostile applets." Java 2 introduces mechanisms that can be used to help address
the problem.

Attack Applets:
Exploiting Holes in the Security
Model
There is a tightrope to walk in this chapter. You should understand the problems encountered with
Java, so you know how things can go wrong, especially if you are charged with designing security-
critical systems, administering a large number of Java users, or making business decisions that
depend on Java security issues. But it is not the intent of this book to give the bad guys a manual
for invading your computer. Although we discuss Java security problems, we hope you forgive the
omission of details necessary to exploit these problems.

Just for the record, we do not believe in security by obscurity. If we did, we would not have written
this book at all. However, we don't believe in publishing exploit scripts and aiding and abetting
attacks by inexperienced would-be crackers, either. Serious Java attacks have yet to escape the lab,
and we want to do our part to keep it that way.

In the early days of Java, Sun Microsystems and the rest of the Java industry hyped Java as
completely secure [Sun Microsystems, 1995]. This was really no surprise. They still have a lot to
gain if you believe them and jump aboard the Java bandwagon without even considering the risks
of doing so. It's true that Sun Microsystems, Netscape, Microsoft, and others have gone to great
lengths to make their Java implementations as secure as possible. That's all well and good, but you
don't want effort-you want results. To this day, the question remains: Is Java safe enough to use?
This chapter examines all of the serious security flaws that have been found in Java so far. By
serious, we mean attacks based on these flaws could go beyond the annoyance or denial-of-service
attacks of Chapter 4, "Malicious Applets: Avoiding a Common Nuisance." These attacks could
corrupt data on your hard disk, reveal your private data to third parties, turn your machine into a
hostile listening post, or infect your machine with a virus. By exploiting some of the vulnerabilities
discussed here, a cracker could attain the ultimate cracker goal-complete control of your machine.

Java vendors are very quick to fix any problems that are discovered in Java. In fact, vendor
response to the discovery of a new Java security hole far surpasses the usual response to non-Java-
related security problems posted to Bugtraq and other mailing lists run by security professionals
(Bugtraq archives are available at www.geek-girl.com/bugtraq/). In terms of Java, the penetrate-
and-patch machine is smoothly oiled (not that it represents the best approach to security, but that's
another issue). Rest assured that the problems we discuss in this chapter have been fixed in the
latest JVMs, including those packaged in Java-enabled browsers. That means if you're using an up-
to-date version of your favorite browser, these specific problems won't affect you. On the flip side,
if you're using an older browser like Netscape 2.x/3.x or Internet Explorer 3.x, this chapter provides
enough information about serious attacks that you really should upgrade immediately. Browsers are
not patched; they are made obsolete through accelerated release of new versions. Using an old
browser to surf the Web is like wearing a "kick me" sign to a fraternity party.

Though these specific attacks are not likely to be your problem since they have been fixed, they
indicate what sorts of things can go wrong and what the consequences are when things do go
wrong. If more Java security problems are found in the future, they're likely to be similar to the
ones presented here. Hopefully the industry can learn from its old mistakes and avoid reintroducing
old holes (as often happens in computer security).

Most of these problems were trivial to fix once they were discovered. Removing security bugs is
like removing needles from a haystack: It's hard to find the needles, but they're easy to remove once
you know where they are. To push the analogy a bit: It's obviously much better to find the needles
before they stick you. This principle motivates our Java security research.

Chapter Five Sections

1. Implementation Errors or Specification Errors?
2. Attack Applets
3. What Applets Aren't Supposed to Do
4. A Chronology of Problems
5. Jumping the Firewall
6. Slash and Burn
7. You're Not My Type
8. Applets Running Wild
9. Casting Caution to the Wind
10. Tag-Team Applets
11. Big Attacks Come in Small Packages
12. Steal This IP Number
13. Cache Cramming
14. Virtual Voodoo
 15. The Magic Coat
16. Verifying the Verifier
17. The Vacuum Bug
18. Look Over There
19. Beat the System
20. What These Problems Teach Us

Attack Applets: Exploiting Holes in the Security Model

CHAPTER SECTION:1

Section 1 -- Implementation Errors or Specification

Errors?

One question we are commonly asked is whether Java's security woes are due to simple bugs or
reflect deeper design problems. The answer is a bit complicated, as we shall see.

Software Engineering Meets Internet Time

Software that is properly engineered goes through a standard process from requirements design,
through detailed specification, to actual implementation. In the world of consumerware (software
created for the mass consumer market, like browsers and JDKs), pressure to be first to market and
retain what is known as "mind share" compresses the development process so much that software
engineering methods are often thrown out the window. This is especially true of testing, which
regularly ends up with no scheduled time and few resources. An all too common approach is to
leave rigorous testing to users in the field (sometimes even paying users when they find bugs!). We
think this is just awful.
The Internet time phenomenon has exacerbated the software engineering problem. These days,
Internet years rival dog years in shortness of duration (the standard ratio is seven dog years to one
regular year). So three months of regular time are currently equivalent to a complete Internet
"year." Given the compressed development schedules that go along with this accelerated kind of
calendar, the fact that specifications are often very poorly written (if they exist at all) is not
surprising. The authors commonly encounter popular consumer-oriented systems that have no
specifications. Java suffered from this problem in its early years as well. Fortunately, Java does
have an informal specification today. That's always a good start.

One of the most common misconceptions about Java security holes is that they are all simple
implementation errors and that the specification has been sound and complete since day one.
Threads in the newsgroup comp.lang.java.security and other newsgroups often repeat this fallacy as
people attempt to trivialize Java's security holes. The truth is that many of the holes described in
this chapter are simple implementation bugs (the code-signing hole from April 1997 comes to
mind-see The Magic Coat later in the chapter), but others, like problems discovered in Java class
loaders, are not. Sometimes the specification is just plain wrong and must be changed. As an
example, consider how the Java specification for class loading has evolved.

Often it is hard to determine whether a security hole is an implementation problem or a

specification problem. Specifications are notoriously vague. Given a vague specification, who is to
blame when a poor implementation decision is made? Specifications are also very often silent; that
is, when a hole is discovered and the specification is consulted, there is nothing said about the
specific problem area. These sorts of omissions certainly lead to security problems, but are the
resulting problems specification problems or implementation problems?

In the end, the holes are fixed, regardless of whether they are implementation bugs or design-level
problems. This leads to a more robust system. If Java stood still long enough, you would think all
the holes would be discovered and fixed. But Java is far from still. With every major JDK release,
the Java source code has doubled in size. Much new functionality has been added to the language,
some of which has important security implications. The addition of flexible access control in Java 2
is a case in point. Implementing a code-signing and access-control system is nontrivial, and the
code is certainly security-critical. Other examples are serialization and remote method invocation
(RMI). Subtle security problems are likely to be discovered in these and other new Java
subsystems.

Discovering Holes

Why is it that all the known attack applets covered in this chapter were discovered by good guys
and not bad guys? The quick but unsettling answer is: pure luck. The Princeton team and other Java
security researchers are not the smartest people in the world (sorry guys), and the holes uncovered
in Java so far do not require years of advanced training to find. There is no reason that malicious
crackers could not discover such holes for themselves. The Java industry has been fortunate that the
people who usually discover Java security problems are honest and want to see Java improved so
that it is safer to use. Also fortunate is the punctuality and accuracy of typical vendor response.
So how are holes usually discovered? Most often, the scenario goes something like this.
Researchers discuss where potential flaws may lie by thinking about what is difficult to implement
properly. Occasionally, researchers notice peculiar or surprising behavior in their work with Java
and get an idea about what to investigate. The next step is to take a close look at the Java source
code (for the VM and API classes) or the binary code if no source code is available. Sometimes,
errors are obvious and exploits are easy. Other times, experimentation is required to turn a potential
flaw into a real exploit. All of the holes described in this chapter can be exploited using attack
applets. That means the holes covered here are not esoteric flaws that are impossible to exploit.
They are sometimes-subtle flaws that have been turned into full-fledged attacks.

Holes and Exploits

Every Java hole described in this chapter has an accompanying exploit. Another way of putting this
is that there is an attack applet (the Java form of an exploit script) for each hole discussed here.
However, the one-to-one correlation found in this chapter does not imply that it is necessary for
every security hole to have an exploit. Holes are just vulnerabilities. Sometimes a hole will be
recognized as a hole but cannot be exploited by itself. In these cases, multiple holes together create
an exploit.

Think of attacking a system as climbing up a cliff. When you reach the top, you have successfully
completed an attack. A security hole can be likened to a piton in the cliff with a piece of rope
attached. Sometimes one piton is enough to help a climber make it to the top (especially if the
climber is an experienced veteran). Other times, more than one piton may be needed. The holes
discussed in this chapter have exploits of both categories. A majority of the attack applets require
only one hole, but sometimes an attacker must leverage other weaknesses to exploit a hole. (A
perfect example of the latter category is the Beat the System hole of July 1998.)

CHAPTER SECTION:2

Section 2 -- Attack Applets

It is important to reemphasize that the attacks described in this chapter are not hypothetical; each
has been implemented by either the Secure Internet Programming team (SIP) at Princeton
University or other researchers. Each was successfully used to break into a machine in the
laboratory. The Princeton team, who have discovered a majority of known holes, choose not to
release the resulting attack applets onto the Net. Other researchers, especially consultants, tend to
release their attacks.

Attack applets are the most dangerous kind of hostile applets. They do more than simply annoy or
deny service. The end result of an attack applet is the same as being hacked by a cracker: Your
system is wide open for unauthorized access.
According to both our research and that of the CERT Coordination Center (an organization that
keeps track of computer security violations on the Internet), there have been no confirmed reports
of loss due to the attacks described in this chapter. There are, however, a few cases of attacks
possibly carried out with applets. It is, of course, impossible to rule out the possibility of attacks
that haven't been discovered or that haven't been reported. The lack of reports indicates that the
number of attacks, if any, has been small. Successfully implemented attack applets probably
haven't occurred in the wild, but there can be no guarantee that one won't show up tomorrow. The
danger is real enough that CERT recommends people disable Java when using particular versions
of popular browsers [CERT, 1996a; CERT, 1996b].

CHAPTER SECTION:3

Section 3 -- What Applets Aren't Supposed to Do

Chapter 2, "The Base Java Security Model: The Original Applet Sandbox," and Chapter 3, "Beyond
the Sandbox: Signed Code and Java 2," discussed the Java security model at length. Java's
designers tried to ensure that untrusted or partially trusted applets could not misbehave by placing
them in an adjustable sandbox. For a concise listing of things that untrusted Java applets should not
be allowed to do, see Chapter 2. It is also worth reading the "Frequently Asked Questions-Java
Security'' Web page served by Sun Microsystems at java.javasoft.com/sfaq. In order to provide
concrete examples of Java security policies that work, Sun's Security FAQ page includes pointers
to a number of applets that cannot get around Java security. The good news is that some
straightforward approaches to breaching security will fail. The bad news is that crackers usually
don't give up after the straightforward approach fails. Fortunately, neither do security researchers.

It is always interesting to get an objective outsider's opinion about Java security. That is probably
one of the reasons you are reading this book.Appendix A, "Frequently Asked Questions: Java
Security, Java versus ActiveX," includes a hard copy of two of the Princeton Secure Internet
Programming team's Java Security FAQs. An up-to-the-minute version of the FAQs can be found
at www.cs.princeton.edu/sip/java-faq.html.

CHAPTER SECTION:4

Section 4 -- A Chronology of Problems

To date, 16 serious security problems have been discovered in implementations of Java. Table 5.1
lists the holes and their accompanying exploits by name. A brief chronology follows that describes
each flaw. These flaws will be discussed in more detail later in this chapter. Some of these flaws
allow full system penetration. This means that an attacker could exploit them to do literally
anything to your machine, including corrupting your data, reading your private data, injecting a
virus, or leaving a trapdoor to reenter your machine at will.
 Table 5.1 Attack Applets that Exploit Holes in the System

DATE ATTACK APPLET

February 1996 Jumping the Firewall

March 1996 Slash and Burn

March 1996 Applets Running Wild

May 1996 Casting Caution to the Wind

June 1996 Tag-Team Applets

June 1996 You're Not My Type

July 1996 Casting Caution to the Wind (reprise)

August 1996 Big Attacks Come in Small Packages

February 1997 Steal This IP Number

February 1997 Cache Cramming

March 1997 Virtual Voodoo

April 1997 The Magic Coat

May 1997 Verifying the Verifier

July 1997 The Vacuum Bug

August 1997 Look Over There

July 1998 Beat the System

February 1996: Drew Dean, Edward Felten, and Dan Wallach at Princeton discovered a flaw in
Java's networking software, affecting Netscape Navigator 2.0. This flaw was postulated
independently by Steve Gibbons. It could be exploited to launch security attacks on other machines
on a private network. This flaw was fixed in Netscape Navigator 2.01. The resulting attack is called
Jumping the Firewall. See page 147. This attack resulted in one of the two Java-related CERT alerts
[CERT, 1996a].

March 1996: David Hopwood at Oxford University found a flaw that allows an attack that tricks
Java into treating the attacker's applet as trusted code. This flaw allowed full system penetration. It
affected Netscape Navigator 2.01 and was fixed in Netscape Navigator 2.02. The resulting attack is
called Slash and Burn. See page 153.

March 1996: The Princeton team (Dean, Felten, and Wallach) found a bug in the Java byte code
Verifier and a flaw in the class-loading mechanism. Together, these allowed full system
penetration. This problem affected Netscape Navigator 2.01 and was fixed in Netscape Navigator
2.02. The resulting attack is called Applets Running Wild. See page 158. This attack resulted in the
second of the two Java-related CERT alerts [CERT, 1996b].
May 1996: Independent consultant Tom Cargill, working with the Princeton team (Dirk Balfanz,
Dean, Felten, and Wallach) found a flaw in the implementation of the Java interpreter. This flaw
allowed full system penetration. It affected Netscape Navigator 2.02 and Microsoft Internet
Explorer 3.0beta1, and was fixed in Navigator 3.0beta3 and Explorer 3.0beta2. The resulting attack
is called Casting Caution to the Wind. Seepage 163.

June 1996: Hopwood found another flaw in the interpreter that again allowed full system
penetration. This flaw affected Netscape Navigator 3.0beta3 and was fixed in Navigator 3.0beta4.
The resulting attack is called Tag-Team Applets. See page 165.

June 1996: Balfanz, Dean, and Felten found a flaw in Java's implementation of array types that
allowed full system penetration. This flaw affected Netscape Navigator 3.0beta5 and was fixed in
Navigator 3.0beta6. The resulting attack is called You're Not my Type. See page 156.

July 1996: Cargill, Balfanz, Dean, and Felten found another implementation flaw in the Java
interpreter. This flaw allowed an attacker to mount some attacks on network services on other
private-network machines. This flaw affected Netscape Navigator 3.0beta5 and was fixed in
Navigator 3.0beta6. This attack is also called Casting Caution to the Wind. See page 163.

August 1996: Balfanz and Felten found a flaw in Microsoft's Java implementation. The flaw
allowed code in an attack applet to become a member of a security-critical Java package, thus
gaining the ability to change various security parameters. This in turn gives the applet full access to
the target machine's files and the network. This flaw affected Microsoft Internet Explorer 3.0beta3
and was fixed in Explorer 3.0beta4. The resulting attack is called Big Attacks Come in Small
Packages. See page 167.

February 1997: A pair of British hacker/consultants, Ben Laurie and Major Malfunction,
discovered two separate flaws, one that worked only against Netscape Navigator 3.x and the other
that worked only against Microsoft Internet Explorer 3.x. The Microsoft flaw was much more
serious than the Netscape flaw. The fact that the attacks were browser specific serves to emphasize
that different vendors have different approaches to implementing Java security. To be sure, both
vendors are coding to the same specification, but there are many ways to skin a cat. The two attacks
are called, Steal This IP Number and Cache Cramming, respectively. See pages 169 and 171.

March 1997: Security researchers at JavaSoft discovered a subtle error in the JVM and
immediately patched it. This illustrates how serious JavaSoft is about security. The error was deep
inside the Virtual Machine code and affected all browsers. The attack is called Virtual Voodoo.
Seepage 172.

April 1997: Soon after the release of JDK 1.1, the Princeton team discovered a serious flaw in the
newly implemented code-signing system. The flaw allowed an attack applet to take on maximum
privilege allocated inside a system. Because only the HotJava browser supported JDK 1.1, it was
the only browser affected by the flaw. This attack is called The Magic Coat. See page 172.

May 1997: The Kimera group at the University of Washington, led by Professor Brian Bershad,
created a byte code Verifier of their own using formal methods and strict software engineering
processes. In order to test their implementation, the Kimera group created an automatic test harness
that generated millions of tests by mutation. They then tested their Verifier against commercially
available Verifiers. In the course of testing, they identified 27 errors in various commercial
Verifiers. One error was severe enough to warrant a patch. The others were patched in later releases
of the JDK. This set of attacks is called Verifying the Verifier. See page 174.

July 1997: Sun's response to the Verifier errors in May (which downplayed their severity)
prompted the Kimera group to create an exploit that attacked Netscape Navigator 3.x. The attack
was able to gain access to protected information in the browser's memory space, including private
keys used in setting up secure socket layer (SSL) sessions. This attack is called the Vacuum Bug.
See page 177.

August 1997: Creative Concepts consultant Ben Mesander discovered a weakness in the way
HTTP redirect operations were handled by Java. The weakness was particularly obvious in
Microsoft Internet Explorer 3.x but was also present (in a subtler fashion) in Netscape Navigator
3.x. This attack is called Look Over There. See page 178.

July 1998: Balfanz, Dean, Felten, and Wallach found a security flaw in the ClassLoader
implementation of JDK 1.1 and JDK 1.2beta3 that allows a malicious ClassLoader to override the
definition of built-in "system" types like java.lang.Class. When properly abused, this can lead to a
type confusion attack that completely compromises security. The flaw requires use of a secondary
flaw to gain a foothold. Mark LaDue had earlier discovered such a flaw in Netscape 4.0x's Security
Manager. Thus, Netscape 4.0x is exploitable, while other Java VMs (Sun's and Microsoft's) do not
appear to be exploitable even though they contain the same flaw. This attack is called Beat the
System. See page 182.

The rest of this chapter describes these flaws in more detail.

When Holes Happen

The chronology presented here has an interesting meta-level property. Both in August 1996 and in
August 1997 several months followed in which no major security holes were discovered.
Interestingly, the period of six months in late 1996 was of long enough duration that some Java
evangelists began to claim that all Java holes had been discovered and that Java was completely
secure. They were wrong.

First of all, anyone who claims any program or programming language is completely secure should
be viewed with suspicion. There is no such thing as 100-percent security; the best we can do is
minimize risk. This goes for Java as well as any other computer system. Fortunately, Java mitigates
many risks that competing systems of mobile code like ActiveX and JavaScript do not (see Chapter
1, "Mobile Code and Security: Why Java Security Is Important," for details). This makes Java more
secure than those systems, but it does not make Java perfectly secure. Short of proving Java correct
(which is unlikely ever to happen given the state of formal methods), we must live with potential
security holes.
Second, the pattern in the chronology corresponds with major releases of the JDK. The gap
between August 1996 and February 1997 included the time period when JDK 1.02 was in common
use and JDK 1.1 had not yet been released. As soon as JDK 1.1 was released, some new holes were
discovered. The same sort of gap appeared as Java 2 slowly trickled out. This reflects two facts: 1)
each major release includes much new functionality, and 2) Java is complicated, and complicated
systems always include room for error. From these facts, it is natural to infer that the discovery of
holes will coincide with major releases.

CHAPTER SECTION:5

Section 5 -- Jumping the Firewall

In the first problem, an attack applet launches network security attacks on other machines. This is
something that an attacker could already do before Java came along. The twist is that by embedding
the attack into an applet, the bad guy makes the attack come from the machine of an innocent
bystander. Example: You're sitting at your desk, happily browsing the Web, and without realizing
it, your machine is trying to penetrate the security of a machine down the hall.

This kind of confusion is reason enough to use Java as the penetration vehicle, but the culprit has
an even better reason for using Java. Many corporate networks protect themselves from Internet
intrusion through the use of a firewall. (See Figure 5.1.) If your firewall is well configured, it
prevents the mischievous cracker from making direct use of the network to probe the defenses of
your machines. The firewall does this by blocking certain types of network traffic from entering the
corporate network.

Figure 5.1 A firewall stands between your internal network and the rest of
the Internet.

It screens every packet of data coming across the network, allowing only
certain kinds of packets through. A firewall is only as effective as the policy it
implements.

A Java applet, though, doesn't look suspicious to most firewalls. (This was more true in 1997 than
it is today. We discuss the state of the art in applet blocking in Chapter 6, "Securing Java:
Improvements, Solutions, and Snake Oil.") Many firewalls examine the type of packet, not the
contents of the packet. For some firewalls, to block Java applet traffic, a system manager would
have to block all Web traffic.1 The fact that your browser requested the applet makes the firewall's
job that much trickier. If the applet can open network connections to other machines, it can connect
from your machine to another machine behind the firewall. In the current case, the attack originates
from the inside rather than the outside. Since the firewall only filters traffic coming from the
outside, it is helpless to prevent this sort of attack. This is especially dangerous since many sites
have strong firewall protection, but almost no protection against attacks from the inside. In security
circles, these sites are jokingly referred to as "crunchy on the outside and chewy in the middle."

The people who designed Java-enabled browsers thought of the possibility of inside-the-network
attacks, so they made a security rule to prevent it. The rule states:

An applet may not open a network connection, except back to the server from which it came.
If enforced properly, this rule stops any network probing by applets. Netscape Navigator 2.0 did not
enforce this rule properly. In order to understand what went wrong, you need to understand how
machines are named on the Internet.

Internet Naming

Like people, machines on the Internet need to have names to identify them. Specific names help
machines send messages across a network. These names are also numeric addresses. Because these
numbers are often difficult to remember, there are two layers of network addressing in the Internet.
The Internet Protocol (IP) uses only numeric addresses to communicate between machines. The
Domain Name System (DNS) keeps track of how the user-friendly names correspond to the IP
numbers used to establish a machine's low-level connections.

An IP address is just a number. For example, the Web server at JavaSoft has this numeric address:
11001110000110100011000001100100 in binary notation. IP addresses are often written in
decimal form, which looks like 206.26.48.100. When the computers that make up the Internet talk
to each other, they identify themselves with the numeric IP addresses. Computers deal naturally
with numbers like this, but they are, to say the least, not very user-friendly.

The other sort of Internet names, DNS names, are made for people. They look like java.sun.com, or
sandbox.rstcorp.com. These names are made up of often intelligible words strung together with
dots to separate them. DNS divides the world up into domains like sun.com (Sun Microsystems)
and cs.princeton.edu (the Princeton University Computer Science department). Each domain
corresponds to a single administrative entity. It is up to that entity to define names that end in its
domain name. For example, the cs.princeton.edu domain is free to define names like
elvis.cs.princeton.edu. Anyone can create his or her own domain by registering with an
organization called InterNIC and paying a modest fee.

The owner of each domain is responsible for providing two DNS server machines that respond to
queries about DNS names inside that domain. For example, if someone wants to know the IP
address of elvis.cs.princeton.edu, he or she can ask one of the DNS servers for cs.princeton.edu.

A single DNS name might refer to several IP addresses. There are two reasons for this. First, a
machine might be connected to more than one network, with a separate IP address for each of its
connections. Second, there might be several machines providing the same service. For example,
espn.sportszone.com might actually correspond to several machines, all providing identical
services.

Sometimes several DNS addresses refer to the same IP address. For example, a company's Web
server www.rstcorp.com and its FTP server ftp.rstcorp.com might actually be the same machine.
This makes sense because management might later want to move the two functions onto separate
machines. Using two separate names allows them to keep this flexibility.

What Went Wrong: The Java DNS Security Bug

To enforce the rule that an applet can connect only to the server from which it originated, the
implementers of Java needed a way to check whether the machine an applet wanted to reach was
the same as the machine that the applet came from. They did this as follows:

• Use DNS to translate the name of the Web server into a list of IP addresses.
• Use DNS to translate the name of the machine the applet wants to connect to into a list of IP
addresses.
• Compare the two lists. If any address appears in both lists, declare the two machines are the
same and allow the connection. If not, declare they are different and refuse the connection.

This way of using DNS to authenticate a host is illustrated in Figure 5.2. Though this approach
sounds good at first, it turns out to be too permissive.

Figure 5.2 How Java originally used DNS to make sure that an
applet attached only to the machine that served it.

The problem is that the check is too lenient.

The following scenario describes what can go wrong. Figure 5.3 shows the scenario visually.
 Figure 5.3 How the DNS security bug allows an applet to jump a site's
firewall.

The figure shows several different snapshots arranged in order of occurrence.

Imagine that a bad guy wants to attack a machine called target.victim.org, with the IP address
10.10.10.2. The bad guy sets up a Web server calledwww.attacker.org, with IP address
172.16.16.16; then he waits. An unsuspecting person, surfing the Web on stooge.victim.org (IP
address 10.10.10.1), happens to visit the attacker's Web site. The site contains a Java applet written
by the attacker. The applet is downloaded to stooge.victim.org and run.

The applet asks to create a network connection to bogus.attacker.org. Because that name is in the
attacker.org domain, the attacker's DNS server is asked to provide an IP address for that machine
and is free to provide any IP addresses it likes. The attacker's DNS server slyly returns the pair of
addresses (10.10.10.2, 172.16.16.16). Because that list contains the address of the attacker's Web
server (172.16.16.16), Java erroneously concludes that www.attacker.org and bogus.attacker.org
are really the same machine, so it allows the connection to go ahead.

Unfortunately, after verifying the connection is allowed, Java connects to the first address on the
list, 10.10.10.2, or target.victim.org. The attacker has achieved his goal: to connect to the target
machine.
What does the attacker do next? The attacker can systematically probe the defenses of the target
machine, looking for weaknesses. Sophisticated tools such as SATAN, Ballista, and ISS even exist
to automate this part. If the attacker finds a weakness, the victim could be in big trouble.

The Fix

This problem was fixed by simply changing the criterion by which Java decides to allow a
connection. The new approach is to store the IP address of the Web server, and allow a connection
only to that IP address. This simple and complete solution is implemented in Netscape Navigator
versions beginning with 2.01 and all Java-enabled Microsoft Internet Explorer versions. It is no
longer possible to jump the firewall with Java using the DNS bug; however, it is important to make
sure that you are not using the unpatched Netscape 2.0.

The Reaction

The announcement of this flaw triggered a flurry of press reports, beginning with a story in USA
Today. Reporters learned of the flaw from a brief message in the comp.risks forum. The
discoverers of the attack were surprised to learn that many reporters monitor comp.risks.

It turned out that the existence of this flaw had been postulated independently by Steve Gibbons
about four weeks before the announcement. Steve Gibbons had reported the bug to Sun
Microsystems, but it was not fixed. After the USA Today article, Sun Microsystems and Netscape
said they would fix the bug within days. It was fixed quite quickly.

The security researchers who uncovered the DNS attack were surprised to see that the press treated
the news as a business story rather than as a technical story. This was probably a naïve point of
view. These days, technology reporting, even when discussing noncommercial technology, seems
to be considered a branch of business reporting.

It was also surprising to see that many news organizations repeated a story that they had read
elsewhere without contacting the parties involved and apparently without reconfirming any of the
facts! As usual, when information is heard and then repeated, small inaccuracies creep in at each
stage. It was sometimes possible to figure out who had copied the story from whom, by tracking
small inconsistencies.

The USA Today story also triggered a blip in the stock market. Netscape's stock price dropped
significantly on the day the story appeared. CNN and the Nightly Business Report attributed the
drop to the announcement of this flaw, although there were other factors (for example, the
expiration of the post-IPO embargo on insider sales) also driving down Netscape's stock that week.
In any case, the stock bounced back when it became clear that the product was not irretrievably
broken.
 CHAPTER SECTION:6

Section 6 -- Slash and Burn

The second set of attacks involves Java code that passes itself off as belonging to the browser. In
early versions of the JDK (before Java 2), code that came with the browser was assumed to be safe
(see Chapter 2 and [McGraw and Felten, 1996]). The original built-in code distinction was
scrapped with the introduction of code signing, and these days very little code is trusted (see
Chapter 3). In any case, the Slash and Burn fraud allows the malicious code access it would not
ordinarily have. It could, for example, access files on the local disk.

In order to properly understand this attack, you need to understand how Java works. In particular,
examine how Java accesses its own code on the browser's local disk.

Where Java Code Comes From

When a Java applet runs, many Java classes (pieces of Java code) are loaded and run. Some applet-
related classes are loaded by the applet, using the Web server. Other classes are part of the browser
itself. Browser-related code is stored with the browser on the local disk. Netscape, for example,
keeps its Java class files zipped up in an archive called classes.zip. When Netscape is installed, the
class archive needs to be put somewhere special, like /usr/local/lib/netscape on Unix machines.
Because the browser classes were considered part of the trusted browser program, they were given
more privileges. (This is no longer the case.)

In general, before JDK 1.1, Java treated code loaded from the local disk as trusted, and code loaded
over the Net as untrusted. That meant if an attacker could somehow get some malicious code
loaded from the local disk, the attacker was home free. The original system was changed
significantly with the introduction of JDK 1.0.2, which stopped treating code loaded off the disk as
trusted. This change was made behind the scenes with little fanfare. As the Cache Cramming attack
(explained later) shows, many people were confused by the change.

From our discussion of the Java class loader in Chapter 2, we know that when Java needs to find a
piece of code, say, for a class MyClass, it first looks on the local disk for a file called
MyClass.class. If Java fails to find an appropriate file on the local disk, then it tries to fetch the file
from the Web server that originally provided the applet.

We've glossed over one key issue at this point: How does Java know what class to look for? The
answer is that a class is only loaded when it is mentioned by another class already resident. This is
called dynamic loading. The name of the mentioned class is stored in the Java code for the
mentioning class.

Java classes have names like security.book.chapter5. When the Java system wants to look up a
class on the disk, it translates the dots in the class name into backslashes. The name
security.book.chapter5 becomes security\book\chapter5.2 This transformed name is the filename
used to search for the file on the local disk.

What Went Wrong: Dots and Slashes

If a bad guy wants to pass off a piece of code as trusted (in systems before JDK 1.0.2), two steps
must be carried out: 1) Get the malicious code onto the victim's disk, and 2) Trick the victim's
browser into loading it.

The first part, getting code onto the victim's disk, isn't as difficult as it sounds. For example, some
machines have public FTP directories, where anyone can put a file. Alternatively, if the victim is
using a shared, public machine, the attacker could get an account on that machine and put the file in
that account's home directory.

Perhaps the most effective way to inject code is to take advantage of the browser's cache. Most
Web browsers keep on-disk copies of recently accessed files. This allows repeated accesses to the
same Web documents without continually downloading the documents. Unfortunately, it also gives
a malicious applet a way to get a file onto the victim's machine. The applet could load the file
across the Net, pretending that it was an image or a sound file. Once this was done, the file would
be on the victim's disk in the cache. If the applet knew how the browser organized its cache, it
would know where on the victim's disk the file resided. This sneaky trick makes a second
appearance in the Cache Cramming attack as well (seepage 171).

Once the file is on the victim's disk, the attacker tricks the victim's browser into loading the file.
Since the browser only looks up classnames in relation to the current directory, the attacker would
have to place a file into the victim's working directory. Filename lookup is relative because Java
classnames cannot start with a dot; therefore, the translated name cannot start with a backslash.

David Hopwood discovered that Java 1.0.1 and Netscape Navigator 2.01 erroneously allowed a
classname to start with a backslash. Such a classname could reference any file on the system, not
just those files associated with the browser. For example, a class named
\programs.browser.cache.file407 would be looked up on the local disk as
\programs\browser\cache\file407.

This trick could be used to cause any file on the local disk to be loaded as Java code. Because code
loaded from the local disk was trusted (pre-JDK 1.0.2), it could proceed to illegally access the local
system. This attack allows full system penetration-the bad guy can do anything at all on the victim's
machine.

The Fix

This problem was fixed in Netscape Navigator 2.02 and in all Java-enabled versions of Microsoft
Internet Explorer. The fix was simple: Prohibit classnames from starting with backslashes (or
slashes, as the case may be). It is no longer possible to execute impostor code using the Slash and
Burn attack.

CHAPTER SECTION:7

Section 7 -- You're Not My Type

As discussed in Chapter 2, the most common kind of serious security problem in Java involves type
confusion. A type-confusion attack confuses the Java system about the types of data objects it is
manipulating.

The Java system treats objects as blocks of memory. Allocated memory contains the data fields of
all objects, lined up one after the other. When a Java program has a reference to an object, what it
really has internally is a pointer to the memory address storing the object. You can think of the
pointer as tagged with a type that says what kind of object the pointer is pointing to.

As mentioned in Chapter 2, every aspect of Java security depends critically on the type-safety of
the language. This means that if Java is going to be secure, it has to make sure that all pointers are
properly tagged; that is, the tag must match the actual type of object that is being pointed to.

In a type-confusion attack, a malicious applet creates two pointers to the same object-with
incompatible type tags. When this happens, the Java system is in trouble. The applet can write into
that memory address through one pointer, and read it through another pointer. The result is that the
applet can bypass the typing rules of Java, completely undermining its security.

Figure 5.4 shows a type-confusion attack at work. The applet has two pointers to the same memory:
one pointer tagged with type T and one tagged with type U. Suppose that T and U are defined like
this:

class T {
SecurityManager x;
}

class U {
MyObject x;
}

Now the applet can run code like this:

T t = the pointer tagged T;

U u = the pointer tagged U;
t.x = System.getSecurity(); // the Security Manager
MyObject m = u.x;
The result is that the object ends up with a pointer, tagged as having type MyObject, to the memory
representing Java's Security Manager object. By changing the fields of m, the applet can then
change the Security Manager, even though the Security Manager's fields have been declared
private.

While this example showed how type confusion can be used to corrupt the Security Manager, the
tactic may be exploited to corrupt virtually any part of the running Java system.

Figure 5.4 Type-confusion attack.

Two of the objects in the reference table, t and u,

are supposed to be of different types, but actually
reference the same object in memory.

An Example of Type Confusion

Drew Dean discovered a typical type-confusion attack, based on Java's handling of array types.
Java allows a program that uses a type T to use the type array of T. These array types are not
explicitly declared by the programmer, but exist automatically. The Java Virtual Machine defines
them automatically when they are needed.

These array types are defined by the VM for internal use. Java gives them a name beginning with
an open square bracket ([). As this character is not allowed to be the first character of a
programmer-defined classname, there is no danger of conflict.

Dean discovered, however, that in Netscape Navigator 3.0beta5, a Java byte code file could declare
its own type name to be one of the special array type names. Attempting to load such a class would
generate an error, but the Java VM would install the name in its internal table anyway.

This redefined one of Java's array types and created a classic type-confusion scenario: Java
considered the object an array, but it actually had some other type. The result was full system
penetration. This problem was fixed in Navigator 3.0beta6.

The Type-Confusion Toolkit

The Princeton team, as a feasibility demonstration, created a toolkit that allows any type-confusion
attack to be turned into a disarming of Java's security. In other words, the toolkit serves as a way of
turning a small security breach into a complete system penetration. The type-confusion toolkit has
not been released to the public and is considered too dangerous to describe in any detail here. The
toolkit was recently revised to work against Java 2 systems.

CHAPTER SECTION:8

Section 8 -- Applets Running Wild

The next security problem is the Princeton class-loader attack. This was the most widely publicized
of all Java security breaches. The problem was caused by mistakes in the way the Java system
integrated separate pieces of code. By corrupting this integration or linking process, an attacker
could break through Java's security and do anything at all. To help better understand this issue, the
following section looks more closely at how Java manages the dynamic-linking process.

Linking

A Java program is composed of several separate pieces called classes. Each class is stored in a
separate file, and the Java system uses a just-in-time strategy to load each class only when it is first
needed. Just-in-time loading allows Java applets to start running quickly, without waiting for the
entire applet to be pulled across the Net. It does have one drawback, however: A running applet is
usually incomplete. When an applet is built from several code pieces, the system has to be clever
enough to make sure that the right pieces are attached in the right places.

A Java class file contains a series of instructions telling the Java system how the class should
behave. The instructions sometimes reference other classes by name. Since classes are stored
separately, the Java system translates each name into the identity of another class. This may involve
loading the mentioned class across the Net.

The core Java system does not do this translation itself, but outsources it to Java objects called
Class Loaders. Outsourcing in this way allows programmers to create their own class loaders,
extending Java's linking mechanism.

The interaction between a Class Loader and the core elements of Java is simple. When Java needs
to determine which class corresponds to which name, the following steps are followed:

1. Java calls the Class Loader's loadClass method, passing it the name to look up.
2. The Class Loader consults its internal dictionary (which can include a list of built-in classes)
to see whether a class with that name already exists. If one exists, that class is returned.
3. If the Class Loader does not have a class with the requested name, it tries to find one.
Usually, it does this by fetching the byte code for the class across the Net.
4. After getting the byte code for the class, the Class Loader calls a special method called
defineClass to turn the byte code into a usable class.
5. When defineClass is finished, the Class Loader returns the resulting class to Java.
The Class Loader's loadClass method returns the class that corresponds to the name being looked
up.

There are usually several class loaders in operation. When Java needs to translate a name, it asks
the Class Loader that originally loaded the class referencing the name. Thus, each Class Loader is
responsible for maintaining and defining its own part of the namespace.

Linking and Record-Keeping

Because Java has separate namespaces into which classes can be loaded, it can't simply have a
unified "phone directory" tracking which class corresponds to which classname. Instead, the Java
Virtual Machine maintains a separate directory for each class. These independent directories keep
track of the names needed by each class.

For example, if class A has a reference to a class called B, the directory for A will have an entry for
B that points to the actual class the name represents. Figure 5.5 shows a more complicated example
with four classes referencing each other. A big applet could consist of more than four classes, but
the idea is the same: The applet is a set of classes that reference each other.

Figure 5.5 Four classes linked together.

Each box represents a class. The circled name at the top

of each box is the name of the class, and the entries
underneath show how the class's namespace is defined.

Attack of the Evil Class Loaders

The example described in Figure 5.5 shows reasonable, self-consistent namespaces. The Princeton
team discovered that a hostile class loader was capable of setting up a twisted namespace in which
different classes had different views of the Java environment. Such inconsistencies can be exploited
to create type confusion. A hostile class loader could launch a system-penetration attack.
Figure 5.6 shows an example of what an evil class loader can do. The figure shows two classes, A
and B, each of which refers to a classname "C". However, the two classes have different ideas of
what the name "C" means. Class A points to the class we've labeled C1, while B points to C2.

Figure 5.6 An inconsistent namespace, created by a

hostile class loader.

Classes A and B have different ideas about what C refers to.

This can sometimes be used to confuse the Class Loader.

Suppose that the Java code in class A allocates an object of type "C" and then passes that object to
class B. The Java byte code Verifier thinks everything is okay, since an object whose class was
named "C" is being passed into code that is expecting an object whose classname is "C". The
Verifier allows the operation to proceed. But when class B accesses the object named "C", the true
type will be C1, not the C2 that the Verifier approved. An object of type C1 is being treated as
though it were of class C2. This is type confusion.

When this attack is carried out, the evil class loader is asked twice to say which class corresponds
to the name "C". It gives back different answers: C1 for class A, and C2 for class B.

Taking Exception

The class-loader attack should have been impossible. Java's security rules prohibit applets from
creating class loaders. Unfortunately, the Princeton team discovered a flaw in the byte code Verifier
that allowed this rule to be violated. Nothing stops an applet from declaring a new class that is a
subclass of the ClassLoader superclass. It is up to the Security Manager to stop the actual
construction from occurring. In this case, the Security Manager check is bypassed because of a bug.
Read on for the gory details.

The rule against making class loaders is enforced by the object-oriented nature of Java. Every Java
class extends its superclass. Each class can be thought of as being a specialized version of its
superclass.3 Every class has one or more constructor functions, which properly initialize new
objects. Java requires each constructor to call the constructor of its superclass, or another
constructor of the same class, before it does anything else. For example, if you create a class called
MyHashtable that extends the built-in class java.util.Hashtable, then you have to provide a
constructor for MyHashtable. That constructor must call the constructor of java.util.Hashtable
before it does anything else. The byte code Verifier ensures that these rules are followed.

To prevent applets from making class loaders, the constructor for the class ClassLoader consults
the Security Manager, which generates a Security Exception if the class loader being constructed
would belong to an applet. This Security Exception can abort the creation of such an object. If an
applet defines a new EvilClassLoader class to extend the basic ClassLoader, then the new
constructor is required to call Java's basic ClassLoader constructor. Doing so generates a Security
Exception that prevents the applet from creating an EvilClassLoader.

What the Princeton team discovered was a trick by which a constructor could avoid calling its
superclass constructor, without being caught by the Verifier. This allowed them to create an
EvilClassLoader whose constructor did not call the basic ClassLoader constructor, and thus was not
subject to the normal Security Manager check. The EvilClassLoader could then create type
confusion.

Having created type confusion, the attacker could then exploit it to achieve full system intrusion;
that is, the attacker could do anything at all on the victim's machine.

The (Sort of) Fix

Sun Microsystems and Netscape had two options for fixing this problem. They could prevent the
superclass-constructor-avoidance by fixing the Verifier, or they could find another way of forcing
the basic ClassLoader constructor to be called. They chose to do the latter. They added an
initialized data field to every class loader, and set the field to true only when the basic ClassLoader
constructor was run. The basic ClassLoader would refuse to perform the crucial defineClass action
unless the initialized field was true.

The implementation created a new private ClassLoader method called defineClass0. This does the
real work of defineClass. Redefining defineClass to check the initialized flag and call defineClass0
only if the flag was true helps to block this particular security hole. The change does not prevent an
attacker from making a class loader, but it does prevent an attacker from using the new class loader
once it has been made.

The change took effect in Netscape Navigator 2.02. Unfortunately, future attacks managed to
circumvent this fix.

The Reaction

This flaw received more press coverage than any of the others. It had more news interest than the
DNS bug because it was more serious. Later bugs did not receive as much coverage because by the
time they came to light, the novelty of bug discovery had worn off. That does not mean that the
current and future security problems are not just as serious. Whether or not security problems are
splashed on the front pages, they still need to be taken seriously.

Perhaps the press coverage partly reflected a backlash against the extremely positive hype
surrounding most press stories about Java at the time. Java is great, but many of the exaggerated
claims went much too far. There was even a story stating that if you wrote programs in Java you
would never have to debug them because they would always be right the first time. To be fair, only
a little of the hype came from Sun. Much of it came from freelance consultants, self-proclaimed
experts, and trainers who had an interest in seeing their Java bandwagon become a juggernaut.

When the Applets Running Wild flaw was discovered, Sun Microsystems, Netscape, and the flaw's
discoverers gained some valuable experience discussing these issues with each other and with the
press. As a result, the parties did a better job of conveying simple and consistent information to the
public. Hopefully, this will remain true when future security holes come to light.

CHAPTER SECTION:9

Section 9 -- Casting Caution to the Wind

Software consultant Tom Cargill has discovered two security flaws related to the way in which
Java handles interface types. Both flaws involve a rare case in which Java fails to check whether a
method is private. Both also use type-casting operations on Java's interface types. By exploiting
these flaws, an attacker can call private methods normally prohibited by Java's security rules. Since
some of the security-critical values inside the Java system are protected by private methods, a
complete security breach using this attack is possible.

Simple Interface Casting

The core of Cargill's first discovery is shown in the following code:

interface Inter {
void f();
}
class Secure implements Inter {
private void f();
}
class Dummy extends Secure implements Inter {
public void f();
Dummy() {
Secure s = new Secure();
Inter i = (Inter) s;
i.f(); // should be illegal
}
}
This code allows the private f method of class Secure to be called illegally. The Java interpreter
fails to determine if f is private when i.f() is called.

The Princeton team figured out how to use this flaw to achieve full system penetration. This was
done by exploiting the fix to the class loader bug. The class loader bug was fixed by splitting the
critical defineClass method into a private method and a public method. The private method,
defineClass0, did the work. The public method checked the initialized flag and called defineClass0
only if the flag was true. Since the private defineClass0 method couldn't be called directly by an
applet, this was supposed to fix the class loader bug.

Unfortunately, a variant of the interface-casting trick shown here allows an applet to call the private
defineClass0 method directly, bypassing the check. This meant that the attack could create a class
loader by exploiting the Verifier bug. The initialized flag would be false, but that wouldn't matter.
A programmer could bypass the flag-check by exploiting the interface-casting trick to call the
private defineClass0 method directly.

By using this trick, an attacker could gain full system penetration under Netscape Navigator 2.02.

The Full Fix

Netscape fixed this problem in two ways. First, it fixed the flaw in its Java Virtual Machine that
allowed the interface-casting trick to work. Second, Netscape began storing and checking the
initialized flag inside the Java Virtual Machine, rather than in programmer-generated Java code.
Netscape eliminated the dangerous defineClass0 operation by integrating everything into the VM's
implementation of defineClass. This change took effect in Navigator 3.0beta3.

In reaction to the interface-casting bug, Netscape changed its Java implementation to protect itself
more generally against an attacker who had the ability to call private methods. By going beyond a
simple bug fix to improve the structure of the system, Netscape practiced good security
engineering. Its decision paid off when the next bug was discovered.

Advanced Interface Casting

Here is the core of Cargill's second discovery:

interface Inter {
void f();
}

class Secure implements Inter {

private void f();
}

class Dummy implements Inter {

 public void f();

static void attack() {

Inter inter[2] = {new Dummy(), new Secure() };
for(int j=0; j<2; ++j) inter[j].f();
}
}

The first call, inter[0].f(), is legal since Dummy's f method is public. The next time around the loop,
inter[1].f() is illegal since Secure's f method is private.

In this case, Java was too smart for its own good. In order to improve performance, it only checked
for legality the first time through the loop. Theoretically, what was legal the first time would be
legal the next time. (See Chapter 2.) Though this is often a correct assumption, it broke down for
the code just shown.

This trick allows an attacker to call private methods in violation of Java's security rules. Had
Netscape not improved the structure of their system after the previous bug was reported, this bug
would have once again allowed the class-loader attack to work. However, because Netscape had
protected their system against private method attacks, this flaw was not easy to exploit.

CHAPTER SECTION:10

Section 10 -- Tag-Team Applets

The next group of attacks combines the two previous attack methods. By setting up two separate
naming environments and passing objects between them, this new group of attacks causes type
confusion, leading to security breaches.

These attacks are launched by putting two applets on a Web page and having the two applets
cooperate. Typically, both applets would be written by the same programmer, and located on the
same Web server.

To better understand this threat, the next section will examine in further detail how Java manages
namespaces. (See also Chapter 2.)

What's in a Name?

In a Java-enabled browser, several applets might be running at the same time. Since each applet
contains several classes, each with a distinct name, there's a danger that two applets might
accidentally use the same name. To prevent this, the Java designers decreed there should be a
separate namespace for each applet; that is, each applet should have its own view of which names
correspond to which classes.

Despite the fact that each applet has its own namespace, there are ways for two applets to pass
objects back and forth among themselves. One such channel involves public variables in the Java
runtime. Another channel is through manipulating threads. The result is that an applet can
potentially have an object whose name is defined in another namespace.

Things can get tricky when this happens. For example, suppose that the AncientGreek applet and
the Simpsons applet are running at the same time. Each of the two applets has defined a class called
Homer, but they have very different ideas of how Homer should behave. Worse yet, imagine that
the two applets communicate, and the AncientGreek applet ends up with a Homer Simpson object.
If the AncientGreek applet asks the object what its class is, the object responds, Homer. The
AncientGreek applet then asks Homer to recite an epic poem. Depending on your point of view, the
result would be either tragic or comical. In any case, it wouldn't be what the programmers wanted.

This isn't really a security risk; however, it becomes one if the Java system itself gets confused. The
danger is that the system will decide that two unlike types are really the same, when all that is the
same is their names. This sort of mix-up would constitute type confusion, and the applet could
break the Java type system, leading to a security breach.

One way that an applet could do this is by engaging in type punning. The applet would set up two
types with the same name, create an object of one type, and then use it as though it were an object
of the other type. For example, suppose that this is a Java type:

class Secure {
private Object secretData;
}

Another applet could create another type with the same name:

class Secure { // impostor

public Object secretData;
}

Now if the applet could get an object of the real Secure class and convince Java that the object
belonged to the impostor Secure class, Java would allow the applet to access the supposedly private
secretData field. As far as Java is concerned, this would be fine. The impostor secretData field is
public. The applet would have accessed data it was not supposed to see.

Type punning works for method calls, too. If the secretData field were replaced with a
dangerousOperation method, then an applet that could do type punning could call the
dangerousOperation method even though it was supposed to be private. In summary, if type
punning is possible, Java's security collapses.

Java prevents type punning by being very careful when deciding whether two classes are the same.
Rather than using the classname to make this decision, Java considers two classes the same only if
they have the same name and were defined in the same namespace (that is, by the same Class
Loader). That is sufficient protection to avoid type punning.

What Went Wrong: A Name Alone

Unfortunately, the creators of Java were not always so careful. In Java 1.0.2, Netscape 2.02, and the
first beta version of Internet Explorer, the types of interfaces and exceptions were compared by
name rather than by (name, namespace) pair as required. This led to a set of attacks that could
break Java's security system, achieving full system penetration. The attacks worked as described
earlier. The attacker wrote two applets defining different classes with the same name C. One applet
would create an object of class C and pass it to the other applet, which would operate on its C. This
leads to a classic type-confusion situation, which can be exploited by methods seen several times in
this chapter.

CHAPTER SECTION:11

Section 11 -- Big Attacks Come in Small Packages

We now describe an attack applet that exploits a Java security weakness in beta versions of
Microsoft's Internet Explorer 3.0. The weakness allows code in an untrusted applet to pass itself off
as part of a Java package. This flaw allows an attacker to gain full access to the victim's files and to
the network.

Understanding this flaw requires a more detailed explanation of Java packages.

Java Packages

The Java language supports the concept of packages-groups of Java classes meant to be used
together. Packages have names like java.lang and EDU.princeton.cs.sip. Every Java class belongs
to some package.

Packages serve two purposes. First, since the full name of a class is the package name followed by
the classname, they provide a way for different people to name their classes without having
accidental name collisions. For example, if we put all of our classes into the authors package and
you put all of your classes into the readers package, then our classnames cannot collide with yours.

The second purpose of packages is to restrict access to certain Java variables. When declaring a
variable, a programmer states which classes are allowed to access the variable. If the variable is
declared private, it is accessible only by the class that created it. If a variable is declared protected,
it is accessible only by the creating class and its subclasses. If a variable is declared public, it is
accessible by all classes. If a variable is declared neither private, protected, nor public, then it is
accessible only by classes in the creating class's package.

Some packages limit their membership to only built-in browser classes. Membership is restricted
by having the Virtual Machine ask the Security Manager to pass judgment on every request to join
a package. The Security Manager enforces restrictions by prohibiting classes loaded across the Net
from joining restricted packages. (For more information on this topic, see Chapter 2.)

What Went Wrong

In Microsoft's browser, there was an error in the way the Security Manager made its decisions
about package membership. Because of the bug, the Security Manager incorrectly used only the
first component of the package name to check access permission. This method failed for packages
whose names started with com.ms. Interestingly, several of Microsoft's built-in packages started
this way. (This is interesting because the domain name ms.com belongs to Morgan Stanley, not to
Microsoft. The package should have been called com.microsoft, although this change would not
have prevented the bug.)

The result was that untrusted applet code could join a sensitive package, and gain access to any
variables in that class that were accessible package-wide. These variables included, among other
things, the Security Manager's list of files to which the applet had access. A mischievous applet
could access any file on the system by changing the Security Manager's list to include the desired
file.

The Reaction

This flaw was found just before Microsoft was to ship the first nonbeta version of their Internet
Explorer 3.0 browser. Since the ship date had been announced (and a big public release hoopla was
planned), the ship date could not be moved. Since the product had a serious security flaw, shipping
it was not an acceptable alternative. Microsoft's development team launched a heroic effort to fix
the bug, test the solution, and restart the product release cycle in time to meet the original release
deadline. They succeeded.

The Big Attacks Come in Small Packages bug was the last major flaw found in the JDK 1.0.2
security model implementations. Following discovery of this attack applet, several months went by
before JDK 1.1 was released. As we discussed earlier, the period of six months without a major
security hole was of long enough duration to convince some people (in particular, Java's most
ardent supporters) to declare that all holes had been discovered and that Java had been rendered
secure through a series of patches. In fact, the previous version of this book was waved around as a
prime example of antiquated old news that no longer applied.

Even if another hole is never discovered in Java (unlikely, but why not dream big?), the
information contained in this chapter is important to people charged with designing, managing, and
using software in a security-critical situation. We all do well to learn from our mistakes as history
often tends to repeat itself.

CHAPTER SECTION:12

Section 12 -- Steal This IP Number

In a February 1997 post to comp.lang.java.security and Bugtraq, two British consultant/hackers,
Major Malfunction (probably not his real name) and Ben Laurie, followed through with their
decision to inform the unsuspecting of a couple of new Java-based attacks. Although the pair (and
assorted friends) had actually used Java to hack their way through firewalls a month earlier, they
thought it only fair to provide Netscape and Microsoft with ample time to address the problems
before they went public.

The most interesting thing about the two attacks was the fact that one of them (which we call the
Steal This IP Number attack) was found only in Netscape, and the other (which we call Cache
Cramming) was found only in Internet Explorer. This is interesting because it emphasizes the fact
that there are multiple Java implementations, and they are not always equivalent. To be sure, they
are all supposed to follow the same specification, but there are many ways to do so. As a result,
Netscape's model (which is very close to the JDK implementation) and Microsoft's model differ
significantly. This implies that as Java implementations diverge, holes related to implementations
will not be cross-platform. It also implies that some implementations will be more secure than
others.

It is stretching a bit to call the first problem a Java security hole, but because of the way the hole
was treated by the community we decided to include a description here anyway.

The Steal This IP Address hole, which exists in both Navigator 3.x and 4.0, allows a miscreant to
gain access to information from the client machine that would normally be considered secure. The
attack works as advertised on the Java/MSIE/Netscape Cache Exploit page
(seewww.alcrypto.co.uk/java/), but there is really nothing new to this discovery. On their page,
Major Malfunction and Ben Laurie say:

All we can do is log the real identity of a client machine, despite most precautions they might take
to prevent us from doing so . . . Devices such as firewalls, proxies, SOCKS hosts, etc., all succumb
easily to the call of the Java siren . . . Even the mighty anonymizer retires after the first round, nose
bleeding and ego bruised. To complete this recipe, we take one call to InetAddress.getLocalHost(),
mix it with a call to AppletContext.showDocument() . . .
And there you have it. Because the applet is running on the client machine and it is allowed to call
InetAddress.getLocalHost(), it can find out the client machine's IP. Although this may surprise
some users (especially those using the anonymizer, a proxy meant to protect client browser
identities from snooping Web servers), the ferreting out of this information is not really a
dangerous new invasion of privacy. The Web is not a private place, and this demonstration only
serves to bring that point home. Your browser is probably a blabbermouth. It is a clever move to
use Java to look up an IP at the client end through several proxy layers, but not all that clever.

Déjà Vu All Over Again

The flaw that appeared in the Netscape browser was actually a flaw that had been discovered and
fixed internally by JavaSoft some 10 months before it reappeared. In Sun's JDK 1.0.2 reference
implementation of java.net, an applet that calls getLocalHost() does not get a true hostname/IP
address; instead, it gets the loopback host ("localhost/127.0.0.1"). For some reason, the change
made to fix the privacy hole was not incorporated into Netscape. The fix was exceptionally easy.

CHAPTER SECTION:13

Section 13 -- Cache Cramming

The second of the two attacks discovered by Major Malfunction and Ben Laurie in February 1997
works against Microsoft's Internet Explorer browser, but not Netscape. Unlike the minor Steal This
IP Address problem, this problem is much more disturbing. On their Web
page,www.alcrypto.co.uk/java/, Major Malfunction and Ben Laurie claim "this loophole allows an
attacker to connect to any TCP/IP port on the client's machine." That's a bit of an overstatement,
but interesting information about listening ports can be gathered (for possible later use), which may
leave a firewalled host more susceptible to standard TCP/IP-based attacks. And that's bad news.

The Java Security Manager usually disallows port-scanning behavior, but the crackers use the well-
known trick of sticking some Java code (in this case, a port scanner) in the browser's cache and
later executing it through a file: URL (using frames in the usual way). This attack works because
Microsoft's cache layout is transparent.

This is an interesting variation on the Slash and Burn attack described on page 153. The attackers
cheat a bit for demonstration purposes by having the patsy clear his or her cache, but even without
this exercise, guessing the cache location (one of four possibilities) would not be all that much of a
challenge.

Contrary to their claim, however, Java security rules are no longer relaxed for code loaded out of
the cache (unless the cache happens to be in the CLASSPATH, which is not recommended). That
problem was fixed in the upgrade to JDK 1.0.2. (Yet another reason that the Slash and Burn attack
is obsolete.)
In any case, Microsoft apparently places HTML and class files in the same directory stored with
their original names (remember, a Java class will only run if it is correctly named). Although MSIE
can't browse cache files directly, HTML pages can reference cache files by explicit name. Thus, the
file: URL, if properly constructed, can invoke the Java class.

The applet stuffed in your cache is a port scanner. The port-scanning attack works because an
applet is allowed to open a socket connection back to where it came from. And guess where it came
from: Yep, the client machine.

So a port scan is carried out by their cache-bomb applet. Unlike the Steal This IP Address problem,
port scanning is very serious. Using this attack, a cracker might be able to discover things like weak
sendmails listening on port 25, leaving only the problem of getting the port-scan information back
to the cracker site. Accomplished crackers can simply use the URL-lookup covert channel to do
this. Unfortunately, this approach is only one of many ways of sending interesting tidbits out from
an applet.

Resolution

The information released by Major Malfunction and Ben Laurie prompted Microsoft to release a
patch to solve the problem.

CHAPTER SECTION:14

Section 14 -- Virtual Voodoo

In March 1997, Sun announced the discovery and eradication of a bug in the Verifier of the JDK.
The bug was present in all Java VMs, and Sun shipped a patch to Java licensees. Sun claimed that
the bug was discovered by the engineering team during a standard security audit and was fixed
within 24 hours of discovery.

No attack based on this bug was ever devised. In fact, very little information about the fix was
disseminated publicly. Statements made by Sun to the press emphasized the complexity of an
exploit. Realistically, it sounds like the problem was similar to the You're Not My Type problem-an
attacker would need to create malicious byte code to exploit the problem.

Preemptive Strike?

We found it a bit peculiar that Sun announced the discovery of a flaw in the Verifier and the
dissemination of a patch to vendors. We speculate that someone outside of Sun had discovered the
problem and Sun decided to announce the flaw before the discoverer did.
 CHAPTER SECTION:15

Section 15 -- The Magic Coat

Chapter 3 serves to emphasize that code signing is complicated. As in the original sandbox model,
there is plenty of room for error in designing and implementing a code-signing system. The Magic
Coat hole was a fairly straightforward problem in the implementation Java's Class class and was
quickly explained on both the Princeton Web site (www.cs.princeton.edu/sip) and JavaSoft's
security site (java.sun.com/sfaq). The problem was that the method Class.getsigners() returned a
mutable array of all principals that signed a particular class. It was possible for an applet to modify
the array, label itself as signed by a trusted principal, and thus gain whatever privileges it wanted.
The applet didn't even have to guess which principals were trusted: the system helpfully gave it a
list of all known principals "t" and the applet could "try on" the known identities one by one until it
found a highly privileged one. The fix was as simple as returning only a copy of the array and not
the array itself.

Consider a situation in which Alice has been granted no security privilege on a Web user's system.
In fact, contrary to what the original JavaSoft statement about the bug claimed, Alice can be
completely unknown to the system. In other words, code signed by Alice is not trusted any more
than the usual applet off the street. If the Web user (using the HotJava browser, which at the time
was the only commercial product that supported JDK 1.1.1) loads an applet signed by Alice, that
applet can step out of the sandbox by exploiting the hole.

The fact that the system need not have Alice's public key in its database is important. It means that
Alice can be any arbitrary attacker who knows how to sign an applet with a completely random
identity. Creating such an identity is easy, as is signing an applet with that identity. This makes the
hole very serious indeed.

The hole allows Alice's attack applet to change the system's idea of who signed it. This is especially
bad if Alice is not granted privilege to run outside the sandbox, but Bob is. Alice's applet can
exploit the hole to change its level of permission to include all of Bob's privilege. Alice's applet can
get the maximum amount of available privilege doled out to any signer known to the system.

If you liken the signature/privilege identities to coats in a closet, Alice's attack applet can try on
each coat and attempt various disallowed things until it discovers which of the coats are "magic"
and allow it to gain privilege. If a magic coat is discovered, Alice's applet can step out of the
sandbox and do things it should not be allowed to do. Trying on coats is as simple as attempting a
disallowed call and watching to see what happens.

In brief, by exploiting this hole, the Magic Coat attack applet can get a list of all signers known to
the local system, determine which if any of those signers is trusted, and then relabel itself so it
appears to have been signed by a trusted signer. The result is that the applet can completely evade
Java's security mechanisms.

JavaSoft fixed the flaw in release 1.1.2 of the JDK. Soon after discovery of the hole, a patch was
created and sent to the various Java licensees. Since neither Netscape nor Microsoft supported JDK
1.1 code signing when the hole was discovered, they were not vulnerable. In fact, as Chapter 3
discusses, both Netscape Communicator and MSIE have different models of code signing than Sun
does.

Assessing the Bug

JavaSoft states correctly that this bug "represents minimal exposure to users" since it affects neither
of the popular browsers. It is important to note that HotJava is completely susceptible to this
problem unless code signing is entirely disabled. HotJava has always been suspect from a security
perspective, and the Magic Coat hole shows why.

So was this bug serious? Yes. It provides yet another example of how complicated systems can
break down in unexpected ways. Dr. Peter Neumann, moderator of comp.risks and noted security
expert said at the time, "This is another instance of an old RISKS story-a surprisingly large portion
of the entire infrastructure must be trustworthy, including pieces you might not have realized were
critical. That statement is perhaps best thought of as a corollary to Leslie Lamport's classic
statement, 'A distributed system is one in which the failure of a computer you didn't even know
existed can render your own computer unusable.'"

CHAPTER SECTION:16

Section 16 -- Verifying the Verifier

As Chapter 2 describes, one of the essential pieces of the Java security model is the Verifier, which
is responsible for checking the integrity of a class file and its byte code. Each VM, including the
VM in your browser, has its own version of the Verifier. Thus the Verifier acts as a kind of
independent verification mechanism to double-check the integrity of mobile Java that arrives from
unknown parts.

The University of Washington's Kimera Project, led by Professor Brian Bershad, implemented a
clean-room Verifier as part of a larger mobile code architecture experiment. The main idea behind
the Kimera Project is to centralize Verification of byte code instead of having a Verifier running on
each client. Their aims in creating a Verifier were to make it small, simple, and able to work
independently. The discussion here is distilled from extensive Kimera Web documentation, which
can be found at kimera.cs.washington.edu.
After creating their Verifier, the Kimera Project team wanted to test it to make sure it performed in
a secure and robust manner. The question was, how to do this? The answer to that question led to
an empirical demonstration that the Kimera Verifier was safer than many commercial Verifiers
then in widespread use.

Most commercial Verifiers perform security checks in a series of stages that are distributed
throughout the VM architecture. In particular, Chapter 2 describes how verification is traditionally
broken into static and runtime processes. By contrast, the Kimera Verifier packages a complete
verification system as one single component. An added bonus to the Kimera Verifier is the
inclusion of a number of safety axioms distilled by the Kimera Project from the Java VM
specification. This has the advantage of allowing the Kimera Verifier to be checked for correctness
in a more thorough manner than the code for commercial Verifiers.

The Kimera Verifier aligns closely with class file verification as described in the VM specification.
That means the process of verification is logically divided into four stages (see Chapter 2 for more
on these stages):

• Verification of class file consistency and structural soundness

• Verification of instruction boundaries and safety of branches
• Data flow analysis that verifies that operands preserve type-safety rules
• Verification that the class, along with the rest of the VM, does not break global type-safety
rules or interface restrictions

In order to test their Verifier, the Kimera Project team created a mutation testing system. The end
product of the approach is a test suite that includes millions of tests. The tests, millions of legal and
illegal byte code patterns, were created by applying a set of simple mutation rules to a small
number of primitive test cases. Without access to an oracle (the lack of which is the traditional
Achilles' Heel of testing), there is no way to say whether behavior of the Verifier on any given test
is correct or incorrect. One way around this is to submit the tests to a number of different Verifiers
and see what happens.

According to this paradigm, whenever results from a number of distinct Verifiers disagree, further
investigation into the cause of the disagreement is warranted. The obvious problem with this
approach is that if all Verifiers perform equally incorrectly on a test case, nothing suspicious will
be observed, and all Verifiers will be incorrectly thought to have done the right thing. Regardless of
that serious flaw, the Kimera test suite was able to identify a large number of errors in commercial
Verifiers, which led to correction of the Kimera Verifier throughout its testing.

The Kimera testing paradigm has much in common with N-version programming, in which N
distinct versions of a piece of software are run simultaneously and a vote determines the final
result. (For more on N-version programming see [Voas and McGraw, 1998].) We believe Kimera's
testing methodology is a glimpse at the future of testing. Given the vast computational resources of
today, there is no reason not to automate testing to a much greater extent than was feasible just a
few years ago. Traditional metrics, such as test coverage, can be used to gauge the efficacy of such
automated testing.
 Flaws in the Verifier

In April of 1997, the Kimera Project announced the discovery of 24 flaws in Sun's Verifier
implementations and 17 flaws in Microsoft's Internet Explorer. Because Netscape's Verifier is very
closely based on the one in Sun's JDK, it is safe to assume that most of the 24 flaws in Sun's
Verifier exist in Netscape's as well (in fact, testing confirmed this). As we detail next, the flaws can
be divided into several categories: security holes, weaknesses, and ambiguities.

Flaws in Sun's JDK

The Sun flaws were found in the Verifiers included in JDK 1.0.2 and JDK 1.1.1. JDK 1.1.1
contained only 15 of the 24 total flaws. One of the flaws was serious enough to warrant an
immediate patch to the JDK. We describe it now.

The most serious flaw was a type-safety error that allowed a number to be converted into a pointer
to any object in the VM. An attack applet based on this flaw could gain access to privileged
information or otherwise force an illegal operation. As we describe in Chapter 2, type-confusion
errors of the sort that this bug could lead to can be used to circumvent Java's security mechanisms
entirely. This flaw allowed applets to assign a long or a double into an object reference, which can
in turn be used to forge pointers inside the VM. Both JDK 1.0.2 and Netscape's Navigator Gold
3.01 included this bug.

Five other type-safety problems were also discovered in Sun's Verifier. One of these errors
prompted Sun's security patch. This flaw, which existed in JDK 1.1.1 and JDK 1.0.2, involved the
fact that a method can declare its maximum number of locals to be N, but take M arguments in its
signature, where M can be greater than N. A description of the type-safety problems can be found
atkimera.cs.washington.edu/flaws/sunflaws0423.html.

Besides the type-safety flaws, 11 access-flag flaws were identified. One example of such a flaw
found in JDK 1.1.1 and JDK 1.0.2 is a flaw in which access flags for some methods are
unrestricted. A properly constructed attack might be able to affect type safety and lead to a type-
confusion attack. Once again, more information is available on the Kimera Web site. Finally, seven
flaws can be classified as instruction or class file validity problems. The most serious of these
flaws, found in JDK 1.0.2, was a problem whereby the class namespace management system could
become confused by malformed classnames.

Flaws in Microsoft Internet Explorer

The Kimera Project's testing methodology uncovered 17 flaws in Internet Explorer versions 4.0 and
3.02. Microsoft released a patch to address some of the more serious problems. Ten of the flaws
that applied to the MSIE Verifier also occurred in Sun's Verifier.

The most serious flaw was the same flaw discovered in the JDK implementation: the ability to
assign a long or a double into an object reference. This flaw prompted the security patch. A list
briefly explaining of all the flaws can be found
at kimera.cs.washington.edu/flaws/msflaws0423.html.
 The Reaction

One of the most interesting things about the Verifier bugs discovered by the Kimera group was the
way in which the news broke in the press. Somehow, Sun was able to stage a preemptive PR strike
before the Kimera announcement was even made. Their version of the story, which was later
changed to more closely align with reality, was covered in the Wall Street Journal. In particular, the
Sun announcement focused on only one of the many bugs.

The importance of type safety to the Java security model was also reemphasized by the Kimera
Project findings. Sun claimed that many problems in the type system might lead to a denial-of-
service attack through a crash, but did not acknowledge that it is often trivial to turn these crashes
into more insidious type-confusion attacks. The next Java security hole, also discovered by the
Kimera Project, served to bring that point home.

CHAPTER SECTION:17

Section 17 -- The Vacuum Bug

In June of 1997, the Kimera Project team uncovered another security hole in JDK 1.1.2 and the
HotJava browser. Like the previous 24 flaws discovered, the new security hole had at its core a
type-safety flaw in the Verifier. Prompted into further action by Sun's response to the first
announcement, the Kimera Project team decided to create a complete exploit based on the new
flaw. That was one way to emphasize that type-safety problems should always be taken seriously!

The flaw itself existed only in JDK 1.1.1 and JDK 1.1.2 and was never present in either of the
major browsers. By itself, the flaw manifests itself as a VM/browser crash (the browser being
HotJava). That is, an applet that passes the Verifier with flying colors would end up crashing the
VM when it actually ran. The crash is caused when the applet directs the browser to access
inaccessible memory.

Using a PC debugger (MSDEV), Kimera team members were able to determine which instruction
was causing the browser to crash. With this information in hand, it was possible to cause the
browser to jump to a legitimate address and start reading arbitrary memory ranges. In a strings-like
move, the malicious code directed an ASCII text version of the targeted memory range back to a
collection server.

The attack applet created by Kimera exploited the type-safety problem to carry out this attack. The
most pernicious aspect of the attack was the applet's ability to determine sensitive information
about the user from the browser's memory space, including configuration settings, private crypto
keys, name, email address, browser history, cache contents, etc.
 Why the Flaw Was Exploited

Other than its ability to steal sensitive data, the main purpose of the attack applet was to
demonstrate that what Sun had called "less serious" type-safety problems could be easily turned
into full-fledged attacks. Java has at its heart a language-based security model. Such models depend
completely on the type system to provide security guarantees.

CHAPTER SECTION:18

Section 18 -- Look Over There

In August of 1997, Ben Mesander, a professional programmer and consultant from Creative
Concepts in Boulder, Colorado, uncovered a security hole that allowed untrusted Java applets the
ability to make network connections to arbitrary locations. This flaw affected browsers with VMs
coded to the JDK 1.0.2 specification. According to the JDK 1.0.2 security model, applets are not
allowed to make network connections to any host other than the Web server from which they come.
Three browsers-HotJava, Netscape, and MSIE-were all susceptible to the problem (at least with
some proxy configurations, as we explain later).

To demonstrate the flaw, which was most apparent in the MSIE implementation of Java, Mesander
wrote a simple applet that was able to load a graphic from www.microsoft.com even though the
applet was not hosted from that server. The ability to open arbitrary connections to other servers is
distressing for several reasons. The first is that such a connection provides a channel for indirect
attacks. That is, a bad guy can cause your browser to run an attack against another server, making
your machine take the blame. Another is that information from your machine may be siphoned off
to another site. A third is that some attack code could be fetched from another location, leaving the
true culprit applet in a less-suspicious situation should a successful attack be carried out against
your machine. Finally, and most realistically in terms of the example we will show later, the attack
applet is able to download an image from any Web server, even those servers behind firewalls. If
you have images on your intranet that should not be seen by people outside your organization (such
as sales data with sensitive pricing information), the seriousness of the attack is apparent. In any
case, it is clear that Mesander's applet was able to do something that should not be allowed.

The applet itself is shown as Listing 5.1. Mesander serves up this "test applet" as an example on his
Demo of Browser Security Hole page atneurosis.hungry.com/~ben/. The applet attempts to load a
graphic from a disallowed site (Microsoft's Web site). The applet is able to determine its level of
success and display a message relating to the security of your browser.

Listing 5.1 Ben Mesander's applet WhereDoYouWantToGoToday fetches an image from a

disallowed location.

// ben@gnu.ai.mit.edu
import java.applet.*;
import java.awt.*;
import java.net.*;
class WhereDoYouWantToGoToday extends Canvas
{
Image image = null;
WhereDoYouWantToGoToday (Image image)
{
super ();
this.image = image;
}

public void paint (Graphics g)

{
g.drawImage (image, 0, 0, this);
}

public Dimension preferredSize ()

{
return new Dimension (image.getWidth (this), image.getHeight (this));
}

public Dimension minimumSize ()

{
return preferredSize ();
}
}

public class example0 extends Applet

{
private Button b;
public void init ()
{
createUI ();
}
private void createUI ()
{
setLayout (new BorderLayout ());
b = new Button ("Go!");
add ("West", b);
}

public boolean action (Event evt, Object arg)

{
if (evt.target.equals (b))
{
try
{
Image i = getImage (new URL (getDocumentBase (),
"cgi-bin/redirect?where=" + URLencode
("www.microsoft.com/library/images/gifs/
homepage/tagline.gif")));
MediaTracker tracker = new MediaTracker (this);
tracker.addImage (i, 0);
tracker.waitForID (0);
if (i.getWidth (this) == -1)
add ("Center", new TextField ("Browser did not get exception,
but image did not load"));
else
{
add ("Center", new WhereDoYouWantToGoToday (i));
add ("East", new TextField ("Your browser is not secure."));
}
validate ();
}
 catch (Exception e)
{
add ("Center", new TextField ("Exception while fetching image:"
+ e));
validate ();
}
return true;
}
return super.action (evt, arg);
}

private static String URLencode (String s) {

int i; StringBuffer b = new StringBuffer ();
for (i=0; i < s.length () ; ++i)
{
b.append (URLencode_helper ((char) (s.charAt (i) & 0xff)));
}
return b.toString ();
}

private static String URLencode_helper (char c)

{
if (c %lt; 16) {
return "%0" + Integer.toString (c, 16);
} else if ((c < 32) || (c > 127) || (" +&=%/~#".indexOf (c) >= 0)) {
return "%" + Integer.toString (c, 16);
} else {
return String.valueOf (c);
}
}
}

The applet works in concert with an HTTP redirect call that the browser being attacked follows to
wherever it leads. Most of the dirty work takes place in the line:

Image i = getImage (new URL (getDocumentBase (), "cgi-

bin/redirect?where=" + URLencode
("www.microsoft.com/ library/images/gifs/homepage/tagline.gif")));

Having your Web server implement the redirect command is very simple. With the Microsoft IIS
server, the code is as simple as:
Response.Redirect("http://" & Request.QueryString("where")).

This applet demonstrated flaws in the Java implementations of several browsers. In particular,
results before the browsers were patched showed the following vulnerabilities:

• MSIE browsers on all versions of Windows had a serious bug, which Microsoft took very
seriously and released a patch for within several days of the bug's discovery.
• Netscape browsers were susceptible only if they were set up to use an HTTP proxy server. In
particular, proxies set up to work outside the firewall caused big problems. Netscape fixed
the bug in later releases of their browser.
• The HotJava browser allowed classes to be loaded via redirects, but did not allow images to
be loaded this way.
It is important to emphasize that this is a very clear example of an implementation bug and not a
design problem. Java's design at the time was such that redirects were rendered impotent as an
attack mechanism. However, all the vendors (including Sun's HotJava team) did not properly
implement the design.

Another important point is that the attacker must know the URL of the image or class file that is
being indirectly fetched. Sometimes, getting this information is not possible. Other times,
standardized naming conventions constrain the space of possible names enough that a good guess
works. A good attack strategy would be to combine this exploit with a standard social engineering
attack that is used to determine the name of the image file or class file to steal.

Last, But Not Least

Mesander's redirect exploit was the last Java-related problem discovered in JDK 1.0.2 and JDK 1.1.
In fact, Java experienced a calm period of several months before the next serious hole was
discovered in July of 1998. The timing of these flaws supports the observations that discovery of
holes tends to be clustered around major releases and that eventually a majority of the holes are
found and fixed.

CHAPTER SECTION:19

Section 19 -- Beat the System

In July 1998, Dirk Balfanz, Drew Dean, Edward Felten, and Dan Wallach of Princeton's Secure
Internet Programming team found another Java security flaw that allows a malicious applet to
disable all security controls in Netscape Navigator 4.0x. After disabling the security controls, the
applet can do whatever it likes on the victim's machine, including arbitrarily reading, modifying, or
deleting files. As usual, the Princeton team implemented a demonstration applet that deletes a file.

The hole that the Princeton Team discovered was actually present in all VM's, but was only
exploitable in Netscape 4.0x. This serves to emphasize the difference between holes and exploits
discussed earlier in the chapter (see page 142). Figure 5.7 illustrates the relationship between a
security hole and an attack applet that exploits the hole.

Figure 5.7 Security holes and exploits.

An attack applet is created to exploit one or

more security holes in order to completely
compromise security.
This attack pieced together several security-related flaws. The first flaw, discovered by Mark
LaDue, is that the Netscape 4.0x Security Manager does not prevent untrusted applets from creating
subclasses of Netscape's AppletClassLoader class. This allows an applet to create a Class Loader.

The second flaw, discovered by the Princeton team, is that the class loader mechanism, as of JDK
1.2beta3 and Netscape 4.0x (and, apparently, Internet Explorer 4.01), sometimes allows a malicious
Class Loader to override the definitions of built-in classes. Specifically, a Class Loader can use its
defineClass() method to define classes that have the same name as any built-in class, provided that
the built-in class being overridden has not yet been loaded into the Class Loader's namespace.

Since the correct operation of the Java VM depends in part on the correct behavior of built-in
classes like java.lang.Class, java.lang.Object, and java.lang.Exception, a Class Loader that can
override the definitions of built-in classes can change the rules of the Java VM.

The third flaw is a subtle bug in the Verifier that opens a window of vulnerability for the class-
overriding trick. The details of this third flaw are a bit too sensitive to publish here. Suffice it to say
that the Verifier assumes that only certain types of objects can appear on the stack in some special
situations, and that class-overriding allows an attacker to violate this assumption.

The combination of these three flaws allows an attacker to create type confusion, which leads to a
full-blown security breach as usual.

Class Loading Take Four

One instructive thing about this attack is the role of class loaders. Several previous attacks have
exploited class loader problems, and this attack shows that the class loader design was still not
right, even after several iterations. Indeed, the problem of designing a correct class loader API is a
subject of research by Drew Dean at Princeton [Dean 1997], leading to a major portion of Dean's
Ph.D. thesis. The problems with class loaders are perhaps the best counter-argument to those who
say that Java's security problems have been superficial implementation bugs. Fixing these problems
is hard enough to merit a Ph.D. thesis!

This flaw is fixed in Netscape Navigator 4.5.

CHAPTER SECTION:20

Section 20 -- What These Problems Teach Us

The designers of Java tried to ensure that applets could not misbehave. Although they often claim
success (with apologies to Mr. Clemens) claims about Java's security have been greatly
exaggerated. Lately, the security message emanating from the major vendors has tended to
emphasize the idea of managing risks. That's good. We live with risks every day, and there is no
reason we can't live with mobile code risks, especially if we take on the risks with our eyes open
and some forethought about possible consequences.

All implementations of Java have had some rather serious security flaws. Even "mature"
implementations including Java 2 are not perfect. All known attacks have been detailed in this
chapter. So the question is what to do as we face these risks. Turning Java off is certainly one
solution, but not a very satisfying one. Java has lots to offer, and not using it would probably be a
poor decision in the long run. The new Java 2 security model, with its emphasis on policy, may
help make Java risks easier to manage. The trick is setting up a sound policy that makes sense for
your organization.

Each of the security problems that we discussed in this chapter can be implemented as an attack
applet. In fact, the Princeton team regularly creates attack applets in the lab to test the limits of
Java's vulnerabilities.4 Although rumor has it that attack applets based on the DNS bug and the
Princeton Class Loader attack have appeared on underground Web sites, there is no convincing
evidence that such attack applets have ever been used to crack a system on the Net. Nonetheless,
the main reason attack applets need to be taken very seriously is that the end result of a successful
attack is full system penetration; in other words, attack applets are capable of aiding a cracker in
taking over your machine. Once you no longer "own" your machine, a cracker can install a virus,
erase your hard disk, place Trojan Horses and logic bombs, or maybe just spy on you and steal your
credit card information, bank account number, business plans, or personal correspondence.

Java brings the formidable power of mobile code to the Web. Trading security for this power is a
tough pill to swallow, but a pill that's probably worth ingesting. Users want audio/visual
conferencing without cross-network eavesdropping. Users want loosely coupled computation for
things like factoring without cycle theft and denial of service. Users want games without Trojan
Horses. Users want save and restore for applet-based preferences without having their valuable files
stolen. Being security conscious, users can probably have what they want, without getting anything
that they don't need.

Securing Java:
Improvements, Solutions, and
Snake Oil
Now that we've covered hostile applets, let's turn to the positive side and talk about what can be
done to improve Java's security. Of course, security can always be improved by fixing specific
bugs, as Sun Microsystems, Netscape, and Microsoft have been doing. Again, removing a needle
from a haystack is easy once you've been stuck by it. This chapter focuses on more global issues
surrounding the design of Java. What sorts of high-level antidotes are there to some of Java's
security concerns?

This chapter has two major goals. The first goal is to discuss high-level concerns about Java and to
make some suggestions about how they could be addressed. Many of these suggestions carry over
from the original edition of this book. Since 1996, only a handful of our original suggestions have
been adopted. At the risk of being redundant, we raise them again. The high-level concerns include
programming language issues, formal analysis, applet logging, trust models, the distributed nature
of the security model, implementation versus specification, decompilation, trusted dialogs, and
policy management. Fixing the way that Java does some of these things will certainly improve
security. The second goal is to discuss a number of Java security add-on products that have
appeared on the market. A number of companies have introduced add-on products that are meant to
improve Java security by mitigating known risks. Vendors include Finjan, Digitivity (now Citrix),
Security7, and others. We take a quick look at each of these products and consider their goals in
light of objective reality.

Chapter Six Sections

1. Improving the Platform
2. Writing Safer Code: A Defensive Stance
3. Third-Party Solutions or Snake Oil?
4. Risks That Third-Party Vendors Can Address
5. Risks That Third-Party Vendors Can't Address
6. Assess Your Risks

Securing Java: Improvements, Solutions, and Snake

Oil
CHAPTER SECTION:1

Section 1 -- Improving the Platform

Most problems discussed in Chapter 4, "Malicious Applets: Avoiding a Common Nuisance," and
Chapter 5, "Attack Applets: Exploiting Holes in the Security Model," involve specific
vulnerabilities that have more to do with the current implementation of Java than with the Java
security model itself. There are, however, some general concerns raised by the computer security
community regarding Java. Many of these concerns are not new; in fact, we wrote about a majority
of these issues in 1996. We discuss what progress has been made since then (if any). This section
discusses some of these concerns and how addressing them would improve Java security.
 Language Issues

The first group of issues has to do with the design of Java itself. There are a handful of main
language issues to discuss. Note that these are criticisms of the language itself and not criticisms of
the current implementation. It may be too late to address these concerns now that the Java ball has
been rolling for a couple of years, but these issues still warrant discussion.

Public Variables
First among the language concerns is the fact that Java allows a kind of variable called a public
variable. These variables can be overwritten by a method from any Java class, no matter where the
class may have been defined or from where that class may have been loaded. Storing any data in a
public variable introduces a security risk.

Public variables are still writable across namespaces. This means that a public variable can be
overwritten by an applet that has come across the network. The global nature of public variables
opens an entire avenue of attacks.

Protected Variables
A similar concern is raised by protected variables and classes. The real problem is that the label
protected implies more security than it may actually offer. Protected variables and classes can be
accessed by the class that created them, the creator's subclasses, and classes in the same Java
package. Packages are a bit peculiar in Java (something we discuss later in this chapter). The result
is that code can declare itself part of a package and gain access to protected variables. Developers
should be aware of this risk and use protected variables sparingly.

Packages
A third language issue involves Java's package mechanism. Basically, packages in Java are too
weak. A variable or method can be declared as accessible to classes within the current package, but
there is no alternative way to control what sorts of other classes can access the variable. It would be
better to have more explicit control over who can access variables. The flexibility to choose two of
these classes, those four, and one from that other package to make up a new package would make
the modularity mechanism much more versatile.

Consider the following: The java.io.File class is dangerous, and untrusted applets have no business
accessing it. However, the same File class is required by code in java.lang.ClassLoader in order for
the Class Loader to load classes from the local disk. Since java.io.File is needed outside its
package, it must be declared public, making it accessible to applets. But making it public introduces
a serious security hole. The hole can be plugged by adding a few rules (some code) to the Security
Manager (or the Access Controller, as the case may be). As these parts are built by the browser
vendor (or some other Java application writer), such a solution is generally not very reasonable.

It would be better to have some way for java.io.File to be accessible to the java.io and java.lang
packages, but not to any other code. Doing this would create a stronger package system in Java.
In addition, the way membership in a package is declared is somewhat strange in Java. Most
languages with package-like modularity use a single file for each module, outlining which code is
in the module and who is allowed to access the module. The owner of a module can then easily
control who is allowed to use code and variables in the module. In Java, there is no single
declaration of a module or a list of members having access to the module. Instead, each class itself
declares which package it belongs to. That means that an external mechanism (such as the Security
Manager or the Access Controller) must decide whether partially trusted code should be allowed to
declare itself a member of a particular package. Because the package system is more complex than
it needs to be, there is more room for error than with a more typical setup.

Byte Code Representation

The next programming language critique is more abstract: Java's byte code specification is not
optimal. As an intermediate representation between the Java source and the machine code of the
platform on which Java runs, byte code plays an important role. We believe there are better ways to
represent the same sort of platform-independent code.

One construct, called Abstract Syntax Trees (AST), would be easier to type check than existing
Java byte code. ASTs would greatly simplify global dataflow analysis, which would speed up the
Verifier and reduce the odds of a Verifier bug. That's because the current Verifier must
painstakingly deduce information that ASTs have built directly into them. ASTs also have the same
semantics as the source languages they represent. That means there is no need to question whether
the intermediate representation is more powerful than the source language. By contrast, Java byte
code semantics are different from Java source code semantics. Who can guarantee that Java byte
code is constrained in similar ways to the Java language itself?

If you're at a loss imagining why that matters, consider that some aspects of Java security depend
on Java's semantics and not on byte code semantics. Does that mean it may be possible to do things
directly in byte code that a Java compiler would, for security reasons (or other good reasons), not
allow? Unfortunately, the answer is yes. For details on this issue, see page 196. In any event, since
ASTs have a compilation speed (source to AST) comparable to byte code compilation speed
(source to byte code), why not use ASTs?

These and other language issues are discussed in greater detail in the Secure Internet Programming
team's early paper, "Java Security: From HotJava to Netscape and Beyond" [Dean et al., 1996]. If
you are interested in learning more about such things, the article is available on the Web
atwww.cs.princeton.edu/sip/pub/secure96.html.

Dynamic Class Loading

Class loading has always been a problematic issue for Java. In fact, even though class loading has
been redesigned and supposedly fixed in every successive JDK, each implementation has included
at least one serious security flaw. A recent Java security hole, discovered in a beta version of Java 2
in 1998, was yet another problem with class loading (see Chapter 5 for details).
In Chapter 2, "The Base Java Security Model: The Original Applet Sandbox," where class loaders
are introduced and discussed in some detail, we point out that there are really two functions
performed by class loaders:

1. locating and fetching byte code

2. managing namespaces.

There is no reason these two capabilities need to be combined into a single class. In fact, some of
Java's more serious security holes could have been avoided if class-loading architecture had
initially separated the two functions. The culprit in many security problems has been in defining the
namespaces seen by different classes and how the namespaces relate to each other.

As the approach to class loading has changed throughout Java's short life, class loading has mutated
from a completely extensible architecture (which was dangerous from a security perspective), to a
system in which only trusted code could create a Class Loader, and back to a system in which
untrusted code might once again be able to safely create a Class Loader (that is, if it follows a
stringent set of rules). If you decide to create a Class Loader of your own, it is best to change only
those aspects of class loading related to locating and fetching byte code. Avoid changing the
namespace structure if at all possible.

For more on the complications of class loading and how to fix them, see Drew Dean's doctoral
thesis [Dean, 1998]. As we said before, class loading is a perfect example with which to counter
claims that Java's security problems are all related to superficial implementation bugs.

Can Java Be Proven Correct?

Our previous discussion of ASTs and the current byte code representation leads directly to the next
topic: formal verification. That's because any questions of provability are compounded by having
two languages with separate semantics to understand (Java source code and Java byte code).
Formal verification involves proving, in much the same way that a theorem is proven in
mathematics, that a program does what it is supposed to do or that a programming language has
certain properties such as type safety. This is a laborious process, to say the least.

There are many sorts of formal analysis Java could undergo. The security model itself (if
formalized) could be analyzed. The Java source language could be formalized in a specification,
then shown to be valid. The same thing could be done for Java byte code. In addition, a better-
specified formal relationship between Java byte code and Java source code could be worked out.
The Java VM could also be formally verified.

Computational Logic, Inc. (CLI), Schlumberger, and JavaSoft collaborated in 1997 to create a
formal model of a portion of the JVM. The model was built in Common LISP and provided some
formal analysis capabilities. The model performs extensive runtime type-safety checks, something
that the standard VM does not do (the standard VM relies on the Verifier to perform many type-
safety checks instead). CLI focused on Card Java (see Chapter 8, "Java Card Security: How Smart
Cards and Java Mix"). It appears that CLI is not planning further formal analysis work. For more
information see: www.cli.com/software/djvm/index.html.

Formalizing the Security Model

To this day, Java still has no formal security model. The complete security policy has never been
specified at a sufficiently high level for current versions of the language. As a group of security
researchers once said, "A program that has not been specified cannot be incorrect; it can only be
surprising" [Young, et al., 1995]. It is not possible to determine just what secure means without a
creating a formalized policy. Furthermore, a particular implementation of a nonexistent policy
cannot be properly verified.

Some progress was made toward this goal in a report commissioned by Sun back in 1996. The
report, entitled Security Reference Model for JDK 1.0.2, explained (in informal English) Java's
implicit security policy (at least for the base security sandbox described in Chapter 2) [Erdos, et al.,
1996]. The SRM is available through www.javasoft.com/security/SRM.html. Creating the SRM
was a useful exercise; unfortunately, any utility provided by the SRM was caught in the Internet-
time cross fire. The SRM is completely out of date. Given the rigorous security demands of
electronic commerce, documents like the SRM should be demanded by organizations using
consumerware in their security-critical systems.

Progress on the formalization front has also been made by programming language researchers (see,
for example, [Drossopoulou and Eisenbach, 1998; Stata and Abadi, 1998]). Work on the soundness
of Java continues.

Analyzing Java Source

The Java source language is powerful and includes a whole host of features. Only recently has any
sort of specification of the language appeared. Given a complete specification of Java source
semantics, a formal analysis can be completed. This work is currently under way.

Analyzing Byte Code

Java byte code plays a critical role in the way Java works. Some progress has been made with
regard to formalizing byte code semantics with the release of a specification for the VM [Sun
Microsystems, 1996b] (also see [Venners, 1998]). Given a sufficiently detailed specification, it is
possible to begin work on proving that the VM and Verifier systems are implemented properly.
Preliminary work on testing Verifier implementations has been done by the Kimera Project at the
University of Washington (for more on the Kimera effort, see Verifying the Verifier in Chapter 5).

Comparing Byte Code and Java Source

Showing how Java byte code behaves in relation to Java source code was impossible without a
semantics for both. Now that we have two specifications, we can determine whether or not byte
code is more powerful than Java source code. Are there things that you can do with byte code that
you can't do through Java source? Unfortunately, the answer is yes. The Princeton team has
discovered at least one instance in which it is possible to create byte code for an activity that is not
allowed when going through a Java compiler. Other efforts to probe byte code functionality include
the University of Washington's Kimera Project and Mark LaDue's malicious applets. Byte code
banditry is as potent an approach today as it was in 1996.

Analyzing the Java VM

One problem affecting formal analysis of Java implementations is the size of the Java system. With
tens of thousands of lines of code, Java raises critical assurance flags. Making certain that each of
these lines of code does not introduce subtle vulnerabilities requires significant security analysis.
Only a bit of this sort of analysis has been performed.

It is beyond today's technical capability to formally verify any piece of code in excess of a few
thousand lines. This means that because of its size, Java is not amenable to formal proof of
correctness. However, it may well be worth the effort to formally prove some aspects of Java's
specification correct. The first targets should probably be the core of the VM and other security-
critical pieces of the JDK, such as Class Loaders and Security Managers.

Software Engineering

Many bugs have been found in various sections of the Java code. It is unlikely that security-critical
code is bug free. Security vulnerabilities are often the result of buggy software. It is difficult
enough to deal with bugs in standard code; bugs in security-critical code are much more serious.

This problem requires sound software engineering. That Java programs will be built out of
prefabricated components will make any security bugs much more serious. Many different sites
may end up using such a component that turns out to have a security problem. Not only will people
liberally borrow security-impaired code snippets from each other, they will also begin to reuse
entire classes of flawed code. Such code flaws will be increasingly difficult to isolate. Perhaps
software engineering will develop a new approach that avoids such potential pitfalls. In any case,
Java will continue to have an effect on what the future deems state of the art.

To Log or Not to Log

The next concern involves something very simple: keeping track of what Java does on your
machine. One universal capability that computer security experts rely on, no matter what the
platform involved, is logging. Often, the only way to reconstruct an intrusion is to carefully and
painstakingly read the associated log files. Of course, such detective work is not possible in an
environment lacking log files. Logs provide several benefits:

• They allow the victim to determine what damage was done.

• They provide clues about how to prevent similar attacks.
• They provide raw data for many intrusion detection approaches.
 • They provide evidence for possible legal or administrative proceedings against the
perpetrator.

Java still has no logging capability (although as we shall see later in this chapter, a number of add-
on products provide this). It is impossible to track which applets were loaded and run, as well as
what those applets might have done. The most fundamental things that should be logged are file
system and network access. Simply capturing these data would give system and security managers
a chance to see what sorts of access were involved in an intrusion. File system access logging alone
would help system managers protect files that Java crackers were accessing in their break-in
attempts. It would also be good to capture applet byte code for analysis in case an applet ends up
doing something hostile. It is often easier to recover from an intrusion if you know what caused it
and what happened during the event.

Chapter 4 examines how an applet can delay its processing until a later time. Given that applets can
do this, logging becomes even more important. An especially crafty hostile applet can wait until
some other Web site becomes the main suspect before doing its dirty work. It won't be surprising if
the most hostile applets turn out to be the craftiest. Tracking byte code would give system
managers the ability to at least verify the function of each applet that may have been involved in an
attack.

One of the lessons emphasized in the book Takedown is that without a log file, it is impossible to
prosecute computer criminals [Shimomura and Markoff, 1996]. Without a log file, you have little
legal recourse in the event of a system break-in. If your site is hit by an attack applet today, erasing
critical information, you can't do anything about it, even if you know the culprit. Applet logging is
an essential security feature that should be made available immediately.

Who Do You Trust?

Early versions of Java were built without technological help for making privilege decisions. Since
1996, things have changed significantly; so much so that this book required a complete
revision. Chapter 3, "Beyond the Sandbox: Signed Code and Java 2," discusses the impact of the
new privilege system defined by Java 2 on the Java security situation.

Not only is the VM itself infused with the capability to create and enforce privilege policies, but the
very primitives out of which the new system is constructed have been made available to Java
developers. Java now includes support for standard cryptographic algorithms, including SHA,
MD5, DES (at least in North America), and SSL.

Now what is needed is tools to create and manage security policies that include privilege decisions.
Java 2 offers fine-grained access control, but it does not offer a compelling tool for creating,
testing, and managing policy (see Appendix C, "How to Sign Java Code"). Lack of such
management tools is likely to slow the adoption of Java 2 functionality in the enterprise.
 Scattershot Security

One of the most common criticisms of early Java security architecture centered on how Java
spreads security functionality throughout the code. Unfortunately, the problem of scattershot
security has not gone away. Research at Princeton shows that security boundaries (between trusted
system code and less-trusted code) are crossed up to 30,000 times per second in a typical applet
[Wallach, et al., 1997]. Other evidence can be seen by the effort that Sun undertook when changing
the JDK 1.2 API from the beginPrivileged()/endPrivileged() syntax of beta3 to the doPrivileged()
syntax of beta4. Over 250 changes were required in the Sun reference VM implementation to make
the change.

Reliance on a scattershot architecture means that security depends on many different parts working
together properly. There is no centralized security system; no single source for security approval.
Java implements security features through dynamic type checking, byte code verification, class-
loading restrictions, and runtime checks performed by the Access Controller. Each resides in a
different part of the Java environment. Such an architecture depends on too many unrelated
functions. If all of the security-critical functions were collected together in one place, that aggregate
code could be more easily verified and analyzed. That simple step would satisfy some concerns
held by security experts.

Some of Java's security policies are dependent on the Java language itself. This is fine if all Java
byte code must be created by a Java compiler, but what guarantees does anyone have that byte code
has been generated by a Java compiler that plays by the rules? There are none, nor should there
ever be. There are compilers now in existence that turn Ada and C code into Java byte code. To
take such third-party byte-code development efforts away by legislating a particular compiler
would go against the spirit of the language.

The problem is that the Virtual Machine interpreting Java byte code may allow more functionality
than it should. More explicitly, there may be more functionality built in to the byte code than
security would dictate (see Figure 6.1). If the Java compiler never creates byte code capable of
exploiting such features of the VM, then the architecture would seem to remain safe. Since no one
has control over who and what creates Java byte code, system managers should not rely on such a
false hope. Someone could write a compiler able to create byte code that seems valid to the VM but
breaks rules ordinarily enforced by the Java compiler. Or, someone could create byte code through
any number of other means; for example, direct creation with an editor, or creation with a Java byte
code assembler (like Jasmin, see www.isbe.ch/ ~wwwinfo/sc/cb/tex/jasmin/guide.html).

Figure 6.1 If Java byte code is more powerful than

Java source code, then the extra functionality in byte
code is dangerous.

There is some evidence that this is the case.

One somewhat inefficient (but interesting) solution to this problem has been suggested by Andrew
Appel of Princeton. He suggests checking byte code by first decompiling it to Java source, then
recompiling the source to byte code. If a compiler you trust does not complain during
recompilation, then the original byte code is equivalent to some Java source program, and hence
must obey the rules of the Java language. This process is slow, but in certain security-critical
instances it pays to be paranoid.

Decompiling Java Byte Code

Although decompilation is not a traditional concern of security experts, it does have some
interesting twists in Java. It turns out that one of the side effects of Java byte code's clarity is that
byte code is very easy to decompile. This means that given a .class file, it is possible to
automatically reconstruct reasonable source code. (Of course, it is also possible to decompile x86
object code as well as any other executable code. Java is not alone in its exposure to
decompilation.)

The JDK comes with a weak decompiler as one of its standard tools, but much better decompilers
are available on the Web. In the early days, the best was the Mocha decompiler, which has since
become obsolete. A good decompiler to consider now is the SourceAgain Decompiler fromAhpah
software.

Decompilation is relevant to security for a couple of reasons. The first reason is that businesses
interested in using Java as a development language will need to consider the existence of
decompilers before they distribute Java .class files. It probably won't be possible to sell something
if making knock-offs turns out to be incredibly easy. Fortunately, some companies now distribute
Java source code obfuscators (watch out for snake oil solutions in this domain, however). The end
result of obfuscation is that although a .class file will decompile into valid Java, that valid Java
won't be very readable by humans. One caveat: Obfuscation certainly makes decompilation more
difficult, but it won't protect your code against a determined adversary.

Even if your code is subject to decompilation, you can still get some protection by copyrighting the
code and legally defending the copyright in court if necessary. This is not an ideal solution, but it's
better than nothing.

A closely related issue involves protecting secret or otherwise sensitive information in a piece of
mobile code, such as cryptographic keys. A good guideline if you are developing mobile code in
Java is not to include any secrets in the code. An applet that carries a password or a crypto key in
its code is amenable to hacking. Anyone who runs such code can get access to its secrets. More on
this issue can be found in Chapter 7, "Java Security Guidelines: Developing and Using Java More
Securely."

There is a third security concern related to decompilation. Given a piece of Java source code
obtained by decompilation, a cracker can better analyze the program for weaknesses that could be
exploited to break it. This would allow an attacker to attack a Java program more intelligently.
Applications like Netscape's Java VM are susceptible to this sort of source-related attack. Crackers
like to have code to poke around with. Furthermore, an attacker could build a very realistic Trojan
Horse program that looks almost exactly like the original. Like its ancient counterpart, a modern
Trojan Horse is a program that appears to be one thing at one level, but turns out to breach security
at another.

Trusted Dialogs and Meters

In an earlier chapter, we raised the idea of providing trusted dialog boxes for critical actions like
file I/O, or critical measurements such as CPU cycles used. These dialogs would provide an
important monitoring and feedback mechanism to Java users.

Providing a trusted set of dialogs (that cannot be spoofed) for things like file access seems like a
good idea. However, with any such user interface, one of the key goals must be to minimize user
involvement in security. Most users don't read their dialog boxes before they click OK (recall the
dancing pigs problem). Sophisticated users should probably have some control over their security
policies, but the less intrusive this control is, the better. Management issues like these are taking on
more importance as Java security evolves from the base sandbox into the Java 2 model in which
security policy plays such a central role. Centralized management is especially appealing at the
enterprise level, and much work remains to be done to develop policy management tools and
techniques.

Far from being in the way, a set of resource access indicators that cannot be forged would be a
welcome addition to Java from nearly every user's perspective. This set of instruments could allow
a user to track system resources such as CPU cycles, or microphone use. Some third-party vendors
offer monitoring capabilities like the ones mentioned here. What is not yet clear is how well
protected against spoofing these meters are. A meter that can be made to display false system
information on behalf of an attack applet is potentially more dangerous than having no meter at all.

Management Tools

Java 2 is not going to be adopted overnight; it is a complicated system, and utilizing it to its full
potential will be a complicated undertaking. As we have said before, we think it is likely that
signed mobile code and complex security policy will first be adopted for the intranet. Only after
organizations and enterprises have their ducks in a row internally will they begin to experiment
with complex security policies that make use of the Internet/Web.

A set of tools for creating and managing policy, especially enterprise-wide, would go a long way
toward easing the adoption of Java 2. The existing tools being distributed with the JDK are
rudimentary at best, and hard problems like identity/certificate management have many remaining
open issues. (See Appendix C for details on how to use some of the existing code signing tools.)

The problem of policy management has existed for years in the security community. One
characteristic of the problem is that it does not scale well. A tool that may be adequate to managing
policy for one browser will probably not work well across a network of hundreds or thousands of
machines. This problem crops up in all aspects of security. One common way to get a handle on it
is to create a choke point at the perimeter (for example, at the firewall) and instantiate site-wide
policy there. Security vendors have been frantically working on policy-management tools for some
time, but work remains to be done. Ideally, a site-wide policy could be managed by a powerful tool
and would include mobile code policy.

Many security pundits anticipated that by now, a solid public key infrastructure (PKI) would have
been put in place; unfortunately, that is not the case. Java 2 would be much easier to adopt if the
PKI were already there. As it now stands, delays in PKI placement are likely to hamper systems
that rely heavily on code-signing. After all, if you have no idea who is behind an identity, how can
you possibly trust them? It is not clear at this point why any particular certificate authority deserves
your trust.

Java Antidotes

As can be seen from the laundry list of high-level concerns, Java security can still be improved in
many ways. Some of the most effective antidotes to Java security problems involve addressing the
criticisms raised here.

CHAPTER SECTION:2

Section 2 -- Writing Safer Code: A Defensive Stance

It is all well and good to look to the future and determine what might make a platform stronger,
but developers and managers charged with using existing JDKs won't benefit immediately from
this strategy. Are there things developers can do now to make their Java code more secure?
Fortunately, the answer is yes. Chapter 7 introduces 12 technical guidelines for writing Java code
more securely. Also covered in Chapter 7 are user guidelines.

CHAPTER SECTION:3

Section 3 -- Third-Party Solutions or Snake Oil?

Sun Microsystems and the licensees of Java who have created particular Virtual Machines have
done an admirable job implementing a complex, language-based security model. Of course no one
is perfect. We discuss several serious problems in detail in Chapter 5. In light of the problems
detailed there (a majority of which have been addressed as Java has grown up), is there a need for
third-party Java security vendors?
The answer is complicated. On one hand, if Sun and the other major vendors (including the largest
software organizations on the planet) can't do it right, how can someone else? One answer is that
Sun is too busy working on the entire Java platform to pay enough attention to security concerns
and that little companies specializing in security can do better. Just for the record, we don't believe
that is true. Sun and the other Java vendors behave in a manner that shows they are truly concerned
with security issues. On the other hand, different organizations have different goals for their
security solutions. Some may demand features that are not included in off-the-shelf Java VMs. The
implication is that special-purpose solutions that address particular risks are needed. If that's true,
there should be plenty of room in the market for third-party security vendors to get involved.

As long as such third-party vendors concentrate on mitigating particular risks, their products will
add value. However, many such vendors are making overblown claims about what they can do to
enhance security. In this section, we want to clarify which risks can reasonably be addressed by
these vendors and which cannot.

In order to set the stage for a discussion of risks, we'll begin with a brief introduction to security
solutions that have been offered by third-party organizations.

Finjan

In the interest of full disclosure, we should note that both authors are members of Finjan's
Technical Advisory Board. Our membership on Finjan's TAB does not constitute an endorsement
of the company or its products.

Originally based in Israel and now headquartered in California, Finjan Software, Ltd. was among
the first third-party companies to address mobile code security issues (www.finjan.com). Finjan got
off to a rough start when some of its early marketing involved the use of scare tactics and what
might be called the "Chicken Little" approach to educating the public (and potential clients) about
security risks. Its approach to marketing has since matured significantly.

Finjan offers a couple of products created for both Win32 and Unix platforms. The first,
SurfinShield, is meant to be a browser-level application firewall. The idea is to add some
capabilities to the browser to help with mobile code management. SurfinShield comes in several
flavors. The second product, SurfinGate, is a firewall product that attempts to identify and
categorize mobile code as it arrives at the firewall. SurfinGate carries out some form of content
inspection that attempts to peer into the inner workings of Java applets (statically). SurfinCheck is a
less-powerful version of SurfinGate.

Finjan has had an interesting time in the mobile code security space and has been the target of some
particularly scathing criticism. Mark LaDue is especially outspoken about his concerns
(see www.rstcorp.com/hostile-applets/rube.html and www.rstcorp.com/hostile-
applets/drowning.html). Fortunately, Finjan has taken these criticisms to heart and seems to be
working diligently to provide better security products to its customers.
 Digitivity (Citrix)

Digitivity, the commercial arm of APM, Ltd. in Cambridge, England, was recently acquired
by Citrix. The Digitivity approach to mobile code management is particularly sound from a
technical perspective. The idea is to identify and route all mobile code to a central server, where it
is then executed. This works because all GUI traffic is sent (by specialized protocol) to be
displayed on the client browser that originally requested the code. There are two main reasons to
centralize the execution of code like this: 1) to expose only the server, what Digitivity calls the
CAGE, to possible attack; and 2) to better manage the behavior of mobile code by knowing the
exact configuration of the mobile code platform. As we know, different Java VMs behave
differently even when they are running the same byte code. If you know for certain which VM a
piece of code will run on, it is easier to develop and manage custom enterprise solutions.

There is an inescapable irony to the Digitivity CAGE model. The very idea that spawned mobile
code systems like Java is the idea of taking advantage of distributed systems by running code on
client machines instead of running code on something like a centralized Web server. The CAGE
model centralizes Java code and works counter to the original Java concept. Still, there are
sometimes appealing reasons to centralize the execution of code, whether it is potentially dangerous
or not.

It is not clear how the CAGE approach will adapt to the new Java 2 security model. The main
strength of the CAGE approach is that the mobile code runs on a special machine that simply is not
allowed to access user files or initiate network connections under any circumstances. As soon as
partially privileged applets enter the picture, this simple approach goes out the window and the
CAGE machine faces many of the same problems as existing VMs.

Security7

Security7 is an Israeli company with offices in the United States. U.S. sales for Security7 are based
in Woburn, Massachusetts. The Security7 approach to mobile code security is to inspect HTTP
traffic coming in on all ports. Its SafeGate product requires Windows NT and is most effectively
implemented on a standalone box that acts as a proxy server for all HTTP traffic. The idea is to
enhance the existing firewall approach with the HTTP filtering system, which is built in to the OS
as a device driver. The SafeGate product includes the usual mobile code management capabilities
and logging.

It appears that Security7 has been active in spreading FUD (fear, uncertainty, and doubt) among
potential customers through an organization calledWithinReach. This strategy is reminiscent of the
early days of the antivirus industry in which some unscrupulous vendors were rumored to have
created and released actual viruses. These days, a code of ethics has been developed within the
antivirus community that does not permit the FUD strategy. Unscrupulous antivirus vendors are
quickly stamped out by more scrupulous vendors.

It is pretty obvious that Security7 and WithinReach are closely affiliated (in fact, Security7 has
openly admitted this). Assaf Arkin, a Security7 customer support manager, is also the
administrative and technical contact listed in the DNS records of WithinReach. Other evidence
includes the fact that one of the hostile applets hosted by WithinReach was signed with a digital
certificate registered to Richard Kosinski, Security7's vice president of marketing. The signature
has since been changed. InfoWorld broke a story about the relationship between Security7 and
WithinReach in late August 1998.

Until recently, the WithinReach site hosted a number of hostile applets, including a port of the Cult
of the Dead Cow's famous Back Orifice loader to Java. None of the applets on the site exploits any
security holes in Java; instead, the applets require permission to be granted by the user in order to
do anything harmful. That is, the applets are signed and request special permission to step outside
of the sandbox. The applets thus serve to emphasize the role that a human can play in mobile code
security. In this sense, the WithinReach applets may provide an interesting service. Nevertheless,
we do not believe that it is ethical for third-party security vendors to create security problems for
their products to address. Fortunately, Security7 seems to share our opinion now, and the
WithinReach Hostiles have been removed.

eSafe

eSafe is a Seattle-based company that also happens to be founded by an Israeli. eSafe offers two
products: Protect, a personal firewall, and Protect Gateway, a firewall-level filtering system. Protect
works by placing resource limitations on mobile code. The idea is to create a sandbox similar to the
Java sandbox within which all mobile code must run. The Protect Gateway product is a filter meant
to be added to an existing firewall that scans several protocols for mobile code. The filter includes
blacklisting capability. eSafe products also include antivirus capability in addition to addressing
mobile code security.

The Princeton Secure Internet Programming Team's JavaFilter

The Princeton team distributes a black-listing/white-listing Class Loader for JDK 1.0.2 that can
automatically allow or disallow applets to be loaded from particular sites. The filter replaces Java's
normal AppletClassLoader with a new implementation that checks URLs and policy before
fetching code. Although this is not a commercial product, it is certainly a third-party add-on that
some organizations may find useful. Seewww.cs.princeton.edu/sip/JavaFilter for more information.

ICSA's Mobile Code Security Consortium

Regardless of its misleading name, the International Computer Security Association is a for-profit
business that licenses the use of trademarked "certification" logos. (Perhaps its name is a perfect
example of spoofing?!) ICSA was known as NCSA until 1998 when it changed its name from
"National" to "International." As part of its business, ICSA creates consortia of security vendors
interested in particular issues. The consortia exist to hash out self-imposed certification criteria that
can be used as a marketing edge by vendors. ICSA's business strategy is to get vendors to pay to be
in a consortium (in which vendors create certification criteria) and then pay to be certified on a
subscription basis. Consumer purchasing decisions are often swayed, for whatever reason, by ICSA
certification marks.

One of ICSA's best-known certification products involves certifying firewalls. The firewall
certification system makes an interesting case study. As we understand it, ICSA's firewall
certification process boils down to running a penetration test against one instance of a firewall
product as configured according to printed instructions from the firewall vendor. If a firewall
product passes the tests, the vendor is allowed to place an ICSA certification stamp on its box (and
use it in its marketing literature).

A potentially fatal flaw in this firewall certification scheme is that firewalls are not really black-box
systems; instead, they are programmable systems that are only as strong as the rules within them
defining security policy. Rules in a typical firewall say things like "only allow machines having an
IP address within the proper range to send HTTP traffic through port 80." The flaw in the ICSA
certification scheme becomes obvious considering that what is being certified is a particular
configuration of a firewall. The problem is that firewalls are particularly easy to misconfigure, and
the certification scheme says nothing about how difficult it is for an end user of a firewall to
configure it correctly. Firewall purchasers may be misled into thinking that buying an ICSA-
certified firewall guarantees some minimum level of security. That is not the case. For a stark view
of the ICSA firewall certification process, see firewall guru Marcus Ranum's page
at www.clark.net/pub/mjr/pubs/fwtest/index.htm. On the flip side of the coin, the firewall
certification process that ICSA offers is said to be a discriminator; that is, some firewall products
are unable to pass the security tests even when configured according to the instructions! So the
certification has at least that benefit to offer.

We raise the firewall certification issue because ICSA recently announced the formation of a
consortium meant to address mobile code security. Current members of the consortium include
Digitivity, eSafe, Finjan, Internet Security Systems, Security7, and Symantec (among others).
Strikingly, the major vendors of security-critical platforms for mobile code (Sun, Netscape, and
Microsoft) are missing from the list. The question raised earlier in this chapter about what third-
party vendors can offer (as opposed to the platform architects) comes to mind.

It is likely that the mobile code consortium will choose to invent a set of self-imposed standards (a
certification process) for itself. The question to ask is, what will this certification amount to?
Developing a certification standard for the mobile code consortium is no easy task if it is to be done
properly. Without external review by experts, a mobile code security certification may not actually
mean anything. It is our hope that ICSA will take the opportunity to do things right.

CHAPTER SECTION:4
 Section 4 -- Risks That Third-Party Vendors Can
Address
As we mentioned in the previous section, there are a number of Java security needs that third-party
vendors can help to address. We discuss such needs here and also raise some hard questions that
you should ask vendors of such products if you're considering buying them. Perhaps
counterintuitively, some concerns included in this section are also covered in the next, which
discusses risks that can't be easily addressed. That's because the issues are complicated and can be
seen equally well from both points of view.

Logging

For a discussion of why logging is important, see page 194. The Java platform in most browsers
does not do an adequate job of logging mobile code. This is an area in which third-party software
can add real value. However, logging is actually trickier than it might appear at first blush.

What to Ask about Logging

The main thing to ask of any logging capability is, how well protected is the log file from being
overwritten, corrupted, or deleted? Attackers often cover their tracks by editing log files. Attack
applets of the sort we discussed in Chapter 5 could certainly change logs if they wanted to.
Accuracy is also a big issue for log files. It is important that logs collect proper data and can't be
easily mislead by a malicious process.

If vendors say that their products log all incoming byte code, you should ask how they can be sure.
This is roughly the same issue we describe next when we talk about applet isolation. After all, if
code can slip past your firewall, how can you be sure it can't slip past the logging facility?

Applet Isolation (and Identification)

A common approach to security for many companies includes the installation of sacrificial lamb
machines in a DMZ (terminology borrowed from military speak). Things like Web servers and FTP
servers are well-situated in DMZs because they are common targets of attack with many well-
known and commonly exploited security holes. The idea is to create a subnetwork behind the
firewall but isolated from the rest of your network. That way, if the servers are hacked, your site is
still not completely compromised.

Isolating untrusted code to a server in the DMZ may be a good idea, depending on your mobile
code risk analysis. If mobile code turns out to be hostile and aims an attack at the server it is
running on, much less is lost if the server is a sacrificial lamb in the DMZ. Some third-party
solutions offer this capability.
What to Ask about Applet Isolation
One interesting question to ask vendors of isolation products is, how well do they identify applets
in the first place? It turns out that trapping all applets is not an easy problem. Early approaches
relying on scanning port 80 traffic for the <APPLET> tag have been shown to be inadequate
(something we mentioned in 1996). One of the most thorough treatments of this issue can be found
in a paper called Blocking Java Applets at the Firewall [Martin, et al., 1997]. The paper points out
problems with standard blocking methods and discusses the technical difficulties of blocking.

Another hard question for vendors involves the use of encrypted channels for mobile code delivery.
Most browsers have built-in capability to create an SSL connection between the Web server and the
client browser (see Chapter 3). Once an SSL connection exists, all traffic between the browser and
the server is encrypted. That means a firewall will not be able to parse the traffic as it goes by.
What a firewall can't see, it certainly can't identify. Ask vendors what they do about encrypted
communication in their identification approach. If they can't scan SSL traffic, they're in trouble
because an attacker can defeat their scanner by changing http to https in the attack page's URL.

Black Listing

The idea of creating a list of applets known to be hostile seems like a really good idea. The key is to
identify hostile applets by something less easy to change than their name or the URL from which
they came. Some systems use hashing algorithms like MD5 to create a database of applets on a
black list. Others offer the ability to black list entire Web servers.

Assuming applets can be identified in the first place, black listing will work. One problem is that it
is almost trivial to make a hostile applet that changes its own byte code (in a very simple way) each
time it is requested from a server. Mark LaDue's HAMGen applet does this.
Seehttp://www.rstcorp.com/hostile-applets/Rube/HAMGen.java. HAMGen stands for Hostile
Applet Mutation Generator.

What to Ask about Black Listing

It should be clear that black listing by itself does not provide adequate security; in fact, all by itself,
black listing is darn close to useless. It's too easy to make trivial changes in a malicious applet (a
process that can be automated at the Web server end) to thwart almost every black-listing scheme.

Nevertheless, black listing is so cheap to implement that it may make sense to do it anyway,
especially if you enlist the help of a Class Loader. Using a system that blacklists known hostile
code may be worthwhile even if it only stops the occasional naïve attack.

Trusted Dialogs and Meters

We discussed trusted dialogs and meters earlier in this chapter on page 198. Such dialogs are
particularly useful to managers whose policy involves having users keep an eye out for unusual
activity. They are also useful to more savvy users who know about mobile code. The problem with
most VMs today is that they give no indication that anything special is happening when mobile
code is running, be it Java, JavaScript, or ActiveX. The behind-the-scenes approach gives the user a
more seamless Web experience, but it makes the job of writing a hostile piece of mobile code that
much easier.

There is a downside to providing dialogs and meters-the user can become overwhelmed with
security-related dialogs leading to the "cry wolf" phenomenon. It's easy to click OK over and over,
especially when you're annoyed. Trusted meters and dialogs would best be as nonintrusive as
possible.

What to Ask about Trusted Dialogs and Meters

A particularly hard question to ask is, how can dialogs and meters avoid the spoofing problem? In
other words, how can you be sure that the "meter" you see on the screen is real and isn't really
being drawn by a hostile applet? If these things can't be trusted to tell you the truth, then they're not
worth the pixels they're made of. Turns out this problem is a tough one. A nontrustworthy meter is
potentially worse than no meter at all.

Platform Proliferation

One of the most successful Java marketing phrases is "write once, run anywhere." A number of
parodies of this phrase have been floated; among the best is "write once, test everywhere." The
problem is that all Java VMs don't always do the same thing given the same byte code. Arbitrary
behavior of similar code in different versions of a language is a problem that Java was supposed to
solve.

This problem can introduce real security risks. Consider, for example, that the attacks described in
Chapter 5 still work against old versions of browsers out there. Unless you have an up-to-date
browser, you may be surfing dangerously. Now imagine that you are the administrator for a large
site with hundreds of users. How likely is it that all your users are using up-to-date browsers? How
likely is it that they're even using browsers from a single vendor? Some sites address this problem
by mandating the use of a particular (often out-dated) browser; however, impatient power users will
download their own free browser and install it themselves.

Using a move that mirrors the Applet Isolation idea discussed previously, it is possible to address
this risk by forcing all applets to run on a central server. That way, you can guarantee things about
the environment in which mobile code will run.

What to Ask about Centralized Server Solutions

A big issue for all centralized systems is scalability. How many users can bog down a central server
before it chokes? How big a server do you need? What protocol is used to direct GUI traffic
between the server and the clients running on normal browsers? How well protected is that protocol
against simple denial-of-service attacks? And given the difficulties in detecting incoming applets,
how can you be sure that all applets are being redirected to the central server?

Policy Management
Finally, we come around to policy management again. Given the state of existing tools, there
should be some serious demand for good policy management systems.

Note that the management issue is not unique to security. Managing large networks of many
machines is a daunting task, and the tools are not yet good enough. Consider the problem of
keeping all the software on hundreds of PCs up to date. To some extent this is a problem introduced
by the complications of distributed systems. Security in merely one aspect of this broader
management problem.

What to Ask about Policy Management

Policy management is as much a business management problem as it is a technological problem.
Human factors enter the picture, such as, who is allowed to set policy and who can edit it? An
excellent goal to strive for is to put in place a site-wide security policy that speaks to all security
issues. Much work remains to be done.

CHAPTER SECTION:5

Section 5 -- Risks That Third-Party Vendors Can't

Address
It seems that there is indeed room for third-party vendors to get involved in the mobile code
security business. However, many mobile code security issues cannot be addressed in a trivial
manner. In this section, we raise a number of tricky issues that are harder to deal with than they
seem at first. Many of these issues are reflected in the questions to ask from the previous section.
Keep these points in mind when you are shopping for mobile code solutions.

Identifying Applets Entering the System

As we pointed out in 1996, identifying applets is much harder than simply scanning for the
<APPLET> tag in port 80 HTTP traffic. The problem of encrypted communication using
something like SSL is especially hard to deal with. (Similar problems crop up with encrypted mail
that includes mobile code.) The only completely guaranteed way of identifying all mobile code
before it runs is by stopping it as it enters the VM. Your browser certainly knows when it
encounters a Java applet, and it is probably in the best position to do something about it.
From a management perspective, identifying mobile code at the firewall has more appeal than
trying to identify it on every desktop in an organization. This is especially true of organizations in
which employees do not follow security policy. However, the problem is nontrivial. Ask hard
questions about systems that claim to be able to stop all mobile code. Make sure the answers deal
with all ports, multiple protocols, and encrypted connections.

Killing Applets

Some vendors will tell you that their products allow the user to kill a running applet if it is
misbehaving. Although many people are surprised to hear it, there's really no effective way to kill
an applet if the applet doesn't want to die. The problem is that the only way to kill a Java thread is
to throw an Exception at it, and the thread can simply catch the Exception. See page 125.

You might think that this problem can be solved by creating a new kind of Exception that cannot be
caught, but that won't solve the problem either. The difficulty is that the try/finally statement in the
Java language allows a program to do an arbitrary amount of "cleanup" work before it finishes
running. In fact, the "cleanup" code can simply carry on the work of the thread you wanted to kill.

An even stronger way to try killing an applet is simply to stop all of the applet's threads, not even
letting them execute their cleanup code. This doesn't work either, in general, because the stopped
threads may be holding locks, and the VM may be unable to make progress without the locks.
Revoking the locks while the victim threads are in the middle of using them only makes things
worse, leaving the VM in a potentially inconsistent state.

This gets pretty complicated, but the bottom line is that there's no way to safely kill a thread that
doesn't want to die. And if an applet thread is trying to cause trouble, why would it willingly let you
kill it?

Of course, you can stop all running applets by killing the VM or browser entirely, but that's a pretty
drastic solution, and you don't need some fancy tool to let you do it.

Scanning Applets

Java has important dynamic properties. Because of Java's dynamic loading capabilities, it is not
possible to statically analyze a Java class completely. Some analysis will always have to be put off
until runtime. The fact that the Verifier has a runtime phase is no accident (see Chapter 2).

Java's dynamic capabilities do not bode well for systems that claim to be able to scan applets for
potentially harmful behavior. After all, if the code is not all there (or if it includes dangling
references to not-yet-loaded code), how can you scan it? Static analysis is not sufficient to ensure
security, and short of firing up a VM, that's all you can do.
Another problem is that scanning works according to the assumption that attack code can be
categorized as such. We have seen (or written) plenty of attack code in the lab. It is not the case that
this code can be identified as attack code before it does its dirty work. For example, one of the
attacks described in Chapter 5 can be written as an applet that carries out seemingly innocuous
type-casting operations, one after another. The casting actually implements the important part of a
type-confusion attack. Looking at the code, it would be impossible to tell that the applet is an attack
applet.

Many of the malicious applets written as demonstrations use very obvious techniques to carry out
their hostile activities. For example, early denial-of-service or monitoring applets redefined the
stop() method. This does not mean that every applet that redefines stop is malicious, nor does it
mean that each and every attack applet will do so.

Scanning for unknown malicious behavior is a very difficult task that is certainly impossible in
theory.

Trusted Dialogs and Meters

Providing security-related feedback to a user is a good thing, as long as the information is correct.
However, if a meter can be spoofed, you can bet that a hostile applet will do so. The spoofing
problem may be severe enough that it is best not to have meters. This may in fact be why Sun,
Netscape, and Microsoft do not include such feedback mechanisms in their implementations.

Ask yourself why you should trust a meter and how you can ensure that it is giving you the correct
information. Improving the VM's Security Model In the end, the most bang for the buck in terms of
security will come from Sun and the Java licensees who create the VMs and APIs. Compared to
creating a complete VM with added security mechanisms, improving the security situation by
adding on minor services is probably nowhere near as effective.

CHAPTER SECTION:6

Section 6 -- Assess Your Risks

In some sense, the entire purpose of this book is summed up by the phrase "assess your risks." Our
goal in writing this book is to make you aware of what is going on with Java security. That way,
you can make an intelligent, informed decision about what to do as a user, as a developer, as a
manager, or as a business decision-maker.

Each organization and individual must create their own strategy for developing, using, and
managing Java. The way to do this is to take a long hard look at the risks incurred through Java use.
If these risks turn out to be too much to bear, then you should probably reconsider being connected
to the Internet itself! Using Java is risky, but really not much more risky than simply being on the
Net.

Risk assessment involves understanding what it would mean if the data on your machine were
made public, what it would mean if your machine were to stop functioning, and what it would
mean if the performance of your machine were suddenly and seriously degraded. Risks differ
according to context. That means if you have more than one machine (and most organizations do),
it is likely that risk assessments for each one differ.

An intelligent Java strategy can only be made after understanding what you have to lose. If the
answer is "nothing," then there is no reason to worry about Java. If the answer is "the business,"
then perhaps a more comprehensive Java security policy should be put in place.

When you are considering your risks, make sure you don't discount the benefits of Java. Java is an
exciting and interesting technology that has lots to offer. Try not to throw out the good with the
bad.

Java Security Guidelines

Developing and Using Java More
Securely
Java security is important to Web users, system administrators, Java developers, and business
people. Sun Microsystems and others have worked hard to evolve a Java system with which to
create and use more secure code. Java is not immune to security risks, however. As we have seen,
designing and implementing a language-based security model is not easy, and mistakes are bound
to happen.

Given that there is no such thing as a 100-percent secure system (at least if we want that system to
do anything useful), how can developers create more secure Java code? And, given that Java
developers can't always be counted among the good guys, how can Web users tailor their Web use
to be more secure? These are the two major questions this chapter answers. We introduce two sets
of guidelines in this chapter: developer guidelines for creating more secure Java code and user
guidelines for avoiding risks when using Java. By establishing some simple security guidelines,
you can avoid most of the risks discussed throughout this book. Many of the user guidelines have
been touched on in other chapters. Here they are consolidated in a complete package. On the other
hand, the developer guidelines are completely new material.
 Chapter Seven Sections
1. Guidelines for Java Developers
2. Guidelines for Java Users
3. Guidelines Are Never Perfect

Java Security Guidelines: Developing and Using Java

More Securely
CHAPTER SECTION:1

Section 1 -- Guidelines for Java Developers

This section introduces 12 rules for writing security-critical Java code; 12 rules that all Java
developers should abide by. If you are charged with managing a gaggle of Java developers, or if
your business relies on the security of Java, make sure your developers follow these rules.

These rules have not been sugar-coated for mass consumption. They get fairly technical and require
broad knowledge of Java. Although experienced Java developers will understand all of the rules,
less-experienced Java developers may have a bit of homework to do. Nevertheless, these rules are
important and can make your Java code more secure.

The rules listed here were built on the experiences of many people who have generously discussed
their experiences in building secure Java code. We are particularly grateful to Andrew Appel, Dirk
Balfanz, Drew Dean, and Dan Wallach, of the Secure Internet Programming Team at Princeton, for
helping us understand these issues. Others who have contributed significantly to the behind-the-
scenes thinking that went into these rules include David Hopwood, Li Gong, and Jim Roskind.

The rules are based on much experience in hunting down Java security bugs, and on advice and
observations from people who write and review security-critical Java code for a living. Each rule is
designed to eliminate an unexpected "gotcha" that you might face.

Of course, security is an elusive goal, and following these rules certainly won't provide any
guarantee that your code is secure. It is easy to write insecure code that follows these rules. The
goal of these rules is not to guarantee security, but to eliminate certain kinds of security attacks that
you might not have thought of. If you follow these rules, certain kinds of attacks will be
impossible; other kinds will still be possible. So think of these rules as a first step. If you are
writing code that may be linked or run in conjunction with untrusted code, then you should
definitely consider following these rules.

Every attempt was made to keep the rules simple enough that you can treat them as a checklist to
be followed in mechanical fashion. That way, you can save your brainpower for other security
issues.
 Rule 1: Don't Depend on Initialization

Most Java developers think that there is no way to allocate an object without running a constructor.
This is not true: There are several ways to allocate uninitialized objects.

The easy way to protect yourself against this problem is to write your classes so that before any
object does anything, it verifies that it has been initialized. You can do this as follows:

• Make all variables private. If you want to allow outside code to access variables in an object,
this should be done via get/set methods. (This keeps outside code from accessing
uninitialized variables.) If you're following Rule 3, you'll make the get and set methods final.
• Add a new private boolean variable, called initialized, to each object.
• Have each constructor set the initialized variable as its last action before returning.
• Have each nonconstructor method verify that initialized is true, before doing anything. (Note
that you may have to make exceptions to this rule for methods that are called by your
constructors. If you do this, it is best to make the constructors call only private methods.)
• If your class has a static initializer, you will need to do the same thing at the class level.
Specifically, for any class that has a static initializer, follow these steps:
• Make all static variables private. If you want to allow outside code to access static variables
in the class, this should be done via static get/set methods. This keeps outside code from
accessing uninitialized static variables. If you're following Rule 3, you'll make the get and
set methods final.
• Add a new private static boolean variable, called classInitialized to the class.
• Have the static constructor set the classInitialized variable as its last action before returning.
• Have each static method, and each constructor, verify that classInitialized is true, before
doing anything. (Note: Constructors are required to call a constructor of the superclass or
another constructor of the same class as their first action. Therefore, you will have to do that
before you check classInitialized.)

Rule 2: Limit Access to Your Classes, Methods, and Variables

Every class, method, and variable that is not private provides a potential entry point for an attacker.
By default, everything should be private. Make something non-private only if there is a good
reason, and document that reason.

Rule 3: Make Everything Final, Unless There's a Good Reason Not To

If a class or method is non-final, an attacker could try to extend it in a dangerous and unforeseen
way. By default, everything should be final. Make something non-final only if there is a good
reason, and document that reason.
You might think that you can prevent an attacker from extending your class or its methods by
declaring the class non-public. However, if a class is not public, it must be accessible from within
the same package, and as we shall see, Rule 4 says not to rely on package-scope access restrictions
for security.

This advice may seem harsh. After all, the rule is asking you to give up extensibility, which is one
of the main benefits of using an object-oriented language like Java. When you're trying to provide
security, however, extensibility is your enemy; it just provides an attacker with more ways to cause
trouble.

Rule 4: Don't Depend on Package Scope

Classes, methods, and variables that are not explicitly labeled as public, private, or protected are
accessible within the same package. Don't rely on this for security. Java classes are not closed, so
an attacker could introduce a new class inside your package, and use this new class to access the
things you thought you were hiding. (A few packages, such as java.lang, are closed by default, and
a few JVMs let you close your own packages. However, you're better off assuming that packages
are not closed.)

Package scope makes a lot of sense from a software-engineering standpoint, since it prevents
innocent, accidental access to things that you want to hide. But don't depend on it for security.
Maybe we'll get sealed classes in the future.

Rule 5: Don't Use Inner Classes

Some Java language books say that inner classes can only be accessed by the outer classes that
enclose them. This is not true. Java byte code has no concept of inner classes, so inner classes are
translated by the compiler into ordinary classes that happen to be accessible to any code in the same
package. And Rule 4 says not to depend on package scope for protection.

But wait, it gets worse. An inner class gets access to the fields of the enclosing outer class, even if
these fields are declared private. And the inner class is translated into a separate class. In order to
allow this separate class access to the fields of the outer class, the compiler silently changes these
fields from private to package scope! It's bad enough that the inner class is exposed, but it's even
worse that the compiler is silently overruling your decision to make some fields private. Don't use
inner classes if you can help it. (Ironically, the new Java 2 doPrivileged() API usage guidelines
suggest that you use an inner class to write privileged code. That's one reason we don't like the
doPrivileged() API.)

Rule 6: Avoid Signing Your Code

Code that is not signed will run without any special privileges. And if your code has no special
privileges, then it is much less likely to do damage.

Of course, some of your code might have to acquire and use privileges to perform some dangerous
operation. Work hard to minimize the amount of privileged code, and audit the privileged code
more carefully than the rest.

Rule 7: If You Must Sign Your Code, Put It All in One Archive File

The goal of this rule is to prevent an attacker from carrying out a mix-and-match attack in which
the attacker constructs a new applet or library that links some of your signed classes together with
malicious classes, or links together signed classes that you never meant to be used together. By
signing a group of classes together, you make this attack more difficult.

Existing code-signing systems do an inadequate job of preventing mix-and-match attacks, so this

rule cannot prevent such attacks completely. But using a single archive can't hurt.

Some code-signing systems let you examine other classes to see who signed them. If you are using
a code-signing system that allows this, you can put code into the static constructors of your classes
to verify that the "surrounding" classes have been signed by the same person as expected.
Examining signers is one way to avoid the example shown in Figure 7.1. This doesn't completely
prevent mix-and-match attacks, since an adversary can still mix together classes that you signed at
different times; for example, by mixing version 1 of Class A with version 2 of Class B. If you're
worried about this kind of interversion mix-and-match attack, you can put each class's "version
stamp" in a public final variable and then have each class check the version stamps of its
surrounding classes.

Figure 7.1 A mix and match attack.

In one type of mix and match attack, signed code

with special privilege is linked or otherwise
grouped together with unsigned code. The
danger is that the unsigned code will be replaced
in the group, leading to undefined and possibly
dangerous behavior.

Rule 8: Make Your Classes Uncloneable

Java's object-cloning mechanism can allow an attacker to manufacture new instances of classes you
define, without executing any of your constructors. If your class is not cloneable, the attacker can
define a subclass of your class, and make the subclass implement java.lang.Cloneable. This allows
the attacker to make new instances of your class. The new instances are made by copying the
memory images of existing objects; although this is sometimes an acceptable way to make a new
object, it often is not.

Rather than worry about this, you're better off making your objects uncloneable. You can do this by
defining the following method in each of your classes:

public final void clone() throws java.lang.CloneNotSupportedException {

throw new java.lang.CloneNotSupportedException();
}

If you want your class to be cloneable, and you've considered the consequences of that choice, then
you can still protect yourself. If you're defining a clone method yourself, make it final. If you're
relying on a nonfinal clone method in one of your superclasses, then define this method:

public final void clone() throws java.lang.CloneNotSupportedException {

super.clone();
}

This prevents an attacker from redefining your clone method.

Rule 9: Make Your Classes Unserializeable

Serialization is dangerous because it allows adversaries to get their hands on the internal state of
your objects. An adversary can serialize one of your objects into a byte array that can be read. This
allows the adversary to inspect the full internal state of your object, including any fields you
marked private as well as the internal state of any objects you reference.

To prevent this, you can make your object impossible to serialize. The way to do this is to declare
the writeObject method:

private final void writeObject(ObjectOutputStream out)

throws java.io.IOException {
throw new java.io.IOException("Object cannot be serialized");
}

This method is declared final so that a subclass defined by the adversary cannot override it.

Rule 10: Make Your Classes Undeserializeable

This rule is even more important than the preceding one. Even if your class is not serializeable, it
may still be deserializeable. An adversary can create a sequence of bytes that happens to deserialize
to an instance of your class. This is dangerous, since you do not have control over what state the
deserialized object is in. You can think of deserialization as another kind of public constructor for
your object; unfortunately, it is a kind of constructor that is difficult for you to control.

You can prevent this kind of attack by making it impossible to deserialize a byte stream into an
instance of your class. You can do this by declaring the readObject method:

private final void readObject(ObjectInputStream in)

throws java.io.IOException {
throw new java.io.IOException("Class cannot be deserialized");
}

As in Rule 9, this method is declared final to prevent the adversary from overriding it.

Rule 11: Don't Compare Classes by Name

Sometimes you want to compare the classes of two objects to see whether they are the same, or you
want to see whether an object has a particular class. When you do this, you need to be aware that
there can be multiple classes with the same name in a JVM. It is a mistake to compare classes by
name since different classes can have the same name.

A better way is to compare class objects for equality directly. For example, given two objects, a and
b, if you want to see whether they are the same class, you should use this code:

if(a.getClass() == b.getClass()){
// objects have the same class
}else{
// objects have different classes
}

You should also be on the lookout for cases of less-direct by-name comparisons. Suppose, for
example, you want to see whether an object "has the class Foo." Here is the wrong way to do it:

if(obj.getClass().getName().equals("Foo")) // Wrong!
// objects class is named Foo
}else{
// object's class has some other name
}

Here is a better way to do it:

if(obj.getClass() == this.getClassLoader().loadClass("Foo")){
// object's class is equal to the class that this class calls "Foo"
}else{
// object's class is not equal to the class that
// this class calls "Foo"
}

Note the legalistic comments in the last example. Whenever you use classnames, you are opening
yourself up to mix-and-match attacks, as described in Rule 7. You should also know that the Java
language forces you to use classnames all the time: in variable declarations, instanceof expressions,
and exception-catching blocks. Only the designers of Java can prevent mix-and-match attacks, but
you can avoid making the problem worse by avoiding by-name class comparisons.

Rule 12: Secrets Stored in Your Code Won't Protect You

You might be tempted to store secrets such as cryptographic keys in the code for your application
or library. Secrets stored in this way are completely accessible to anyone who runs your code.
There is nothing to stop a malicious programmer or virtual machine from looking inside your code
and learning its secrets.

Code obfuscation is another way to store a secret in your code; in the case of obfuscation, the secret
is simply the algorithm used by your code. There's not much harm in using an obfuscator, but you
shouldn't believe that it provides strong protection. There is no real evidence that it is possible to
obfuscate Java source code or byte code so that a dedicated adversary with good tools cannot
reverse the obfuscation.

The Take Home Message

Writing secure Java code is very difficult. There is no magic bullet that will solve your security
problems; all you can do is think hard (perhaps with help from formal analysis tools) and use
prudent engineering practices to minimize risks. Sometimes a pair of objective outside eyes can
help. The rules set forth here are intended to describe some prudent engineering practices for
writing secure Java code. They won't solve your security problems, but they will reduce the number
of ways in which things can go wrong.

CHAPTER SECTION:2

Section 2 -- Guidelines for Java Users

It is all well and good to talk about what can be done to improve the next version of Java, or how
you as a developer can create safer code, but what can a regular Java user do to stay safe? Are there
guidelines for safely using Java as it exists today?

There are several straightforward things you can do to make your use of Java safer. Most of these
are based on good old-fashioned common sense; others require a bit of knowledge about Java. We
have compiled a set of guidelines from the other chapters and have organized them here.

• Know what Web sites you are visiting.

• Learn as much as you can about Java security.
 • Know your Java environment.
• Use up-to-date browsers with the latest security updates.
• Keep a lookout for security alerts.
• Apply drastic measures if your information is truly critical.
• Assess your risks.

Know What Web Sites You Are Visiting

The first piece of advice we have is of the common-sense variety: Know what sorts of sites you are
visiting with your Web browser. The chances of being attacked by an applet from a large corporate
site like www.sun.com are minimal. The chances of suffering an attack while surfing an
underground cracker Web page are, of course, much greater.

All dangerous Web sites may not be run by bad guys, however. One interesting cracker strategy
might be to hack a Web server in a very public fashion (something that has been done to the U.S.
Department of Justice, the U.S. Air Force, and the Central Intelligence Agency, among others
[Ghosh, 1998]), but add a twist. The media coverage will cause many thousands of people to surf to
the hacked site to "check it out." Here's where an attack applet would do the most damage! Since
the Web server has been hacked, the cracker figures, why not install some mobile code that attacks
all surfers indiscriminately? All the curiosity seekers thus become de facto targets.

In any case, there are certainly unsafe places on the Web. An analogy may be useful here. Both of
the authors are sorry to admit they drive minivans. There are places in a large city such as
Washington, D.C. where no one in his or her right mind would drive a minivan. Just as you
shouldn't drive your minivan in certain areas of the city, you shouldn't drive your Java-enabled
browser to certain areas of the Web.

You can avoid risk-laden Web sites by employing the same strategy you would use when visiting a
big city. Use your intuition to assess your environment continually when you surf. If you are
tempted to visit some cracker Web sites, do so with Java turned off. (Actually, make sure that all
types of executable content are disabled when visiting such sites!)

The Internet and the Web are reflections of society, no more and no less. There are sites that reflect
the pinnacle of what people can achieve, and there are those that reflect the depths to which people
can lower themselves. Know that just as there are bad people who rob banks and mug people in the
real world, there are bad people on the Web. Some of these people create traps to prey on
unsuspecting surfers.

Depending on your level of paranoia, you might consider all unknown Web sites as risky locations.
A good strategy might be to leave Java off by default and turn it on only when you make a
conscious decision to trust a site. Many business sites require that their employees use Java this
way. This strategy is easy to implement. We discussed how to disable and enable Java on two
popular browsers in Chapter 4, "Malicious Applets: Avoiding a Common Nuisance."
This guideline takes on more weight as the world rushes into electronic commerce. If your PC has
data on it that help you transact business over the Net (such as trading stocks) then you need to be
concerned about computer security. The addition of money (virtual or not) to the Net changes the
stakes significantly.

Learn as Much as You Can about Java Security

By reading this book, you are off to a good start. Keep in mind, however, that Java security is a
fast-moving field. Since Java's introduction in 1996, the security landscape has changed
dramatically:

• Tens of millions more people are connected to the Internet.

• Java has undergone two major releases.
• The security model has evolved to include signed applets.

There is no reason to believe that Java's evolution will slow. In fact, Java's quick move to maturity
is essential to its long-term viability as a language.

One way to keep abreast of Java security happenings is to sign up for notification of breaking Java
security news. On this book's companion Web site at www.rstcorp.com/java-security.html, you can
submit a form to be added to our notification mailing list. Note that this list will not be sold, rented,
or otherwise shared with anyone other than the authors. We promise. We hate spam as much as
anyone!

You should also keep tabs on the Java Security Hotlist (see Appendix B, "The Java Security
Hotlist," and www.rstcorp.com/javasecurity/links.html).

Know Your Java Environment

Another piece of common-sense advice is to know about the Java tools that you are using. Know
how Java works (this book should help). Now that you know how Java treats signed classes with
privilege, you know how important it is to consider carefully what your security policy looks like
and who created it. Also be aware that early versions of Java (including JDK 1.1) allow built-in
code full power to do anything.

Before Java 2, built-in classes were allowed to bypass all security verification checks. If you are
using a browser that does not yet support Java 2, never put Java classes (or .jar archives of classes)
in your CLASSPATH unless you fully trust the vendor that distributed them. Also be aware that
any subdirectories under the directories in your CLASSPATH may be searched for a class as well.
Know who built your Java libraries and tools.

Similarly, do not install or otherwise change your Java security policy under the influence of a
vendor or other mobile code distributor. A potential social engineering attack against a site running
Java 2 could involve convincing a user to redefine security policy in order to run some cool Java
code. If you must change policy, think long and hard about why and about who you may be
trusting.

Be aware of what Java version you are using. Several companies have licensed the right to produce
Java development environments. Some probably do a better job with security than others. If the
Java VM is buggy, then Java security is compromised. By using a particular vendor's version of
Java, you are trusting the security of your machine to them.

This is actually a general lesson that applies to many technologies. Browser plugins should be
subject to similar scrutiny. So, too, should any executable binaries loaded from the Internet.

Finally, find out who controls your browser's Java security policy. Some corporate users may be
surprised to learn that they are not in control of their surfing security policy. Starting with version
4, both Netscape Navigator and Microsoft Internet Explorer allow a system administrator to set
security policy and lock it in so that it cannot be overridden by users. Some sites attempt to block
Java and other mobile code traffic at the firewall (although see Chapter 6, "Securing Java:
Improvements, Solutions, and Snake Oil"). If you do control your own policy, make sure you set up
a policy that is sound and coherent. Be aware that setting up a security policy is nontrivial and often
leads to subtle errors.

Use Up-to-Date Browsers with the Latest Security Updates

This guideline may be a bit counterintuitive, but you should always use the latest version of your
favorite browser-even if it is a beta version. All of the security holes discussed in Chapter 5,
"Attack Applets: Exploiting Holes in the Security Model," have been fixed in the very latest
versions of Netscape and Internet Explorer. Be aware that no new versions of the early releases
have been updated to fix bugs. This implies that the beta versions are more secure. Of course, beta
versions may also have new bugs of their own.

Recall that although the Princeton Class Loader attack has been fixed for most versions of Netscape
(see Applets Running Wild in Chapter 5), the problem persists in version 2.0. The same thing goes
for the Jumping-the-Firewall attack. Counting on an old version of a browser for your security is
probably not a good idea.

Use the next guideline to help determine which version of a browser you need to have. Then get it.

Keep a Lookout for Security Alerts

Every once in a while, check the latest security information on Java. This book's companion Web
site (www.securingjava.com) is quite current, but you should also keep an eye on the Sun
Microsystems official Java Security FAQ. Also, have someone in your organization (or someone in
your group of friends) subscribe to the CERT Alert list.
If the CERT Coordination Center finds a security hole either particularly egregious or particularly
popular among crackers, they will warn the community at large. To date, CERT has issued two
security alerts about Java. Both were related to attacks found by the Princeton team. The alerts were
reprinted in Appendix B of Java Security: Hostile Applets, Holes, & Antidotes (the first edition of
this book), where you will also find information about signing up for online delivery of CERT
Alerts.

The CERT Alerts have the advantage of telling you the status of any security attacks and how to
avoid them. For Java, this includes information about which browser versions are susceptible to a
particular attack and which versions have been patched.

More Drastic Measures

There are, of course, a couple of drastic measures that can be applied to lessen Java security risks.
These both involve not using Java. These drastic alternatives are not called for unless your
information is ultra-critical. If you determine that the risks described are simply too great for you to
bear, you can implement these strategies.

Stopping Java at the Firewall

Many firewall vendors claim to have added the capability of stopping Java applets at the gate by
using special firewall products. Some firewalls block Java applets by parsing a Web page's HTML
code as it arrives. This action is typically performed by the HTTP proxy. HTML-parsing capability
makes a firewall capable of blocking any HTML-related tag. Thus, the relevant proxy can cut out
Java (by looking for the <APPLET> tag), JavaScript, and even old HTML 2.0 tags that are deemed
disallowed during setup. This strategy is useful only for HTML coming in through the proxy via
HTTP. That means that applets coming into the system in other ways (for example, through SSL or
via ftp) can still get through.

Another solution to the same problem might be to try to stop all files with a .class extension at the
gate. Still another would be to scan all incoming binaries for the magic number each applet is
required to have. The end result is the same: No applets are allowed past the firewall.

Research results show that stopping mobile code is much more difficult than it may seem at first
glance. An excellent technical paper entitled Blocking Java Applets at the Firewall by David
Martin (Boston University), S. Rajagopalan (Bellcore), and Avi Rubin (ATT Research) can be
downloaded from www.cs.bu.edu/techreports/96-026-java-firewalls.ps.Z (or see the Java Security
Hotlist).

Stopping all applets at the firewall is a radical solution that gives up all the good things that Java
has to offer. It may be a viable alternative for machines that require limited Web access but are
considered too important to expose to any risk beyond that. Unfortunately, this strategy resembles
throwing the baby out with the bath water.
Hiding Under the Bed
Believe it or not, there are strategies even more paranoid than blocking applets at the firewall.
Some sites may have such sensitive information that they decide they can't afford to take any risks
at all. These sites protect themselves by not even connecting to the Internet in the first place. Java
risk is thoroughly countered by this strategy, but all of the benefits that come with being connected
to the Internet are given up in return. Java's power and flexibility may still find room on such a
company's intranet, but there will certainly be fewer uses for Java.

CHAPTER SECTION:3

Section 3 -- Guidelines Are Never Perfect

The guidelines included in this chapter can help you develop more secure code and use Java more
securely, but in the end, they can't guarantee anything about security. Following the two sets of
guidelines is probably a good idea, but risks will always remain, no matter how vigilant you are.
Plan accordingly.

If you are doing business on the Net, be particularly careful. The stakes change significantly when
it comes to electronic commerce. An appropriate introduction to the security dangers inherent in e-
commerce is Anup Ghosh's book, E-Commerce Security [Ghosh, 1998].

Whatever you do, pay close attention to the tradeoffs between functionality and risk. We make
security and safety tradeoffs every day when we leave the house, and often they are very
appropriate. Making these decisions is more reasonable when you know about potential pitfalls.

Java Card Security

How Smart Cards and Java Mix
We emphasize throughout this book that Java is much more than simply a programming language.
This chapter takes that lesson to heart and discusses Java's role in a technology destined to become
part of all our lives in the near future-smart cards. In light of its history as a platform for embedded
devices, it's a bit ironic, but not surprising, that in one of its many forms, Java is coming full circle
back to its embedded roots. Smart cards provide an important enabling technology for e-commerce.
They are integral building blocks in many systems currently on the drawing board and a few
systems already in service. Java can help make smart cards more accessible to developers and
business people by providing a well-understood, familiar environment.
One of the barriers blocking the adoption of smart cards throughout the world has been the lack of a
common platform on which to develop applications. Java can help dismantle that barrier, opening a
world of potential development opportunities to Java developers and cutting-edge organizations.

This chapter answers a number of questions about Java-based smart cards, including:

• What is a smart card?

• Why put Java on a smart card?
• How can Java fit on a card?
• How secure are smart cards?
• What role can smart cards play in e-commerce systems?
• How does the use of Java impact smart card security?

These questions are important ones to ask since smart cards have already started appearing in
consumer wallets, especially in Europe.

Chapter Eight Sections

1. Java Security Goes Both Ways

2. What Is a Smart Card?
3. Why Put Java on a Smart Card?
4. How Can Java Fit on a Card?
5. How Secure Are Smart Cards?
6. What Role Can Smart Cards Play in E-Commerce Systems?
7. How Does the Use of Java Impact Smart Card Security?
8. Managing Risks

Java Card Security: How Smart Cards and Java Mix

CHAPTER SECTION:1

Section 1 -- Java Security Goes Both Ways

There are a large and growing number of Java systems running the gamut from Java gizmos such as
Java rings, through smart cards with built-in Java interpreters (the subject of this chapter), to
complete Java Development Kits and Integrated Development Environments (IDEs). Java is
simultaneously making in-roads on many fronts. In distributed systems, Java-based servers and
servlets are becoming as common as Java clients. As with any platform meant to interact in a
networked world, there are security concerns with each flavor of Java.
These concerns take on a new urgency when it comes to e-commerce. When electronic blips are
money, the stakes change considerably. It may be an inconvenience to lose a Web server that
amounts to fancy brochureware; it is something else entirely if the Web server and its associated
backend perform all customer transactions.

The security concerns raised by e-commerce are a large enough topic in their own right that there is
no way we can do them justice here. Of course, because Java is commonly used at all levels in e-
commerce systems, the risks we identify have serious e-commerce implications. This is especially
true for Java cards.

Counterintuitively, Java is both growing and shrinking at the same time. On one hand, the JDK,
now up to Java 2, is doubling in size with each major release. Just to complicate matters, at the
same time as the explosive growth of the code base is occurring, the security architecture is
undergoing major reorganization. Chapter 2, "The Base Java Security Model: The Original Applet
Sandbox," and Chapter 3, "Beyond the Sandbox: Signed Code and Java 2," detail the new model.
On the other hand, embedded Java systems like Card Java 2.x strip Java functionality down to bare
bones. The security model is not immune to this effect and has been deeply affected by Java's
migration to smart cards.

These two diverse directions both have important security implications. Java 2 involves
fundamental changes to the Java security model as the Java sandbox metamorphoses itself into a
trust-based system built on code signing. Card Java 2.x removes much of the sandbox, leaving
smart card applets more room to misbehave.

CHAPTER SECTION:2

Section 2 -- What Is a Smart Card?

A smart card looks just like a credit card, only with a chip embedded in its plastic. Imagine
replacing the hologram on a standard credit card with a similarly thin chip and you get the idea.
Most smart card chips are about the size of a dime (only thinner) and can be recognized by their
distinctive gold terminals. Figure 8.1 shows a Visa smart card.

Figure 8.1 Visa has been active in the

development of the Java Card.

Visa's Open Platform classes interact with

Java Card to provide a secure framework
for which to develop smart card
applications. (This figure used by
 permission from Visa.)

A smart card chip is actually a complete little computer with nonvolatile memory, storage, a card
operating system (COS), and accompanying communication protocols. The most advanced smart
cards on the market have the processing power once found in an IBM-XT (with less memory, of
course).

There are many different uses for smart cards. Smart cards can serve as:

• Security cards that are able to identify the carrier using advanced authentication algorithms
and can safely store secrets like private keys
• Electronic wallet cards that use several different approaches to store value and provide a
kind of electronic cash
• Transaction cards that take over the role once played by the magnetic stripe commonly
found on the back of credit cards
• Processor cards that carry out proprietary calculations in a black box fashion
• Memory cards that act as highly portable databases
• Cards with Virtual Machines that run Java applets

Unlike traditional computers, smart cards are not delivered with a built-in power supply, a
keyboard, or a display device. That means smart cards require a terminal in order to work. Such a
terminal is usually called a smart card reader or a card acceptance device (CAD). Some of these
readers can be quite small and provide limited capabilities. For example, one CAD popular in
Europe among users of stored-value telephone cards is not much bigger than a smart card itself.
This CAD's sole purpose is to display the balance of money stored on the card. (Having a trusted
device with which to query a card you own is important for consumer peace of mind, especially
when spending money at businesses that are of questionable trustworthiness. Plus, it's nice to be
able to verify that transactions, like adding money to a card, actually happen properly.)

CADs are also present at merchant sites (usually in the form of point-of-sale devices) and at issuing
banks. These CADs may look much like a typical point-of-sale credit card processor, with a small
display screen and a few buttons for answering queries or entering PINs. In similar fashion to
today's ATMs, a smart card is inserted directly into the reader. The reader then provides power to
the card and sets it up to receive software commands. Although a CAD of this sort may look like an
ATM on the outside, a smart card is much more powerful than an ATM card or a mag-stripe credit
card. These latter cards store only a few kilobytes of information on the magnetic stripe and are not
capable of performing computations. Smart cards can store many megabytes of information and
carry out sophisticated cryptographic calculations.

Another sort of CAD more commonly encountered by developers is a CAD connected directly to
the serial port of a standard PC. Using development environments similar to those used in normal
application development, programmers can create code for smart cards, download it into a
prototyping card, and in this way create new smart card applications. Most major smart card
vendors have proprietary Java development environments: Gemplus offers
the GemXpresso environment; Schlumberger offers Cyberflex.

There are many custom command sets for smart cards. In fact, there are so many custom
environments and they are so specialized that the number of smart card programmers is very small.
Considering that smart cards are traditionally programmed in platform-specific assembly languages
and that each vendor has a different language, the small number of programmers should come as
little surprise.

The situation could be worse, of course. At least all of the major vendors conform to a set of
common communications standards. The ISO 7816 specifications provide at least some common
ground and ensure that smart cards have similar terminal pin-outs, accept standard protocol
messages, and store some information in databases of common design [ISO7816, 1987]. ISO 7816
defines some commands in great detail and lays out communication protocols used by smart cards.
Because of the existence of 7816, a smart card made by, say, Gemplus, can interface with a CAD
meant for, say, Schlumberger cards.

Smart cards have long been associated with security since they provide a partial solution to the
need for personal identification and nonrepudiation. Because smart cards provide more nonvolatile
storage than other highly portable devices, they make ideal storage compartments for digital
identities. They can also compute hashes, session keys, digital signatures, and MACs right on the
card. To the extent that a card is tamper resistant (something we will discuss further later in this
chapter), it can be used to store important secrets such as DES keys or RSA private keys.

CHAPTER SECTION:3

Section 3 -- Why Put Java on a Smart Card?

As we mentioned earlier, one obstacle blocking widespread use of smart cards in U.S. markets has
been the large number of incompatible and often obscure development languages available for
writing smart card applications. Regardless of the ISO 7816 specifications, programming languages
for smart cards have traditionally amounted to special-purpose assembly languages. Few
developers were familiar with card application languages, the upshot being that only a handful of
people could develop smart card code. As cards become computationally more powerful, new
application languages are being designed and put into use. One of the most interesting new systems
is Java Card 2.x (seewww.javasoft.com/products/javacard/index.html).

The problem of multiple, noninteroperable platforms is not limited to smart cards, of course. A
major part of Java's appeal is that it was designed as a cross-platform solution. Developers have
always wanted a solution to the platform problem (other than the adoption of one single proprietary
platform controlled by a monopoly). Java is one good way of addressing the platform problem on
smart cards.
A Java card is a smart card that is able to execute Java byte code, similar to the way Java-enabled
browsers can. But standard Java with all of its libraries (especially in the Java 2 guise) is far too big
to fit on a smart card. A solution to this problem is to create a stripped-down flavor of Java. Card
Java is just such a flavor. It's based on a subset of the Java API plus some special-purpose card
commands.

Besides providing developers with a more familiar development environment, Card Java also
allows smart cards to have multiple applications on them. For the most part, existing smart card
products (especially in the financial arena) have only one application per card. This application is
automatically invoked when power is provided to the card or the card is otherwise reset. The one-
application-per-card paradigm doesn't scale well, to say the least. Who wants to carry 20 credit
cards around? Card Java can solve this problem by allowing multiple applications, potentially
written by different organizations, to exist on the same card. The idea of multiple applications
running on the same VM by potential competitors raises a number of security issues, which we
address later in the chapter.

CHAPTER SECTION:4

Section 4 -- How Can Java Fit on a Card?

Even a stripped-down version of Java and its accompanying VM requires a fair amount of
computational power in order to work. To be capable of running Card Java, a smart card must have
at least 16K of read-only memory, 8K of EEPROM, and 256 bytes of random access memory.

Given a Java Virtual Machine on a smart card, the number of possible new applications is mind-
boggling. With an off-the-shelf (or off-the-Net) application development environment for Card
Java, thousands of Java developers will be able to program smart cards. Gemplus and
Schlumberger both distribute commercial Card Java environments. Of course, the memory and
interface constraints of smart cards deeply affect programming style, testing concerns, and other
aspects of program development.

Card Java has many features familiar to Java developers, especially those developers familiar with
JDK 1.0.2. Card Java includes:

• Packages
• Dynamic object creation
• Virtual methods
• Interfaces
• Exceptions

Elements of Java that are not supported include:

• Dynamic class loading

 • A security manager
• Threads
• Cloning
• Garbage collection
• Finalization

A number of limitations are also imposed on runtime card application (or cardlet) behavior. The
"Java Card 2.0 Language Subset and Virtual Machine Specification," a Sun Microsystems
document available on the Web at www.javasoft.com/products/javacard/index.html, describes
the smart card version of Java in more detail.

In the current Card Java paradigm, applets live on a card forever once they are installed during a
process commonly called personalization. More specifically, although an applet's byte code may
stay on the card forever once it is masked onto a card, an applet can be marked as unavailable and
thus be permanently disabled. All applets that will be used on a card are installed at one time,
before the card is issued to a consumer. These applets are selected and deselected by the Java Card
Runtime Environment (JCRE). The JCRE is made up of the Virtual Machine and the core classes
of the Java Card API. It keeps track of applets that are selected and currently active. The JCRE is in
this sense the card executive, receiving messages (known as APDUs) on the input lines and
carrying out the appropriate activities such as selecting an applet. Only one applet can run at a time
in current Card Java implementations.

Future versions of Card Java are likely to allow applets to be loaded onto an existing card even
after it has been issued to a consumer (much the same way that applet code is loaded into a
browser's VM). This introduces a number of security risks, including the risk that downloaded
applet code will behave maliciously (in the manner of the hostile applets detailed in Chapter 4,
"Malicious Applets: Avoiding a Common Nuisance," andChapter 5, "Attack Applets: Exploiting
Holes in the Security Model") and the risk that poorly engineered code will disable or otherwise
break the platform. Unlike VMs inside browsers, a smart card VM is not quite as easy to restart,
nor are the security mechanisms as rigorous.

By this point, it should be clear that Card Java has important security implications. These
implications take on even more importance when smart cards are used in e-commerce systems.

CHAPTER SECTION:5

Section 5 -- How Secure Are Smart Cards?

Before we dig into the security implications raised by putting a Java VM on a smart card, we need
to address the issue of basic smart card platform security. Smart cards are funny things. Depending
on how they're used, smart cards can sometimes be meant to keep secrets from the very people who
carry them around and use them. Consider, for example, a smart card that stores monetary value in
an internal register. If the card user can figure out a way to change the value of the register outside
of traditional means, he or she might be able to mint money! Smart cards like this make tempting
targets for bad guys.

Because smart cards are often used in security-critical situations, they have undergone a fair
amount of scrutiny from security researchers. Two main results are worth considering before we
get into security issues specific to Java: 1) the terminal problem, and 2) physical attacks on the
card.

The Terminal Problem

Smart cards need a way to interact with their users. Since there is no built-in display capability in
most cards, the CAD must take on this responsibility. Any display used during critical transactions,
such as transferring money, needs to have two properties: the display must be trustworthy, and it
must be unspoofable. Making sure a terminal presents proper and trustworthy information to a user
is known as the terminal problem.

The terminal problem is really a trust issue. How is a card user to be sure that the card is doing
what it is supposed to be doing during a transaction? How can a card user check to see whether
account balances (for example) have been properly debited or credited? The problem is that cards
are very much black boxes.

Many systems now on the drawing board include the use of personal computers as client-side
CADs. Consumers will use a PC to interact with the smart card and to address the concerns raised
by the terminal problem. The problem is that PCs are notoriously insecure, especially when they're
used to exchange lots of documents and programs, as most consumers do. If you use your computer
this way, you're taking on a great deal of risk.

One direct consequence of PC untrustworthiness is a PC's impotence relative to the terminal

problem. If your PC can't be trusted, how can you believe that what it is telling you on behalf of
your smart card is correct? In fact, one excellent reason for using smart cards at all is that PCs can't
be trusted. The reasoning goes that it is better to store secrets like PINs, sensitive personal data, and
private keys on a smart card than on a PC. That way, if the PC is compromised, your secrets can't
be so easily stolen.

However, this leaves us with the terminal problem. A scenario can make this more concrete.
Imagine that someone has tampered with your Web browser either by hacking into your PC or by
tampering with the Web browser executable before you downloaded it. Now clearly you can't trust
the browser not to steal or rewrite data on the way from your smart card to you. Some things that
might happen are:

• The smart card requires a PIN before it can be used. Through a browser interface, you are
queried for your PIN (which you faithfully enter). The corrupted browser sees the PIN go by
and stores it for later illicit use.
 • The PC is used as a listening post in order to carry out capture/replay attacks against the
smart card (these kinds of attack often work against cryptographic protocols unless the
protocols are carefully designed to address this problem).
• The PC steals the private key off the smart card and is able to "legally" represent you by
digital signature.

What is needed is a trusted display. Some researchers have suggested that PDAs such as 3Com
PalmPilots might serve as trusted displays. The idea is that the PDA can interact directly with the
user during security-critical operations like PIN input. In fact, the PDA can replace the smart card
entirely since it can easily carry out all the required computations. (PDAs are probably too
unwieldy for this idea. It's much easier to slide a smart card into your wallet than a PalmPilot.)

Unfortunately, there is not much reason to trust a PalmPilot much more than a PC these days. The
problem is that newer PalmPilots and other PDAs are designed to network with PCs directly
(sometimes even using a TCP/IP stack). That's good news if you want to transfer data to and from
your PDA, but it's risky. Just like a PC, a PalmPilot is probably insecure if you frequently
download programs onto it. Crackers are currently devising hacks that work against PalmPilots.

In the end, we're stuck with the terminal problem. As smart cards move into more widespread use
on PCs, PC-based interfaces will be especially susceptible to this problem. An insecure Windows
95 OS in concert with a Web browser should not be trusted to display critical information to a
smart card user. A PDA might do the trick, but is likely to carry similar risks.

Physical Attacks on Smart Cards

The most obvious and direct attack on a smart card is a physical attack on the card itself. In the case
of a stored-value card, this sort of attack may even be carried out by the owner of a card. Physical
attacks attempt to reverse engineer the card and determine the secret key(s). Such attacks have been
demonstrated in practice against commercial secure smart card chips, most notably by three groups
of researchers: Dan Boneh, Richard DeMillo, and Richard Lipton of Bellcore; Ross Anderson of
Cambridge and Marcus Kuhn of Purdue; and Paul Kocher and colleagues of Cryptography
Research, Inc.

Boneh, DeMillo, and Lipton

Boneh, DeMillo, and Lipton, three Bellcore researchers, published a paper called On the
Importance of Checking Cryptographic Protocols for Faults in which they pointed out that an
adversary who can introduce computational errors into a smart card can deduce the values of
cryptographic keys hidden in the smart card [Boneh, et al., 1997]. The surprising part is that an
attacker can do this even without precisely controlling the nature of the errors or even the exact
timing of the errors. By comparing the result of an erroneous encryption with the result of a correct
encryption of the same data, the attacker can learn something about the correct encryption key. By
doing enough of these comparisons, the attacker can learn enough information to deduce the entire
encryption key.

How does the attacker introduce errors? There are plenty of ways. The attacker can subject the
smart card to fluctuations in temperature, input voltage, or clock rate; point a radiation source at the
card; or hit the card with a rubber mallet. Anything that is likely to cause voltages inside the card to
fluctuate will do.

Biham and Shamir later generalized this attack with a technique called Differential Fault Analysis,
which works against a wide range of cryptographic algorithms. The upshot of all this is that unless
a smart card cryptography mechanism is very carefully designed, any secret keys stored inside the
card might be extracted by a determined attacker.

Anderson and Kuhn

In a paper entitled Tamper Resistance - A Cautionary Note
(www.cl.cam.ac.uk /users/cm213/Publications/tamper.html), Anderson and Kuhn point out that
"smart cards are broken routinely" and to the extent that their secure use requires tamper resistance,
smart cards "should be treated with circumspection." The paper describes a number of smart card
attacks, many of which can be carried out by amateur attackers with very limited resources
[Anderson and Kuhn, 1996]. Attacks described include voltage manipulation, temperature
manipulation, chip removal (for easier probing), UV light attacks, and microprobing.

More sophisticated attacks requiring professional equipment and materials involve uncovering the
layers of a chip by etching, discerning chip behavior by advanced infrared probing, and reverse-
engineering chip logic. The somewhat gloomy conclusion is that, at best, chip designers can only
impose costs and delays on attackers, never providing guaranteed security. Many businesses that
rely on smart card security realize this and do all they can to manage the risks prudently. Users
should do the same.

Some caveats: the Anderson and Kuhn work is somewhat dated and is based on attacks carried out
in the lab against conventional micro-controllers, which are usually much simpler than today's
smart cards. Micro-controllers provide a great deal of open access to potential attackers since they
are meant to be interactively programmed. For example, micro-controllers often provide an
interface for external memory; generally speaking, smart cards don't have this feature. Thus they
provide less of a beachhead for attacks.

Of course Java complicates this line of reasoning somewhat. Card Java provides a platform that is
meant to be programmable in the sense that applets may be loaded onto a smart card after it is
issued. Mechanisms for loading new code onto a smart card provide a good starting point for an
attacker.

Differential Power Analysis

In 1998, Researchers at Cryptography Research, Inc., led by Paul Kocher, publicly announced a
new set of attacks against smart cards called Differential Power Analysis (DPA). DPA can be
carried out successfully against most smart cards currently in production.
DPA is a complicated attack that relies on statistical inferences drawn on power consumption data
measured during smart card computation. The equipment required to perform DPA is simple: a
modified smart card reader and some off-the-shelf PCs. The algorithm itself is quite complex, but
details have been widely published.

Chips inside a smart card use different amounts of power to perform different operations. By
hooking a card up to an oscilloscope, a pattern of power consumption can be measured. Particular
computations create particular patterns of spikes in power consumption. Careful analysis of the
peaks in a power consumption pattern can lead to the discovery of information about secret keys
used during cryptographic computations. Sometimes the analysis is straightforward enough that a
single transaction provides sufficient data to steal a key. More often, thousands of transactions are
required. The types of sensitive information that can leak include PINs and private cryptographic
keys. Figure 8.2 is a conceptual diagram of DPA.

Figure 8.2 Differential Power Analysis.

Paul Kocher and his colleagues at Cryptography Research

devised a monitoring attack on smart cards based on
information leaked through card power consumption. This
figure used by permission from Cryptography Research.

Possible solutions include masking power consumption with digital noise or throwing random
calculations into the mix. Another potential solution is randomizing the order of card computations
so that in the end, the same computation is performed using different patterns of primitives. All of
these potential technological solutions are ways to mask the giveaway patterns in the power
consumption of the card.

DPA is actually a variation on an earlier attack discovered by Kocher. The earlier attack exploited
the fact that some operations require different amounts of time to finish, depending on which values
they are computing. In the same way that DPA allows an attacker to piece together key information
based on variations in power consumption, Kocher's timing attack allows an attacker to piece
together a key based on variations in the amount of computing time required to encrypt various
values.

One thing to note is that legitimate users of smart cards don't have to worry too much about DPA or
timing attacks, because the attack requires physical access to the card itself. Unless you lose your
card or insert it directly into an attacker's machine, there is not much threat that your card itself will
be cracked. The main risk that DPA presents is to companies that must concern themselves with
widespread fraud of the sort carried out by organized crime.
The best approach is to assume information will leak from a smart card and design systems in such
a way that they remain secure even in the face of leaking information. An approach of this sort may
preclude smart card systems designed to do all processing offline without a centralized
clearinghouse.

Detailed technical information about DPA can be found on the Web

at www.cryptography.com/dpa/technical/index.html.

No Free Lunch

It should not be surprising that smart cards have their own set of risks- 100-percent security is an
unattainable goal. Once again, risk management and defensive design are optimal strategies.

CHAPTER SECTION:6

Section 6 -- What Role Can Smart Cards Play in E-

Commerce Systems?
E-commerce means different things to different people. Some people, for example, limit the
meaning of e-commerce to commerce conducted over the Internet and the Web. For the purposes of
this chapter, we're going to use the term more widely. So, by e-commerce, we mean everything
from electronic business-to-business traffic (for example, Electronic Data Interchange), through
Internet-based systems, to any system in which money is represented as bits. Under this admittedly
overly broad definition, almost the entire economy is touched by some aspect of e-commerce.
We're intentionally invoking this broad definition to emphasize the utility of smart cards for
transacting business.

Smart cards are seemingly an excellent medium for carrying password-protected personal data.
Private information such as medical records or secret crypto keys can be stored on a card in a form
accessible only to the card carrier (or at least someone who knows the right secrets). In addition,
smart cards can store value. Card carriers can decide with whom to share data and with whom to
transact business and use their cards only with those vendors they choose to trust.

The most common form of smart card for commerce is the register-based, stored-value card.
Somewhat ironically, one of the most unfortunate consequences of this kind of smart card is that
secret keys on the card are known only to the issuing bank and must remain secret from the owner.
If the card owner can somehow retrieve a secret key, then he or she can mint electronic cash. In
light of the physical attacks sketched earlier in the chapter, this is a serious problem.

Multiple-application smart cards like the Java Card should directly impact the marketability of
smart card technology for e-commerce. When a single card can replace the many cards most
consumers carry around today, people are likely to want it. Imagine a single card that both holds
personal information (such as driver's license, social security, medical information, auto insurance,
voter registration, workplace ID, Web site passwords, keys for making digital signatures and
encrypting data) and also provides multiple functions (working as a phone card, a charge card for a
store, a video rental credit tracker, a credit card, a debit card, and an electronic cash repository).

Leading Web vendors like Netscape are developing APIs for smart card interfaces. The idea is to
use a smart card to store cryptographic data for use with existing protocols such as SSL. This will
allow Netscape users to interact over the Web with a well-understood (and widely accepted)
protocol. Microsoft is also building smart card interfaces into its products.

The first use of smart cards for e-commerce is likely to be as a key/identity repository. In this case,
smart cards act as highly portable hardware tokens that can be uniquely identified. Smart cards can
store personal digital certificates for use with the SET protocol and other authentication-based
protocols [Ghosh, 1998]. This could make it possible to carry out Web-based commerce on Internet
kiosk systems of the sort occasionally found in airports and coffee shops.

CHAPTER SECTION:7

Section 7 -- How Does the Use of Java Impact Smart

Card Security?
Much of the base security model found in Java's JDK 1.0.2 (and explained in Chapter 2) is not
present in Card Java. For example, Card Java has no Security Manager class. This means the whole
concept of security for Card Java applets is significantly different from the case of applets running
on a standard browser-based VM. Fortunately, some of Card Java's "missing parts" may actually
enhance the security situation; unfortunately, some of the changes introduce new security risks.

How Card Java Lessens Security Risks

One of the most difficult problems in Java security is figuring out how to preserve type safety,
while at the same time allowing dynamic class loading (see Chapter 2). If you can confuse the VM
about the types of objects it is manipulating, you can break the security model. In its current form,
Card Java takes care of this problem by removing dynamic class loading, making type safety easier
to enforce. Class loading has always been problematic in Java and has introduced a number of
serious security holes. Because it has no dynamic class loading, Card Java is less risky than regular
Java from this perspective.

Another constraint imposed by Card Java, lack of threading, makes security analysis of applet code
much easier than it is normally. Threading is difficult to implement properly and to use properly,
plus threading takes a fair amount of overhead in the VM and significantly impacts the VM
footprint. Although there can be multiple applets resident on the same smart card, Card Java
systems allow only one applet to be selected at a time. (The multiple-resident-applications concept
introduces risks of its own, which we address later.)

How Card Java Increases Security Risks

Lack of threads and the absence of dynamic class loading impact security in a positive way, but the
opposite effect can be seen with other Card Java features. In other words, the removal of some
features of Java (clearly intended to make possible the migration to Card Java) may introduce new
security problems. Risks that are introduced involve:

• Lack of garbage collection

• Exception propagation problems
• Multiple applications and applet firewalling
• Object-sharing loopholes
• Access to native code

These problems and their risks are discussed next.

Garbage collection is a good example of a feature whose absence has a security impact. Without a
system for freeing allocated memory, the problem of denial-of-service attacks is exacerbated. The
Card Java 2.0 specification does not require implementation of garbage collection on a card (in
fact, implementing garbage collection on a card would be no small feat). As a result, even subtle
programming errors can wreak havoc on a smart card. Memory leaks are a classic problem in
languages such as C++ that do not support automatic garbage collection [Hastings and Joyce,
1992]. (Note that the term memory leak refers to memory becoming full when objects are
inefficiently created and destroyed.) Since Card Java does not support garbage collection, logic
errors in applet code may over time exhaust free memory, rendering the card useless. This problem
is especially acute on cards with limited memory resources. Another closely related issue is the
"dangling reference" problem, in which a program frees memory even though it still has a pointer
to that memory. The problem is that the freed memory may be recycled for another purpose, and
then the old "dangling" pointer may be used, resulting in memory corruption. Unfortunately,
garbage collection is expensive in terms of both time and computational resources. Nevertheless,
the risk of memory leaks is real. The requirement to ensure that these kinds of errors do not occur
raises the need for extensive testing and analysis of Card Java applet code.

Exception propagation is an interesting issue for Card Java as well, since uncaught exceptions
could lead to a card being muted (disabled for normal use). The potentially fatal effect of
unhandled exceptions implies another significant exposure to unintended denial of service, once
again resulting from subtle programming errors. As with memory exhaustion, the requirement to
ensure that these kinds of errors do not occur raises the requirements for extensive testing and
analysis of the Card Java applet code.

Since Card Java allows multiple applications to be resident on the same smart card, there is a risk
of interapplication attacks. This risk is especially relevant in situations where applets may be
provided by competing vendors. Card Java defines applet firewalls meant to protect applets from
one another, although it is not exactly clear what technology underlies this terminology. It appears
that the main protections between applets are related to memory management; in particular, applets
are not allowed to access memory arbitrarily on the card. As a default, they can only get access to
objects that they own (which are mapped into card memory during applet installation). It is clear
that the memory protection mechanisms must be perfectly implemented to allow safe use of
multiple applets. Plans are in the works for smart card applications that cooperate with each other.
Imagine, for example, a card that works both as a debit card and as a frequent flyer card. Such plans
may introduce more security risk than they are worth.

One feature that is in high demand in systems with multiple applications is object sharing. Card
Java 2.0 includes an object sharing approach that includes a loophole. The current approach is
described as follows:

The JCRE keeps track of the currently selected applet as well as the currently active applet. The
currently active applet value is referred to as the applet execution context. When a virtual method is
invoked on an object, the applet execution context is changed to correspond to the applet that owns
that object. When that method returns, the previous context is restored. Invocations of static
methods have no effect on the applet execution context. The applet execution context and sharing
status of an object together determine if access to an object is permissible [Sun Microsystems,
1997].
To illustrate the implications of this approach, consider an example with three applets named A, B,
and C as shown in Figure 8.3. Applet A shares an object it owns, x, with applet B. Applet B shares
an object it owns, y, with applet C. A virtual method in the object owned by B, called y.bar, and
shared with C invokes a virtual method in the object owned by A, called x.foo. Now if applet C is
selected, it has permission to invoke virtual methods of the object owned by applet B, including the
one that in turn invokes the virtual method in an object owned by applet A. In other words, C
indirectly invokes x.foo.

Figure 8.3 Sharing a virtual method with another applet is

tantamount to allowing that applet complete control over the
method.

The problem is illustrated here. Applet A may think it is sharing method

foo() only with Applet B, but Applet B can in turn share the method
(through method bar()) with Applet C. If A doesn't want to share with C,
this may be a problem.
PLEASE NOTE: In the above image, between Applets B and C should
read "share (y,C)."

In short, if virtual methods are used, granting an applet permission to access an object amounts to
also granting that applet the ability to export indirect access to that object to any other applet. This
has a clear weakening effect on any assurance about the protection of an object. For static methods,
such access is prohibited, since static methods do not change the applet context. Restricting virtual
methods in the same way that static methods are restricted may add some complexity to sharing
schemes. The upshot of this change would be that an applet will be forced to share the object
explicitly with all other applets that directly or indirectly need to be granted access permission.

By far the biggest risk presented in the design of Card Java is a potential ability for a vendor to add
and use Native methods on the platform. Obviously, this will compromise portability (applets that
use Native methods will not be automatically portable to other cards), and it may expose the card to
dangerous code that exists outside the applet firewalls. In fact, if Native methods are available, the
concept of firewalls deteriorates. Native code is not restricted by the JCRE mediation of access, and
misuse is possible.

The very real security concern is that an attack applet will make use of Native code to carry out
operations that would otherwise be stopped by the JCRE. When Native code executes, all bets are
off for the Java Virtual Machine and its protection mechanisms. Native code in applets completely
breaks the idea behind Java security. Attack applets are likely to make use of Native method calls.

The five new risks we have covered were introduced into Java with its transformation to Card Java.
Although Card Java certainly presents an intriguing new set of risks in terms of security, it does
nothing to address several important fundamental security concerns associated with smart cards,
including the problem of physical attacks and the terminal problem (both discussed earlier in the
chapter). It is important to keep in mind that the non-Java-related problems have a real impact on
card security and that they are not solved by Card Java.

CHAPTER SECTION:8

Section 8 -- Managing Risks

New functionality in the form of smart cards promises to help solve some tough, real-world
problems and address important security concerns. With new functionality, however, comes new
risks. The security dilemma remains: How much risk are you willing to take, and to what benefit?

The Future of Java Security:

Challenges Facing Mobile Code
Now that you have reached this chapter, you have learned many things about today's Java security
model. One of the key lessons emphasized throughout the book is that the current Java security
model is more complex than ever. This makes Java security both difficult to understand and
difficult to use securely. The people at Sun Microsystems and other Java licensees have gone to
great lengths to provide a secure platform for mobile code and a set of tools with which to build
security-critical applications. To some extent they have succeeded, as Java is more secure by far
than any other mobile code architecture. The security model is complex; however, there are many
things you can do to make your use of Java more secure. In addition, there are a number of
challenges that remain for Java.

Chapter Nine Sections

1. Lessons from the Trenches

2. Challenges for Secure Mobile Code
3. Software Assurance for Java
4. Should You Use Java?

The Future of Java Security: Challenges Facing Mobile

Code
CHAPTER SECTION:1

Section 1 -- Lessons from the Trenches

Java has evolved more quickly than any other computer language in widespread use. As the
language itself has evolved, so, too, has the security model. Here are some lessons we have learned
as we have watched Java's approach to security change.

Type safety alone is not security. Chapter 1, "Mobile Code and Security: Why Java Security Is
Important," and Chapter 2, "The Base Java Security Model: The Original Applet Sandbox," explain
why type safety is critical to Java's security model. Chapter 5, "Attack Applets: Exploiting Holes in
the Security Model," shows what happens when type safety is compromised. Java security is much
more than type safety, however. Think of type safety as the foundation of a complete Java security
solution. The foundation is essential, but much needs to be built on top of the foundation to make a
useful building.

Real security is more difficult than it sounds. Securing a system as complex as Java (not to
mention systems built on top of Java) is a nontrivial undertaking. Do not let slick marketing
convince you that building a secure system is easy. It isn't. Java provides a powerful set of tools
that can help you create a secure system, but simply using the tools is no guarantee of success. You
must use the tools wisely and closely scrutinize your system from a security perspective. If ever
there was a time to practice solid software engineering, design, and implementation of secure
systems, it is now.
It is impossible to separate implementation errors from design problems. Recurrent security
problems are a clue that something is wrong with the way in which a system is being developed.
These problems are introduced at many different stages of system design and implementation. In
today's fast-paced consumerware market, security assurance is often among the first things to go.
Specifications, if they exist, are vague. Sometimes they are silent on critical points, leaving the
implementor to play a guessing game. What may seem to be a simple security bug often indicates
deeper problems in the development process.

New features introduce new security holes. Java has grown by leaps and bounds. With each
major release of Java, a number of new serious security holes have been discovered. This is not
surprising. It is exceptionally difficult to get everything exactly right in a complex system, and
security demands nothing less. Java 2 introduces many powerful new features into Java. Security
holes are likely to be discovered in the implementation and design of these features.

New classes of attacks keep appearing. Security attacks can be likened to rushing floodwater;
sometimes the places they flow are surprising. It is not possible to anticipate all future security
attacks, mostly because security attacks break systems in novel ways. Do not rely on using only
historical data for security analysis and protection. There is much more to real security expertise
than being able to recount stories of past compromises.

Humans are an essential element to consider. No system as complex as the Java platform can be
used without lots of human intervention. Java 2 provides a perfect example of this fact. Without
proper policy creation and management, trust-based security models are exceptionally dangerous.
Proper use of advanced technologies requires forethought, planning, and careful management. A
big part of this management is anticipating what real users of a system are likely to do, as well as
what real attackers are likely to do.

These lessons are relevant to each and every security-critical, Java-based system. Creating a secure
system is hard work, but it is quite possible to come up with a system that will have reasonable
security in the trenches and address a majority of risks as well.

CHAPTER SECTION:2

Section 2 -- Challenges for Secure Mobile Code

Java has risen to meet many important challenges of mobile code security. That means Java is by
far the most security-aware of the many mobile code platforms. If you want to use mobile code and
you are concerned with security, use Java. Of course, things are not perfect and there are still some
open problems. Here are a number of remaining challenges that secure mobile code systems,
including Java, must face.

Denial of Service
We spent some time discussing denial of service in Chapter 4, "Malicious Applets: Avoiding a
Common Nuisance." As we said there, denial of service is a difficult problem for computer security
that has yet to be addressed, not just in Java, but all over the network infrastructure. Successful
denial-of-service attacks have been carried out against ISPs by exploiting weaknesses in TCP/IP,
the protocol that is the life blood of the Internet. Java is not immune to the denial of service
problem, either.

Denial of service can be more or less serious depending on where the problem manifests itself. On
one hand, if a hostile applet crashes one user's browser by popping thousands of large windows, not
much real harm is done. On the other hand, if a servlet crashes an enterprise Web server, real harm
occurs. Our Chapter 4 discussion focused primarily on the client side; however, Java is making
inroads in places where denial of service takes on more urgency as a problem. Server-side Java is
one example. Another example can be found in systems with built-in Java VMs like Oracle8 or HP
Printers. The implications of denial of service for these systems is much greater than in the client
case.

New forms of denial-of-service attacks will be made possible with complex client-server systems
like RMI that make extensive use of networking, synchronization, and locks. Denial of service in
such a system becomes as easy as holding a lock. Distributed system applications will need to
apply timeouts and other mechanisms to mitigate the risks of an uncooperative process.

Dealing with denial of service is not an easy task. Limiting resource allocation is one solution.
Perhaps future versions of Java will include policy elements that can specify resource limits on the
basis of identity. That way, constraints can be managed according to where code is coming from
and how much it is trusted. These sorts of hooks do not yet exist in the Java 2 model.

Understanding Code Signing

There are a number of myths about code signing. Here are some of the most egregious:

Myth: Signatures denote authorship. The only thing a signature really tells you is who signed the
code. From this piece of information, people infer a sense of vouching; that is, if a piece of code is
signed, the implication is that the signer somehow vouches for the code. Unless you trust the person
or organization who signed a piece of code, code signing gives you nothing. In the end, code-
signing schemes simply amount to technological wrappings around a human trust decision.

Myth: If a signer is honest, the code is secure. Clearly, since all that a signature tells you is who
signed the code, the signature says absolutely nothing about the code's security. Even the best-
intentioned signer can only give you an honest opinion about the code, and that opinion might not
be worth much if the signer isn't a technical expert. Certification schemes may begin to change the
way this works if there are well-known, competent organizations that choose to vouch for certain
code properties. These organizations can have signatures that count as validation stamps.
Myth: Signatures imply accountability/liability. The legal ramifications of digital signatures and
what they denote have yet to be tested in the courts. Given the state of software liability in the
industry, it is unlikely that a signature will carry much legal weight in terms of liability.

Assuming these myths are properly debunked, there are still some real barriers to trust models
based on digital signatures. One of the main problems that will deeply impact the adoption of
signing-based approaches is the lack of a public key infrastructure (PKI). Without some way of
quickly and easily validating a signature, the market is unlikely to embrace code signing quickly.
Adding to any lethargy in adoption caused by the poor state of the PKI is the equally poor state of
tools for managing digital identities and policies (see Chapter 6, "Securing Java: Improvements,
Solutions, and Snake Oil"). In particular, issues of certificate revocation and storage loom large.

Secure Distributed Programming

Distributed computing is still in its infancy. Complex systems like CORBA reflect this. Managing
trust, identity, and policy in a distributed system is much more difficult than doing so on a VM-by-
VM basis using, for example, Java 2. Standards are emerging slowly, and there is much confusion
in the market regarding competing systems. Choices include Java's RMI, CORBA (encompassing
both IIOP and IDL), and DCOM (or one of its many marketing identities).

Common to all of these approaches is the problem of complex identity, which is not well
understood. Figure 9.1 shows why the problem is difficult. In real distributed systems not only is
code mobile, but other functionality is, too. Interprocess communication across different machines
can get hairy fast. RMI may not be equipped to handle some of the challenges that trust models
entail.

Figure 9.1 The problem of complex identity.

In this example, Bob's applet, running on Alice's VM is

communicating (possibly using RMI) with Donna's applet,
running on Charlie's VM. Creating usable policies for
situations like these is not well understood.

Being a True Multiuser System

The Java VM is not currently a replacement for a multiuser operating system. Neither is JavaOS a
real multiuser operating system. JavaOS in its current instantiations is meant only to run a single
Java VM. Object sharing and process firewalling rely on this fact to work. There are many
problems to solve before the VM can serve as a true multiuser environment, and researchers are
just starting to address them.

Persistence, Linking, and Versioning

Systems in which objects can be serialized (think of it as freeze-drying a process) and reconstituted
elsewhere (thawed out) are susceptible to the "environment problem," and it is likely that security
holes will be discovered in these systems. The problem is that there is no guarantee that the
environment in which an object is thawed will be remotely similar to the one in which it was
frozen. This can be a problem if the object assumes (as almost all code does) that its environment
doesn't suddenly undergo drastic changes. This kind of problem can easily lead to type-safety
problems and security risks.

The problem can be related to Descartes' brain in a vat experiment. In that venerable thought
experiment, seventeenth-century philosopher Rene Descartes (of "I think, therefore I am" fame)
asked how it is that we know for certain that our perceived environment is really there-that we are
not simply a brain in a vat that is being fed all the right data by a malicious demon. The unfortunate
answer is that we can't ever be certain.

If you substitute serialized code for the brain and the environment for the vat (and the controlling
demon), you can get the idea. Deserialized software will never be in the position to probe its
environment in order to discover where it really is or whether its environment is telling it the truth.
This is problematic when it comes to security parameters and types. Actually, this analogy works
well for mobile code in general.

Design for Security

Java offers a number of tools with which secure systems can be built. Obviously, this does not
imply that all systems written in Java that make use of its security features will be secure.
Designing a secure system takes much foresight and demands rigorous assurance at all levels of the
process. Risk-based security testing can help.

The best security-assurance approach begins with a system specification. Given a detailed-enough
specification, a thorough risk analysis can identify potential vulnerabilities and point out areas of
the system with the greatest risk. Security risk analysis includes characterizing threats and attacks
and working out attack scenarios based on potential attacks. For example, a specification may
prove vulnerable to playback attacks (a common problem among systems originally designed for
use on proprietary networks), decompilation (in which mobile code secrets can be divulged), or
cryptanalysis attacks (in which things like weak data integrity hashes can lead to complete system
compromise).
Given a thorough risk analysis of a system specification, the next step is to create a plan for probing
system security through testing. Note that the kind of testing we are talking about here is not
functional testing; it is risk-based testing related directly to the risk analysis. Functional testing tells
you only if your system meets design specifications and produces the right output. Risk-based
security testing tells you whether your system can be compromised by security attack. Security
testing is at its heart a creative endeavor that is only as powerful as the risk analysis on which it is
based. As such, security testing is no guarantee of security, but it certainly beats not testing for
security at all. By following a proper test plan, actual testing can be carried out on a live system.

External analysis for security is a good idea. Note that the definition of external can vary. At the
very least, a security review should be performed by a different team (within the same
organization) from the design team. Designers tend to be too close to the system and tend to
overlook security problems, even if they understand security well. In any case, it is essential that
external reviewers have a strong body of security expertise and knowledge on which to draw.
Analysis by external security experts may be warranted as well, although only for truly security-
critical systems.

Systems that are designed expressly with security in mind usually turn out better than those that are
not. One of the worst approaches to take is to try to bolt security on the side of an existing system.
This is especially true of systems that have been fielded successfully on proprietary networks (or no
network at all) and that are migrating to the Internet.

CHAPTER SECTION:3

Section 3 -- Software Assurance for Java

Many organizations creating security-critical code, especially those in the electronic commerce
arena, have reputations to protect. Banks, for example, are reluctant to talk about security problems
for good reason-bank customers expect their bank to have excellent security. No one wants to play
Russian Roulette with his or her money (unless, of course, he or she is in Las Vegas). The same can
be said of any organization that has essential information assets to protect. Strong security
assurance practices can help.

The main objective behind software assurance is making sure that software does what it is
supposed to do. Software assurance encompasses more than just security. The same core idea-
making software behave-is deeply entwined with software reliability and software safety as well.

Sound Software Engineering

The most effective way to make sure your code behaves itself and does not introduce unnecessary
risk is to practice sound software engineering. Following a reasonable development process is a
good start. Begin with a problem-analysis phase that delivers both a set of requirements and a high-
level specification. Develop a software assurance plan simultaneously, so that problems are
identified and removed as early in the development life cycle as possible. The earlier you remove
problems, the more money you save.

Unfortunately, many software organizations creating software for the consumer market have poor
software development practices. Partly because of supercompressed development schedules,
specifications are rarely created. Without a specification, it is not possible to undertake a proper
security analysis.

Lack of a specification makes testing harder, too. There are two main constraints on testing in the
real world: 1) Exhaustive testing is known to be impossible (one of the fun results of theoretical
computer science) and 2) testing resources are always limited. This implies a direct need for ways
to optimize testing and get the most bang for your testing buck. In terms of security assurance, a
risk-based approach to testing is very cost effective. (See page 250.)

Automated tools and methodologies can help make software assurance more effective as well. The
days in which software analysis and testing was a black art are ending. A number of technologies-
for example, code coverage analysis-are entering the mainstream. Test tools can be just as effective
for security analysis as they are for more standard functional testing, especially when they are
wielded by security experts. Advanced assurance methodologies like software fault injection are
also maturing into powerful tools [Voas and McGraw, 1998].

The best approach to security is to design security into a system instead of adding it later. The
earlier in a development process that this can happen, the better. Risk analysis can be applied at all
levels of the software process, from requirements to finished process. Together, risk analysis and
testing for security result in a strong methodological approach.

CHAPTER SECTION:4

Section 4 -- Should You Use Java?

By now you should know the authors' answer to this important question: Java has much to offer,
but its use should be managed wisely. Although one might like a simpler answer, there is no way to
properly make Java-usage decisions on anything other than a case-by-case basis. The way to make
your own decision about Java is to start by assessing your risks. What could you lose? The next
step is to weigh the risks against the benefits. Is what you gain worth the potential loss?

Java has lots to offer. It's the most viable attempt so far to provide secure mobile code. Java is
deeply tied to the Web and comes with many advanced networking features. Java is powerful and
can be used to write full-fledged programs. Java is a more portable application language than any
other on the market today. Java includes advanced language features that all developers should
have access to. To top it off, Java is truly concerned with security.
On the other hand, by using Java, you are taking risks. Security can never be completely
guaranteed. Anyone who tells you it can is wrong. By connecting your computer to the Net at all,
you have decided to take some degree of risk. If you're willing to do that, then you should probably
be willing to use Java. Then again, there are things about Java that set it apart from other languages
and Internet services. For one thing, Java makes running someone else's untrusted code a normal
event!

The previous chapters have explained the current Java security model. Included in that discussion is
an analysis of the vulnerabilities found thus far. Hostile applets-both in the serious attack applet
guise and in the malicious applet guise-are a possibility that needs to be taken seriously. Security
research on Java will continue to expose problems in the future. The security community, working
closely with Sun Microsystems and the Java licensees, will make sure each new vulnerability is
quickly and properly patched.

In addition to discussing particular bugs in the current Java implementations, we have also
examined some more general concerns. Hopefully, most of these will be addressed in the
enhancements planned for the near future.

Finally, we have introduced some guidelines by which Java can be developed and used in a more
secure manner. If you are a Java developer (or a development leader), you can use our developer
guidelines to defend your code against security attacks. If you are a Java user (or part of an
enterprise built around Java), you can use our user guidelines to mitigate common risks.

We hope this book continues to prove a useful reference on Java security. Armed with this
information, you can make informed decisions regarding Java use for yourself and your business.

How to Sign Java Code

This tutorial was put together by John Viega and Tom O'Connor, both research associates at
Reliable Software Technologies. The four major sections each describe a separate vendor's code-
signing tools, including:

• Netscape's Object Signing

• Microsoft's Authenticode
• Sun's JDK 1.1 Code Signing
• Sun's Java 2 Code Signing

Some of the tools are tricky to figure out and use. This tutorial should help.

Before you dig into this tutorial, you should read Chapter 3, "Beyond the Sandbox: Signed Code
and Java 2," which discusses the major impact that signed code has on the Java security
architecture. Of special interest are the sections entitled Signed Code (see page 88) and Trust
(see page 92). The material there discusses the notions of trust, digital signatures, and certificate
authorities.

Appendix C Sections

1. Signing Classes with the Netscape Object Signing Tool

2. Signing Java Applets with Microsoft's Authenticode
3. Comparing Authenticode to Netscape Object Signing
4. Signing Code with Sun's JDK 1.1.x
5. Differences Between Netscape Object Signing and JDK 1.1.x javakey
6. Signing Code with Sun's Java 2
7. Differences between JDK 1.1 Code Signing and Java 2 Code Signing
8. In Conclusion

How to Sign Java Code

CHAPTER SECTION:1

Section 1 -- Signing Classes with the Netscape

Object Signing Tool
First in our tutorial, we'll take on Netscape's Object Signing Tool that can be used to sign Java code
(among other things). As in all of these systems, step one is obtaining an identity.

Getting a Certificate

Most digital signature schemes (PGP being a notable exception) involve the use of a Certificate
Authority (CA)-an organization that can vouch for someone's signature. After all, why trust code
just because it carries a signature? We need an objective third party to make sure people are who
they say they are. That means the first task in code signing is to obtain the proper credentials from a
CA. There are many CAs that can sell you certificates for signing Java code.

Netscape has links to CAs that support their Netscape Object Signing Tool
at https://certs.netscape.com. You can visit that page and pick a CA. Make sure that the CA you
choose provides a certificate that can be used to sign objects (some certificates can't).

VeriSign offers many flavors of Digital IDs. It heads up Netscape's list of CAs. We'll use VeriSign
as an example for obtaining a certificate; however, note that the process will differ depending on
the CA that you choose. To get a VeriSign certificate for Netscape Object Signing, select Software
Developer ID from the popup list at the top of VeriSign's homepage. Choose Netscape Object
Signing from the page that follows. There are two kinds of Software Developer IDs: a Class 2
Individual ID, and a Class 3 Commercial ID. The Class 2 ID costs $20 annually, while the Class 3
ID is a whopping $400 annually. For our purposes, we'll focus on Class 2 certificates. After
selecting Class 2, fill out the information form that asks who will be identified by the certificate
(making sure to include the all-important billing information).

VeriSign will do a limited background check on you before it will issue a certificate. For example,
it checks the data you enter against information publicly available on you through a credit check. If
your request for a certificate is accepted, VeriSign will email you a PIN and a URL that you can
use to retrieve the certificate. For an individual Class 2 certificate, the verification process is
usually close to instantaneous.

Once you receive that information, open the URL with Netscape Communicator and then enter
your PIN. Communicator will install the certificate in itself automatically. If you are using a shared
version of Communicator, someone may have already entered a password for the certificate
database that is stored in your browser. You will need this password before you can download and
install your certificate; otherwise, you will be prompted to enter a password for the certificate
database. Although this password is optional, it does prevent people from starting up your version
of Netscape and stealing your certificate by exporting it. You definitely don't want your certificate
stolen, because then other people can sign applets as you. Password information can be found in the
Security Info box of the Communicator menu, under Passwords.

If everything is successful, your certificate will appear in the Security Info box; check by going to
Yours under Certificates.

There are several things to know as you sign up for a certificate:

1. You do not want a Class 1 certificate, as it cannot be used to sign objects.

2. Use Netscape Communicator (4.x), even though you are allowed to request and download a
certificate using Netscape Navigator 3.x, because the support for certificates in 3.x is not as
good as it is in later browsers. For example, object signing tools may not be able to locate
your certificate inside Netscape 3.x. Also, you may not be able to export your certificate,
which is useful if you want to sign code from a machine other than the one from which you
originally downloaded the certificate.
3. Use the same browser on the same computer both to request and to retrieve the
certificate. If the browser is set up with multiple user profiles, make sure you use the same
user profile as well; otherwise, you will likely be unable to retrieve your certificate.
4. Finally, note that many versions of Netscape Communicator will be unable to verify your
certificate (assuming you got a VeriSign certificate). Unfortunately, information concerning
this problem seems to have disappeared from the Netscape Web site.

Exporting and Importing Certificates

It is a good idea to export your certificate to a file, just in case you install a new version of
Communicator over your old one. Doing so also allows your certificate to follow you to other
machines.

To export a certificate, bring up Communicator's Security Info dialog box. Select the certificate you
wish to export by clicking on its name. Then, click on the Export button. At this point, you may be
asked to enter the password that protects your local browser's certificate database. Next, you will be
asked to enter a password to protect the certificate data. This password is used to make sure that no
one can steal your certificate if he or she sees an exported copy of it somewhere (unless that person
is able to crack your password, so choose wisely!). To make sure you typed the password in
correctly, you will be asked to enter it again. Assuming you've entered the same password both
times, Netscape will prompt you for a filename, which it will use to store the certificate. Once you
enter the filename, you're finished exporting the certificate. You can copy that file to another
machine so you can sign code from there as well.

To import a certificate into a new browser, bring up Communicator's Security Info box. Click on
Yours, which is a subitem of Certificates. Press the button, Import a Certificate. If you have not
previously entered the password protecting the certificate database of the local copy of Netscape,
you will now be prompted to enter it. After you enter the correct password, a file dialog box will
come up; use it to select the file containing your certificate.

Once you have selected the file, you will be prompted for the password used to protect the
certificate, which is the password that you entered when you exported the certificate. At this point,
assuming all has gone well, you should get a dialog box indicating success.

Netscape Object Signing Tool 1.1

The Netscape Object Signing Tool is a command line program that creates digital signatures for
files. These signatures aren't stored in the files themselves; they're stored in the JAR file in which
you bundle your applet. Note that since digital signature information is transmitted in JAR files,
you must package your applets in a JAR file in order to sign them, even if they consist only of a
single class. The important syntax for using a JAR file with the HTML APPLET tag is:
<APPLET CODE="somefile.class" ARCHIVE="jarfile.jar">

where somefile.class is the class in the JAR file where execution should begin, and jarfile.jar is the
URL of the JAR file. The Netscape Object Signing Tool may be downloaded
from developer.netscape.com/software/signedobj/jarpack.html.

The tool is available for most operating systems. While, as of this writing, version 1.0 is still
available for download, we recommend that you use version 1.1.

After the download is complete, unpack the archive file in a directory. Included are three files:
readme.txt, license.txt, and signtool. To make signing objects easier, put the directory that contains
signtool in your PATH environment variable, as per your operating system. For example, a
Windows 95 user who unpacked the tool to C:\nos would run the following line (and then add it to
the autoexec.bat file):
PATH=%PATH%;C:\nos

Before attempting to sign anything, check to see if signtool is able to locate the certificate that will
be used to sign objects. Unix flavors of signtool look for certificates in the $HOME/.netscape. If
your local Netscape files are kept somewhere else, or if you are using the Win32 version, signtool
must be explicitly told the path to the certificates. This is done with the -d flag. On Win32, this path
is commonly c:\Program Files\Netscape\Users\name, where name is the name of your Netscape
Profile. To verify that your signing certificate was installed properly, runsigntool -l or, if
your certificate cannot be found,
signtool -d"<path to certificates>" -l

For example, if your certificates were stored in C:\nos, you would type:
signtool -d"C:\nos" -l

If your certificate still does not appear in the listing, verify that the certificate is installed in
Netscape properly. (See the instructions given earlier). Also check that the path to the Netscape .db
files was properly specified. If all else fails, check with Netscape and the issuing Certificate
Authority. Make note of the full name of your certificate as it appears in the listing, you will need
these data when it comes time to sign.

Create a directory in which to put all the class files for the applet you wish to sign. Once all the
class files that make up the applet are in the right place, the signtool program can create a signed
JAR file in one step.

Navigate into the directory containing the soon-to-be signed classes. To sign the classes and create
a JAR file in one step, issue the command:
signtool -d"" -k"" -e ".class" -Z myjar.jar .

If your Communicator Certificate Database is password protected, signtool will prompt for the
password before signing the classes. The "." at the end of the command should be the last thing to
appear. It specifies that the signing should begin in the current working directory. The signtool
command recursively signs files by default. To keep the tool from recursing through directories,
add --norecurse to the command line.

Here's a brief explanation of the flags used in the previous example, as well as some of the other
more useful flags for signing applets:

-k "certificate name": Specifies the certificate with which you would like to sign. This flag is
necessary when signing an applet. The certificate name should be the entire name of the
certificate as it appeared as the output of signtool -l. Since the certificate name is likely to have
spaces in it, make sure you place it in quotes; otherwise, the signing will fail.
-e".extension": Specifies the file extensions to sign. If you don't include this flag, the tool will sign
all files, as opposed to the preceding example, which uses this flag to sign .class files only.

-x"name": Allows you to sign all files except a particular file or directory. An example where this
might be useful is when you are using an untrusted library in your applet. You probably will not
want to vouch for code you did not write!

-Z"jarfile": Specifies the name of the JAR file to create. If you omit this option, you will have to
JAR everything up yourself.

When the JAR file is created, signtool can be used to test the validity of the signatures. This is done
by issuing the command:
signtool -d"<path to certificate>" -v myjar.jar

signtool will list the contents of the JAR and verify that they have been signed, and that they have
not been tampered with since the signature was created.

You may also check to see who signed the JAR file:
signtool -d"<path to certificate>" -w myjar.jar

signtool can be used to sign anything, not just Java files. In fact, it can extract JavaScript from
HTML files, and sign just the JavaScript; however, that functionality is outside the scope of this
tutorial. Documentation on signtool is available from Netscape
atdeveloper.netscape.com/docs/manuals/signedobj/signtool/.

Adding Capabilities to Your Classes

As Chapter 3 describes, signing a Java applet does much more than just allow people to verify that
you signed it. It can also give your applets the chance to step outside the Java sandbox. If your
applet has a digital signature vouching for it, then the applet may request special privileges, such as
accessing the file system. However, the user of the applet doesn't have to let your applet do what
you request just because you sign it.

The special privileges an applet can request are called capabilities by Netscape.1 Predictably, no
two browsers support flexible privileges in quite the same way, so privilege-management code will
only work with one browser. (So much for "write once, run anywhere"!) As a result, while
Netscape keeps its own internal version of these classes, in order to actually compile and test an
applet that can request them, you must download the library from developer.netscape.com/ docs/
manuals/signedobj/capsapi_classes.zip

Put the zip file in your CLASSPATH (or otherwise edit the CLASSPATH). Now you will be able
to develop code that requests extra privileges in Netscape. Note that you should not include these
classes with your applet; the Netscape browser running on the remote machine will use its internal
version of the classes.

The Capabilities library provides a class called the Privilege Manager that handles requests from
the program to turn on and off privileges. When the first request to enable a certain privilege is
made, the Privilege Manager prompts the browser's user, showing the certificate used to sign the
code requesting the privilege, and asking whether the privilege should be granted. See Figure C.1.
If the user agrees to grant the privilege, the privilege is granted for the lifetime of the applet.
However, once the applet has obtained a privilege, it can turn the privilege off and on at its
discretion.

Figure C.1 Netscape Navigator's Privilege Manager alerts a browser user with this window.

The dialog box explains which dangerous privileges have been requested and who is vouching for the applet
(through a digital signature). Clicking the "Remember this decision" is probably a bad idea.

To request a particular privilege to be enabled, you use the static method enablePrivilege() of class
netscape.security.PrivilegeManager. The method takes a single String argument, which is the name
of the privilege to enable. Some useful privileges include:

UniversalFileAccess: This privilege gives the applet the ability to access any file available
to the user. It will enable the applet to call most things in the java.io package related to file
manipulation. This privilege is a superset of other file manipulation privileges that may be
requested individually, such as UniversalFileRead, UniversalFileWrite, and UniversalFileDelete.

UniversalSendMail: This privilege allows the applet to send email on behalf of the user.
UniversalExitAccess: Allows the Java applet to shut down the Netscape browser.

UniversalExecAccess: Enables the applet to run programs already stored on the user's local
computer.

PrivateRegistryAccess: Grants access to application-specific portions of the computer's

registry (Win32 only).

There are many more privileges that an applet can request. For a full list, see the documentation for
the Capabilities API atdeveloper.netscape.com/docs/manuals/signedobj/capabilities/01cap.htm.

A call to enablePrivilege will throw an exception that the applet must catch if the user decides not
to grant the privilege specified in the call. Thus, the applet must be prepared to catch instances of
netscape.security.ForbiddenTargetException. Here's a sample applet called FirstTry.java that uses
enablePrivilege

import java.applet.*;
import java.awt.*;
import netscape.security.PrivilegeManager;
import netscape.security.ForbiddenTargetException;

public class FirstTry extends Applet {

private TextArea ta = new TextArea(10,100);

public void init() {

this.add(ta);
this.show();
try {
PrivilegeManager.enablePrivilege("UniversalFileRead");
ta.appendText("Read enabled!\n");
}
catch (ForbiddenTargetException fte) {
ta.appendText("Read not enabled.\n");
ta.appendText(fte.toString());
}
catch (Exception e) {
ta.appendText("Unexpected exception!\n");
}

public void paint(Graphics g) {

}
}

The FirstTry applet doesn't do anything with the privilege it asks for, even if it is granted. However,
it would be able to read any file, including the system password file on a Unix system, if it tried.
That could be considered an abuse of privilege. Another potentially bad thing this applet could do
would be to put the enablePrivilege call inside the paint method. Doing this will cause the browser
to continually prompt the user for permission every time paint is called, which will happen until
permission is granted, or until the browser is killed. Actually, the Netscape Grant/Deny window has
a checkbox that says "Remember this decision." Checking the deny box will make this pop-up
never appear again. The take home message is that signed applets can be hostile too.
When you enable a privilege, it does not have to stay enabled for the entire execution of the applet.
There are a couple of ways to turn privileges off (which is always a good idea). First, when the
method that calls enable Privilege returns, the privilege will automatically be disabled. As a result,
you should not use a helper method to enable a privilege, because once execution returns from that
method, the privilege will no longer be enabled. Second, you can call revert Privilege, which also
takes the name of a privilege as an argument. Finally, you can call disable Privilege, which turns
off a particular privilege. In no case will the granting of the privilege be revoked; the applet can
turn the privilege back on by simply calling enable Privilege again. To see an example of a signed
applet, surf to www.securingjava.com/dpig/netscape.html.

CHAPTER SECTION:2

Section 2 -- Signing Java Applets with Microsoft's

Authenticode
Next in our tutorial, we'll take on Microsoft's code-signing system for Java. It's a bit peculiar since
it does not interact with the JDK 1.1 or Java 2 security models in an intuitive fashion. As usual, step
one is securing an identity.

Getting an Authenticode Certificate

There are several ways to get a certificate for Microsoft Authenticode. One of the things you can do
is generate "test certificates," which allows you to try things out. We'll tell you how to do that in a
bit, if you just want to play around. However, if you plan on distributing any code, you're going to
want to get a real digital ID. This costs money. A number of vendors distribute certificates, one of
them being VeriSign, which we'll use in our examples.

To obtain a VeriSign certificate for Authenticode, point Internet Explorer

to digitalid.verisign.com/developer/ms_pick.htm.

Select a flavor of ID. For personal use, select a Class 2 ID. For business use, select Class 3.

You'll be given a form to fill out. Note that the personal Class 2 ID is $20, and you'll have to pay by
charge card. Once you submit the form, VeriSign will try to verify you are who you say you are,
mainly by running a credit check. Sometimes the credit check won't have up-to-date information,
so if you get rejected and you can remember the address for the last place you lived (which is the
most common problem), you might want to try it again using old information, pretending you never
moved. (Not that we condone this strategy, mind you.)

Once your data are approved, VeriSign will send you an email with instructions on picking up the
certificate. When downloading your certificate, two files will need to be saved: your private key
file, and your certificate file. You should probably save these files to a floppy disk instead of your
hard drive, so that someone can't just snag your certificate off your computer (although, without
knowing the password you use to protect your private key, snagging the files alone may not do a
bad guy much good). Remember the password used to protect the private key; it will be needed
when it comes time to sign code. For the sake of simplicity, we'll assume you saved your certificate
as a:\Cert.spc and your private key as a:\Key.pvc.

Getting the Signing Software

Before signing anything with the new certificates, download and install the Microsoft Java SDK.
It's located atwww.microsoft.com/msdownload/java/sdk/31f/SDK-JAVA.asp.

We'll assume you installed the Java SDK in the directory C:\SDK-Java.31.

All of the programs we're going to need for signing Java code live in C:\SDK-
Java.31\Bin\PackSign, so you should probably add that directory to your PATH. Under Windows
95/98, running the following command at the DOS prompt will fix up your PATH for the current
session:
PATH=%PATH%;C:\SDK-Java.31\Bin\PackSign

You can add that command to your autoexec.bat file to make the change persist through a reboot.

Cabinet Files

Unlike Netscape's Object Signing and Sun's signing tools (which work on JAR files), Authenticode
signing will only work on cabinet (CAB) files. There's nothing special about the CAB format; it's
just another way of archiving many files into one. However, it's the only archive format IE supports
for signing Java code.

Say we have an applet that consists of two files: file1.class and file2.class. We can create a CAB
file in the same directory by typing the following at the DOS prompt:
cabarc N test.cab file1.class file2.class

If there are no other class files in the directory, we can also type:
cabarc N test.cab *.class

Security Zones
In order to understand what we're doing when we sign a CAB file, we need to know a little
something about what an IE "security zone" is. By default, a security zone is a group of Web sites.
Each zone is assigned a security level, which may be Low, Medium, High, or Custom. We won't
cover Custom zones, except to say that they can implement arbitrary security policies. For more on
security zones, see Chapter 1, "Mobile Code and Security: Why Java Security Is Important."

There's a default zone called Trusted Sites, into which a user can put any server. All code from that
zone will be completely trusted (i.e., the zone has a Low security level). Similarly, there's a
Restricted Sites zone. Any sites the user puts in this zone will need explicit permission before they
can run anything "outside the sandbox." By default, most everything else falls into the Internet
zone, which is assigned a Medium security level. Code can run outside the Java sandbox in a very
limited manner. For example, code can use up to 1 megabyte of data on your hard drive by using
the API com.ms.io.clientstorage, which is included with Microsoft VMs only. (So much for "write
once, run anywhere"!) Unlike fully trusted applets, applets restricted to the Medium security level
should not otherwise be able to use your file system.

We're going to sign our cabinet file, requesting to run either with Medium or High privileges (we
can also request Low privileges, but since we'll always be allowed to run in the sandbox, doing so
is mainly useful only to show you vouch for the CAB file). If our code ends up in a Low security
zone, our code will always run without prompting the user for permission. If our code ends up in a
Medium security zone, then before code that requests Medium level privileges can run, the user
will be prompted as to whether to let the code run. If our code ends up in a High security zone, all
code that wants to run outside the sandbox will need to be approved through a dialog with the user.
See Figure C.2.
 Figure C.2 The security warning dialog used by Microsoft Internet Explorer's Authenticode
system.

This dialog explains who has vouched for the code (by signing it) and what permissions are being
requested. Clicking "Always trust content from <user>" is probably a bad idea.

Signing CAB Files

To sign test.cab, we're going to use the signcode command, which is included in the Java SDK.
Here's a typical command line:
signcode -j JavaSign.dll -jp High -spc a:\Cert.spc -v a:\Key.pvk -n "My Applet" -i
http://www.mywebpage.com/ test.cab

The flags here are a bit arcane. If you want your CAB file to request permissions, the -j flag should
always be there, and take JavaSign.dll as a parameter, unless you're signing something other than
Java code (the same command can be used to sign ActiveX controls and other mobile code, too).
The -jp flag passes a parameter to the DLL. For Java signing, that's how we request High
privileges. The -spc flag and -v flag are used to specify the location of your certificate and private
key, respectively. The -n option needs to be present, and it specifies the name of the software,
which is displayed to the user before the user decides whether to run your code. The -i option
specifies where to go for more information about the product, which also gets displayed when the
user is prompted to give your code permission to run.

You can also "timestamp" your signature, so that after your certificate expires, your applet will still
work. However, doing so requires a timestamp server, which isn't covered here. For more
information on Authenticode for Java, visit www.microsoft.com/java/security.

To confirm that everything has worked properly so far, run the command:
chkjava test.cab

A window should appear similar to the one an end user will see when IE asks if the application
should be allowed to run.

Making Test Certificates

To avoid putting down some cash for a real certificate from a CA and still be able to play around
with Authenticode, you can make a test certificate. The first step is to create the certificate with the
command:
makecert -sk Key.pvk -n "CN=Your Name" Cert.cer
That command makes a certificate and a private key you can use in other applications, but it won't
work for code signing. To get it to work with code signing, convert it to a Software Publisher
Certificate (SPC) by typing:
cert2spc Cert.cer Cert.spc

When you're finished with that, you can use Key.pvk and Cert.spc for testing purposes in the same
way as if they came from a CA.

Special HTML Tag

When deploying a signed CAB file in an HTML page, a slight variation on the <APPLET> tag is
necessary. As with all applets, the name of the class that extends java.applet.Applet goes in the
CODE attribute. However, instead of putting the name of the CAB file in the ARCHIVE attribute
as is done with JAR files, CAB files signed with Authenticode are passed using the PARAM tag.
As an illustration, the tag to embed into a web page the signed applet "MyApplet" stored in
myapp.cab would look like:
<APPLET CODE="MyApplet.class"> <PARAM name="cabbase" VALUE="myapp.cab"></APPLET>

The named prameter "cabbase" is how Internet Explorer finds the CAB file containing the class
specified in the CODE attribute.

CHAPTER SECTION:3

Section 3 -- Comparing Authenticode to Netscape

Object Signing
Microsoft's Authenticode model is somewhat simpler than the Communicator model for the end
user. Assuming the user doesn't know anything about zones, lots of stuff runs without asking the
user for permission; the user is prompted only to approve code generally when the code requests
full access, and doesn't already have permission. Less interaction generally means less hassle for
the user. You can make more dialog boxes disappear if you check boxes like, "always trust code
from this person," and "always trust code from this site," which appear in the window that
announces that code is trying to gain permissions. However, spreading trust around so easily just to
avoid dialog boxes can have bad consequences.

Authenticode is also simpler for the developer. There's no need for calls to a Capabilities library,
meaning you can simply request an access level, as opposed to requesting a set of privileges.
However, Netscape is capable of finer-grained access control, which allows the applet to secure
only the resources it needs to run without a user feeling the need to give a program complete access
to the computer.
Another convenience of Authenticode over Object Signing is that the user only gets prompted at
most once per applet. Netscape prompts the user whenever new privileges are requested (which is
usually during execution). While the Netscape model is more intrusive, it does afford the user a bit
more control over what privilege is granted to an applet.

CHAPTER SECTION:4

Section 4 -- Signing Code with Sun's JDK 1.1.x

Sun makes its own set of signing tools. The tools have evolved along with the JDK. We'll briefly
cover both the JDK 1.1 tools and the Java 2 tools.

The JDK ships with a command-line tool called javakey. Its job is to manage a database of entities
(people, companies, etc.) and their public/private keys and certificates. It is also supposed to
generate and verify signatures for archive files; however, verification is not implemented as of JDK
1.1.7.

As Chapter 3 describes, an applet contained within a digitally signed JAR file is allowed to leave
the bounds of the Java sandbox under certain circumstances. In JDK 1.1, if a JAR is signed and the
user who has browsed to the Web site containing the applet has a policy stating that he or she trusts
the person who signed the JAR, the applet can do anything at all that Java code is capable of. For
example, it can read and write from the file system, start another process running on the computer
(outside of the browser), open a network connection to an arbitrary machine, or myriad other tasks
that applets are not normally allowed to do. In other words, trusted signed code under JDK 1.1 is as
powerful as Java application code from the JDK 1.0.2 days. Remember, under JDK 1.1, we're
operating under a black-and-white security model.

To get going with code signing in JDK 1.1, there are few things to gather. On the development side,
an applet that tries to perform actions that aren't normally allowed by the Java sandbox is needed
(or at least one that can be augmented to attempt such an action). The most rudimentary operation
that a signed applet can do that an unsigned applet can't do is read the user.name System property.
An example applet follows:

public class UserApplet extends java.applet.Applet {

public void init() {
String username = "user: ";
try {
username += System.getProperty("user.name");
} catch (SecurityException se) {
username += "cannot read";
}
showStatus(username);
}
}
A signed applet containing the preceding code (running in a browser of a user who trusts the entity
that signed the applet) will be able retrieve the name of the user running the applet and display it in
the status bar of the browser.

Once the applet to be signed and its containing Web page have been created, the class files that
contain the applet must be put into a JAR file. Even if the applet in question is only one class, it
must be placed inside a JAR file. It is not possible to sign standalone class files.

In order to sign Java code with javakey, a signing certificate needs to be created. Once this
certificate is created, it can be used to sign the JAR file and distributed to users who wish to allow
the signer's applet full access to their system.

Creating a Signing Certificate

A file called identitydb.obj stores all certificate information and lives in the directory specified by
the Java System Property value user.home. For Unix Java users, this value evaluates to $HOME.
For Win32 users, user.home can take a number of values. Different VMs assign the value of
user.home either to the USERPROFILE directory, to the HOMEDRIVE\HOMEPATH directory, or
when all else fails, to the value of the java.home System Property. To clear up any ambiguity, write
and run a simple Java containing the line:
System.out.println("user.home= " + System.getProperty("user.home"));

Regardless of user.home, the location of identitydb.obj can be set explicitly by adding an

identity.database entry to the java.security file that lives in the lib subdirectory of the java
installation, wherever that may be on the system.

First, the signer's identity must be created in the database. To create an identity, signername, that
will be able to sign objects, run the following command on the command line:
javakey cs signername true

Now that a signer has been created, that signer's public and private keys must be initialized. Keys
can be between 512- and 1024-bits long. To initialize public and private keys for a signer, run the
following command (where # is a number between 512 and 1024):
javakey gk signername DSA #

Higher numbers mean more security. We recommend always using 1024-bit keys. The parameter
DSA signifies the algorithm used to generate the keys. The JDK only comes with the DSA
algorithm by default.

To verify that all has gone well so far, run:

javakey ld
This command will list all the information in the current identity database. The entry for
signername should identify it as a trusted signer as well as noting that the public and private keys
have been initialized. The next step generates a certificate that will be valid for signing JAR files.
This is different from Netscape Object Signing in that there is no Certificate Authority involved.

First, a directives file must be created. The directives file is a Java Properties file that provides
values used during certificate generation. Here are the contents of an example directives file:

issuer.name=signername
subject.name=signername
subject.real.name=Sol S. Signer
subject.country=US
subject.org=Signing Corp
subject.org.unit=Development
start.date=22 Jul 1998
end.date=16 Aug 1999
serial.number=41

To generate the certificate once the directives file exists, run:

javakey gc directivesfile

To verify that the certificate was generated properly, run:

javakey ld

Look for the signername entry to have the subject.* information from the directives file listed.

Everything is now finally set for signing. The command actually used to sign a JAR file also
requires a directives file. This is a different directives file than the one used to generate the signing
certificate. The first directives file used to generate the certificate will no longer be needed, unless a
different certificate needs to be generated. The second kind of directives file is used whenever a
JAR gets signed, and should be kept handy. An example directives file for signing a JAR looks like
this:

signer=signername
# look at javakey ld for certificate numbers, should be 1
cert=1
# chain unsupported, must have as value=0
chain=0
# must be 8 characters or less and not conflict with any other
# digital signatures that could be inserted into the JAR
signature.file=anything
out.file=Signed.jar

Once the signingdirective file has been created, run the command:
javakey gs signingdirective UnsignedApplet.jar

Running this command will generate Signed.jar, which will be a signed version of
UnsignedApplet.jar. Putting Signed.jar in the ARCHIVE field of the APPLET tag in an HTML
page will cause a Java-enabled browser to bring the JAR file over the network and execute the
signed code contained within. For more information on javakey, the official Sun documentation for
Solaris can be found atjava.sun.com/products/jdk/1.1/docs/tooldocs/solaris/javakey.html.

The Win32 specific version can be found

at java.sun.com/products/jdk/1.1/docs/tooldocs/win32/javakey.html.

Testing the Signed Applet

Now that a signed applet exists, and it is embedded within a Web page, it's ready for testing before
release. Testing requires either appletviewer or a Web browser that knows how to validate JARs
signed by javakey and allows signed JARs to leave the sandbox. Unfortunately, neither of the two
major browsers (Netscape Communicator and Microsoft Internet Explorer) support javakey-signed
JARs.

HotJava and the appletviewer program that comes with the JDK can validate JARs signed by
javakey. They will allow signed applets out of the sandbox if the signature is valid and the policy
states that the user whose signature appears is trusted. Both of these programs search for the
identitydb.obj in the same manner that javakey does.

The problem is that no one should be surfing the Net with HotJava (too dangerous), and the
appletviewer cannot be used to browse the Internet. Since the VMs in Communicator and Internet
Explorer do not support javakey signing, in order run javakey-signed applets with those browsers,
users must download and install Sun's Java Plug-In.

Java Plug-In for Communicator and Internet Explorer

Java Plug-In can be used to run applets instead of the browser's default VM. The Java Plug-In can
be configured to use the most recent version of the Java Runtime Environment available from Sun.
When an applet is run through the Java Plug-In instead of the browser's default VM, javakey-
signed JARs can be verified and can step outside of the sandbox (if policy allows).

Users must download the Plug-In from Sun and install it on their system. The download page for
the Plug-In isjava.sun.com/products/plugin/index.html.

Applet developers also need to modify the HTML pages that contain their applets and modify the
<APPLET> tag. Applets that are in Web pages using the standard <APPLET> tag will still be run
by the browser's default page. The Plug-In will run applets only when it detects a different set of
HTML tags that specify an applet. Sun provides an application called HTMLConverter, which can
convert pages with the <APPLET> tag into pages containing tags that will launch applets using the
Plug-in. The HTMLConverter homepage is java.sun.com/products/plugin/converter.html.
Two things to note about using the Plug-In. On Solaris, JavaScript must be enabled for the Plug-In
to work properly. With JavaScript disabled, applets did not load or run when we tested the Plug-In
with Communicator 4.02 and 4.06.

On Win32, the Java Plug-In did not find the identitydb.obj file in the same place that javakey did.
This has to do with different versions of the VM setting different values of the user.home Property.
If you run into trouble, try moving the identitydb.obj file to a different location. Places to try are
mentioned in the section, Creating A Signing Certificate (see page 298).

Distributing Public Keys and Certificates

In order for someone to verify who signed a signed JAR, he or she needs the public key of the
entity who signed the JAR in the first place. Until the public key is distributed to people other than
its owner, no one but the owner can verify that an applet is signed and by whom. Once the signed
applet has been tested and has proven to be functional, it can be placed on a Web site for use by
others.

In order for the applet to escape the sandbox imposed by other people's browsers, users must have
the public key or certificate of the entity that signed the applet. Also, the user must tell the identity
database that he or she trusts the entity that signed the applet. Trusting the entity that signed the
applet allows the applet complete access to the host. Here's how to create a trusted entry:
javakey c signername true

To import the signer's public key contained in keyfile, run:

javakey ik signername keyfile

To import the signer's certificate (which contains the signer's public key) from certfile, run:
javakey ic signername certfile

The identity must be created in the database before trying to import either the public key or
certificate. In order to verify the signature on a signed JAR, you need only the public key of the
signer. Certificates include the public key.

The signer of the applet must make his or her public key (or certificate) available to users of the
applet in some way. It could be linked from a Web site, phoned in, or delivered through email.
Whichever way it is done, the identity must first be extracted from the identity database. To extract
a public key from the database to a file keyfile, use the command:
javakey ek signername keyfile

To extract signername's certificate number 1 to a file certfile, use the command:

javakey ec signername 1 certfile
The information in the keyfile or certfile should be given to those who want to create a policy that
allows applets signed with the identity to leave the sandbox.

CHAPTER SECTION:5

Section 5 -- Differences Between Netscape Object

Signing and JDK 1.1.x javakey
There are five major differences between Netscape and Sun's approach to code signing:

1. Netscape Object Signing only works within Communicator. JDK 1.1 signed applets can
work in any browser, although Netscape Navigator and Microsoft Internet Explorer both
require the installation of the Java Plug-In for the applet to leave the sandbox.
2. Netscape Object Signing requires getting a certificate from a certificate authority such as
VeriSign. JDK 1.1 users can generate their own certificates.
3. Netscape Object Signing requires no modifications to HTML tags. If the Plug-In is needed
for JDK 1.1 (in case you want to use IE or Netscape), the <APPLET> tag must be changed
by HTMLConverter.
4. Netscape Object Signing uses Netscape's own classes to step outside of the sandbox. A
Netscape-specific exception is thrown when permission to leave the sandbox is denied. JDK
1.1 javakey-signed applets do not need to include calls to any other non-java.* classes to
leave the sandbox, and java.lang.SecurityException is thrown when permission is denied.
5. Netscape Object Signing prompts the user when an applet attempts to leave the sandbox,
asking the user for permission to carry out the dangerous act. Actions are grouped, so the
user can allow some actions (file reads) but not others (file writes). JDK 1.1 javakey-signed
applets that are trusted get complete access to the host.

CHAPTER SECTION:6

Section 6 -- Signing Code with Sun's Java 2

The javakey tool from JDK 1.1 has been replaced by two tools in Java 2.

One tool manages keys and certificates in a database. The other is responsible for signing and
verifying JAR files. Both tools require access to a keystore that contains certificate and key
information to operate. The keystore replaces the identitydb.obj from JDK 1.1. New to Java 2 is the
notion of policy, which controls what resources applets are granted access to outside of the sandbox
(see Chapter 3).

The javakey replacement tools are both command-line driven, and neither requires the use of the
awkward directive files required in JDK 1.1.x. Management of keystores, and the generation of
keys and certificates, is carried out by keytool. jarsigner uses certificates to sign JAR files and to
verify the signatures found on signed JAR files.

Getting Started with Keytool

The first step in working with Java 2 is getting the latest beta version from Sun. Members of the
Java Developers Connection (JDC) can download Early Access releases of Java 2 software.
Membership in the JDC is free with registration. Once registered, point your browser
todeveloper.java.sun.com/developer/earlyAccess/jdk12/index.html.

The Win32 version of JDK 1.2beta4 comes with the latest version of the Java Plug-In, which
supports Java 2. During the Install, answer yes when it wants to know if the JRE and the Plug-In
should be installed as well-it will be needed later.

The keytool command operates on a keystore file. The name of the keystore file is .keystore by
default, and it is located in the directory named by the user.home Java System Property. It is
possible to have multiple keystores. Changing the keystore on which the current keytool command
will operate is done through the -keystore <path to keystore> option.

Documentation from the Sun Java Web pages states that Java 2 VMs will run and properly
authenticate JARs signed with JDK 1.1's keytool. It also states that the last beta release of JDK 1.2
does not yet support 1.1-signed JARs. The keytool utility also supposedly allows porting keys and
certificates from 1.1 identitydb.obj files into a Java 2 keystore. According to the documentation, the
command to perform the translation is:
keytool -identittydb -file <path to identitydb.obj file>

Unfortunately, an identitydb.obj file created with JDK 1.1.6 did not successfully import into the
keystore when we tested the keytool from JDK 1.2 beta4-we tried on both Win32 and Unix
platforms. The error message returned from keytool mentions an InvalidClassError and states that a
class used in key management became obsolete, resulting in a serialization error. Until this problem
works itself out in later beta and production versions, the certificates and keys used under 1.1
cannot be used in Java 2. New certificates and keys will need to be generated for use with jarsigner
and keytool.

Generating a public and private key pair and self-signed certificate can be performed from the
command line in one shot without the need to create any directives files. All keys and certificates
stored in the keystore are accessible through an alias. An alias is a name associated with a
certificate entry that keytool uses to uniquely identify each certificate under its control. To generate
a certificate keyed by the alias keyname, run the command:
keytool -alias keyname -genkey

keytool will begin prompting for information. The first prompt is for a keystore password, which
will be needed for all further keytool and jarsigner operations on this keystore. It must be at least
six characters long and is unfortunately echoed to the screen as it is typed. This means that the
keystore password can be leaked to casual observers whenever keytool or jarsigner is used.

Once the password has been entered, keytool prompts for some personal information, such as
name, company name, city, state, and country. All this information is stored in the generated self-
signed certificate, which is saved in the default keystore location. All the personal information is
displayed for verification before keytool generates the keys and certificate. After the certificate and
keys are generated, keytool prompts for another password. Each certificate has its own password,
separate from the keystore password. Entering nothing does not give the key an empty password. It
gives the certificate the same password as the keystore. jarsigner will not prompt for the passwords
of certificates that have the same password as the keystore, so it may appear that a certificate has no
password. However, if the password of the keystore changes, the passwords of the certificates do
not change, so jarsigner will start prompting for not only the password of the keystore, but for the
certificate as well. The command to change the password of a keystore is:
keytool -storepasswd

keytool will prompt for the old password, and the new password twice, all in cleartext. This
command does not affect the passwords of certificates in the keystore, including those that happen
to have the same password as the keystore.

An apparent weakness of the keytool certificate generation system is that a user can accept all the
default values for the personal information prompted for before certificate generation. The default
value for all the questions is "Unknown." So keytool will generate a valid certificate that can be
used to sign JAR files, but is filled with bogus information. No data validation is performed by
keytool, so it is possible to, say, create a certificate for Elvis.

Certificates generated by the system will be valid for just under one year by default. To change the
length of validity for a certificate to n days, add the flag -validity n to the keytool -genkey
command.

To view the fingerprints of certificates in the keystore, use the command:

keytool -list

To view the personal information about the issuer and owner of the certificate, run:
keytool -list -v

Signing a JAR

Once a private key has been generated, jarsigner can be used to mark a JAR file with the public key
of the signer. The command to sign a JAR file called SignMe.jar with the keyname private key
generated previously is:
jarsigner SignMe.jar keyname
jarsigner will prompt for the keystore password and the private key password if different than the
keystore password before signing the JAR file. To monitor the progress of the signing process, run:
jarsigner -verbose SignMe.jar keyname

jarsigner can also be used to verify that a JAR has or has not been signed, and by whom. For a
simple signed/not signed answer for a JAR file Unknown.jar, run:
jarsigner -verify Unknown.jar

To get more information from the verification process, such as the signing status of each file in the
JAR file, the personal information from the certificates used to sign each file in the JAR, and
whether or not the certificate is known in the default keystore, run:
jarsigner -verify -verbose -certs Unknown.jar

After each signed file in the listing will be the personal information encoded in the certificate for
the entity that signed the file. If that certificate is known in the keystore, the name it is known by
will appear in parentheses after the certificate's personal information.

Enter the CA

So far, the only changes from JDK 1.1 are the syntax and the names of the commands. Certificates
can be generated by keytool with any personal information at all. There is nothing to stop anyone
from creating a certificate that claims that it is owned by someone else and signing a JAR with it.
What a Certificate Authority can provide is a level of assurance that a certificate truly represents
the individual that it claims to represent. That is, of course, if you trust that a Certificate Authority
isn't being spoofed, and is properly checking the certificates it vouches for. (Recall, this way
madness lies.)

Certificates generated by keytool can be exported in a form suitable for submission to a Certificate
Authority such as VeriSign. This can be accomplished by running:
keytool -certreq -alias keyname -file requestfile

That command puts a Certificate Signing Request into requestfile for the certificate know by the
keyname alias. However, there is no information as to how to submit this data to a CA for
validation. According to the keytool documentation, the CA will validate the certificate and return
something that must be imported into the keystore. Although we haven't tested it, the command to
import the response from the CA into the keystore is supposed to be:
keytool -import -alias newalias -trustcacerts -file response

That command imports the response from the CA stored in a file called response into the keystore
under the name newalias, which must not already exist in the keystore. The -trustcacerts flag tells
keytool to check the response certificate against the five VeriSign certificates that come shipped
with Java 2 (at least there were five in JDK 1.2beta4).

Turning Over the Keys

Until the certificate used to sign the JAR is made public, no one can grant any permissions to the
enclosed applet. To retrieve a copy of the keyname certificate from the keystore into a file mycert,
use:
keytool -export -alias keyname -file mycert

As usual, keytool will prompt for the appropriate passwords. When the command finishes, the file
mycert can be distributed to users who wish to grant additional privileges to applets signed by that
certificate.

As in JDK 1.1, there is currently limited support for a JAR signed with the JDK tools. Again, Sun
provides support through the Java Plug-In. Plug-In version 1.1.1 does not necessarily support Java
2. Although the Java Plug-In can be configured to use different VMs installed on the local system,
the Plug-In hangs the browser when pointed to a Java 2 VM on Solaris. Documentation for the
Win32 version of the Plug-In mentions running a program off the Start menu to configure the Plug-
In. The installation script does not create a program group for a Plug-In Control Panel as advertised
under Windows NT unless the user performing the installation has permission to create program
groups.

An Early Access version of Plug-In version Java 2 for Solaris is available to members of the Java
Developer's Connection. The latest version of the Plug-In for Win32 ships with JDK 1.2beta4.

As with JDK 1.1, any HTML pages that contain Java 2-signed JAR files must be converted using
the same HTMLConverter used in JDK 1.1. Converting the HTML ensures that the applet will run
in the Plug-In and not in the browser's default VM. See the section on JDK 1.1 JAR signing for
information on where to get the HTMLConverter.

Running a Signed Applet

The first step upon encountering a signed applet is to locate the certificate of the entity that signed
the JAR file and import it into the local keystore. Assuming that the certificate can be located and
placed into a file called acert, run:
keytool -import -alias analias -file acert

An entry in the keystore is created keyed by the name analias for the certificate stored in acert. This
is now a trusted entity. Whereas in JDK 1.1, aliases could either be trusted or untrusted, all aliases
in Java 2 keystores are trusted. However, in JDK 1.1, trusted aliases could do anything they
wanted; aliases in Java 2 cannot do anything unless granted permission. Permissions are granted to
aliases through the use of policy files (seeChapter 3).

Creating a Simple Policy for Signed Applets

Java 2 introduces the notion of policy. Creating, understanding, and managing security policy for
signed mobile code is a difficult and complex problem. Since this discussion is about signing code
and not about constructing policy, an extremely simple example of how to construct policy is
presented. Creating good policy is beyond the scope of this tutorial. The example policy is strong
enough to allow an applet limited file access to the host machine.

Java policy files can be created with the new policytool. This application has a GUI to guide users
though the many twists and turns encountered when creating policy files. It's a very simplistic GUI
with no online help. In its current form as of beta4, it is only useful if one does not know the syntax
of a policy file.

Policy files are plaintext files that follow a format outlined

at java.sun.com/products/jdk/1.2/docs/guide/security/PolicyFiles.html.

The default security policy system first reads a system-level policy file from the lib/security/
subdirectory under the Java installation directory. It then tries to read a .java.policy file from the
current user's user.home directory. In this file, users specify their personal security policy, which
merges with the system security policy. Permissions that can be granted in a Java policy file are
outlined at java.sun.com/products/jdk/1.2/docs/guide/security /permissions.html, as well as
in Chapter 3.

If the policy file is to make reference to a certificate stored in a keystore, a keystore entry must
appear in the policy file. The keystore entry specifies the path relative to the policy file itself and
the name of the keystore file. To keep things simple and use the default keystore file, add the
following line to the .java.policy file in the user.home directory:
keystore ".keystore";

To grant an applet permission to write or create any file in the c:\tmp directory, assuming the applet
comes fromwww.friendly.com/~mybuddy/applets/ and is signed by a certificate known in the
default keystore as friend, add to the .java.policy file:

keystore ".keystore";
grant signedBy "friend",
codeBase "http://www.friendly.com/~mybuddy/applets/" {
permission java.io.FilePermission "c:\\tmp\\*", "write";
};

Note the double backslashes. All Win32 pathnames must use double backslashes to indicate
directories. Unix pathnames use regular singleton forward slashes. CodeBase follows URL syntax.
 Sign Only Privileged Code

Applets that request permission to leave the sandbox are usually built for greater purposes than
saving a high-score list on the local drive. Applets that do serious business and hence require access
to the local system are most likely some of the larger applets in existence. It is unlikely that these
applets will be built completely by one developer or one software company. Chances are some of
the components of an applet will be bits of utility code found on the Internet or purchased from a
tool vendor. A smart organization wants to sign only code that it produces; third-party utility code
cannot be safely vouched for.

If all the code is signed, then any code can leave the sandbox based on the policy. However, if
some code in an applet is from a third party, it should not be signed unless the individual signing
the code is willing to vouch that the third-party code won't try to do anything malicious (or
introduce a security hole that others can exploit). To say the least, we don't recommend signing
code you don't completely understand.

Java 2 presents an API for privileged blocks. Privileged blocks are meant to be small sections of
code that have a higher privilege than the code that invoked them. JDK 1.2beta4 introduced a new
API for privileged blocks. Using this API, the only code that needs to be signed is the code that
invokes the AccessController class, and the code that performs the privileged action.

All other code can remain unsigned, preventing it from leaving the sandbox on its own (or tempting
others to attack it). Documentation on the new API can be found
at java.sun.com/products/jdk/1.2/docs/guide/security/doprivileged.html.

There are two things to consider when writing signed code that will be integrated with unsigned
code. First, make the code in the privileged block as small as possible. The less code that is
privileged, the less chance that granting it higher privilege will result in nasty and unwanted side
effects. Second, to prevent mix-and-match attacks, all the code for the applet should live in one
JAR file, even if the third-party libraries that are used by the applet live in their own JAR. (See
Guidelines for Java Developers in Chapter 7, "Java Security Guidelines: Developing and Using
Java More Securely.")

To sign some portions of a JAR file and leave others unsigned takes a number of steps we'll cover
now. First, create a JAR file containing all classes that need to be signed.
jar cvf MyApp.jar Signme1.class Signme2.class

List all the classes that need to be signed in the previous command. Once the JAR containing
classes that need to be signed is created, sign the JAR with jarsigner.
jarsigner MyApp.jar mykey

Now, add the remainder of the classes in the application to MyApp.jar. The Java 2 version of jar
added the v flag, which allows JAR files to be updated with new files.
 jar uvf MyApp.jar Other1.class Others.class

List the remaining classes in the application in this step. If parts of the application are already in a
JAR or ZIP file, they will need to be unarchived before being JARed into the new partially signed
JAR file. To verify that all went correctly, use jarsigner to verify the contents.
jarsigner -verify -verbose MyApp.jar

Only the classes that were added before jarsigner was invoked the first time to create the signature
will be marked as signed. All the other classes will be listed, but no certificate or signature will be
associated with their listing. If jarsigner fails to verify the entire JAR, or classes that are supposed
to be signed appear not to be, use the jar command to list the contents of the JAR.
jar tvf MyApp.jar

The first entry in the JAR must be META-INF/MANIFEST.MF. If the manifest file is missing or
not in the first position in the file, the JAR will not verify properly. Following the MANIFEST.MF
file should be a .SF and .DSA (or .RSA) file. If either of those files is missing, then the signature is
missing from the JAR. Remove the JAR file and start over. If the commands listed earlier still
move the META-INF/MANIFEST.MF file out of the first position in the file, it may not be
possible to create a JAR containing signed and unsigned code. (The JAR command with JDK
1.2beta4 did not move the META-INF/MANIFEST.MF file around in the JARs we created.)

CHAPTER SECTION:7

Section 7 -- Differences between JDK 1.1 Code

Signing and Java 2 Code Signing
There are a number of major differences between Sun's approach to code signing in JDK 1.1 and
Java 2:

1. JDK 1.1 trusts code completely or does not trust it at all; Java 2 allows policy to define what
code can and cannot do. This reflects the change from black-and-white trust to shades-of-
gray.
2. JDK 1.1 has one tool, javakey, for all code-signing related functions; Java 2 has keytool for
certificate management and jarsigner for signing and verifying JARs.
3. JDK 1.1 does not support certificates from Certificate Authorities; Java 2 does allow
Certificate Authorities to sign generated certificates, however it is unclear if any CAs
currently offer this service.
 CHAPTER SECTION:8

Section 8 -- In Conclusion
Both Netscape and Microsoft have provided browser-specific methods for leaving their sandboxes.
Both rely on external Certificate Authorities to manage identities, but the same certificate used for
Netscape cannot be used for Microsoft. Netscape requires applets to use special classes to take
advantage of code signing. Microsoft also provides a vendor-specific API for certain capabilities.
Both take a similar approach when it comes to prompting the browser's user when certain applets
attempt to leave the sandbox.

Sun has moved from a black-and-white security policy that allowed trusted code to do anything it
wants to a shades-of-gray security policy by which only certain code from certain people can do
certain things, depending upon configuration. However, in Java 2, unsigned code can be granted
free reign of the system as well if the policy is configured as such. Having unsigned code play
outside the sandbox is something that none of the other schemes allow.

Each of the four Java code-signing techniques discussed in this tutorial vary in their complexity
level, have their own special tools for signing and key management, have different levels of support
from VM to VM, and take different approaches to the user's interface to security controls.
Considering that Java is meant to be a portable, mobile code system, the large number of
compatibility issues surrounding code signing is worrisome. Developers want their applets to do
more than the original JDK 1.0.2 sandbox model allowed, but with each vendor providing different
ways for code to leave the sandbox, the goal of "sign once, leave the sandbox anywhere" seems
highly unlikely.
 References
Abadi, M., Burrows, M., Lampson, B., and Plotkin, G. (1993) A calculus for access control in
distributed systems. ACM Transactions on Programming Languages and Systems, 15(4):706-734,
September 1993.

Anderson, R. and Kuhn, M. (1996) Tamper resistance-a cautionary note. In The Second USENIX
Workshop on Electronic Commerce Proceedings, pages 1-11. Also available on the Web
at http://www.cl.cam.ac.uk/users/cm213/Publications/tamper.html.

Badger, L. and Kohli, M. (1995) Java: Holds great potential-but also security concerns. Data
Security Letter, 3:12-15. The Data Security Letter (DSL) is published by Trusted Information
Systems (TIS).

Boneh, D., DeMillo, A., and Lipton, R. (1997) On the Importance of checking cryptographic
protocols for faults. In W. Funny (ed) Advances in Cryptology-Eurocrypt'97, Volume 1233
of Lecture Notes in Computer Science, pages 37-51, Springer-Verlag. Also available on the Web
athttp://theory.stanford.edu/~dabo/papers/faults.ps.gz.

CERT (1996a) CA-96.05: Java applet security manager. See

URL http://www.cert.org/advisories/index.html.

CERT (1996b) CA-96.07: Java Security bytecode verifier. See

URL http://www.cert.org/advisories/index.html.

Daconta, M. (1996) Java for C++ Programmers. John Wiley & Sons, New York.

Dean, D., Felten, E., and Wallach D. (1996) Java Security: From Hotjava to Netscape and beyond.
In Proceedings of the 1996 IEEE Symposium on Security and Privacy, Oakland, CA.

Dean, D. (1998) Formal Aspects of Mobile Code Security. Ph.D. dissertation, Department of
Computer Science, Princeton University.

Drossopoulou, S. and Eisenbach, S. (1998) Towards an Operations Semantics and Proof of Type
Soundness for Java. A technical paper to be included in an as yet unnamed book. Available on the
Web on-line at http://outoften.doc.ic.ac.uk/projects/slurp/papers.html.

Erdos, M., Hartman, B., and Mueller, M. (1996) Security Reference Model fo the Java Developer's
Kit 1.0.2. Available from Sun Microsystems and also as a Web document on-line
at http://www.javasoft.com/security/SRM.html.

Fellisen, M. and Friedman, D. (1998) A Little Java, A Few Patterns. MIT Press, Cambridge, MA.

Felten, E., Balfanz, D., Dean, D., and Wallach, D. (1997) Web Spoofing: An Internet con game.
In Proceedings of the 20th National Information Systems Security Conference, Baltimore, MD. An
early version appeared as technical report 540-96 (revised), Department of Computer Science,
Princeton University.

Flanagan, D. (1997) Java in a Nutshell, second edition. O'Reilly & Associates, Sebastopol, CA.

Flanagan, D. (1997) Java Examples in a Nutshell. O'Reilly & Associates, Sebastopol, CA.

Friedman, D., Wand, M., and Haynes, C. (1992) Essentials of Programming Languages. MIT
Press/McGraw-Hill, Cambridge, MA.

Garfinkel, S. And Spafford, G. (1996) Practical Unix & Internet Security, second edition. O'Reilly
& Associates, Sebastopol, CA.

Ghosh, A. (1998) E-Commerce Security: Weak Links, Best Defenses. John Wiley & Sons, New
York.

Gong, L., Mueller, M., Prafullchandra, H., and Schemers, R. (1997) Going Beyond the Sandbox:
An overview of the new security architecture in the Java Development Kit 1.2. In Proceedings of
the USENIX Symposium on Internet Technologies and Systems. Monterey, CA.

Gong, L. and Schemers, R. (1998) Implementing Protection Domains in the Java Development Kit
1.2. In Proceedings of the Internet Society Symposium on Network and Distributed System Security,
San Diego, CA.

Hastings, R. and Joyce, B. (1992) Purify: Fast detection of memory leaks and access errors.
In Proceedings of the Winter USENIX Conference, ACM Press.

Horstmann, C. and Cornell, G. (1997) Core Java Volume I--Fundamentals. SunSoft Press,
Mountain View, CA.

Hughes, L.J. (1995) Actually Useful Internet Security Techniques. New Riders, Indianapolis.

Hughes, M., Shoffner, M. and Winslow, M. (1997) Java Network Programming. Manning.

ISO7816 (1987) International Standards Organization, International Standard ISO 7816-1 through
7816-6 "Identification cards-Integrated circuit(s) cards with contacts". Available through ISO, New
York.

LaDue, M. (1996) Java Security: Whose business is it? Published by Online Business Consultants
and available as a Web document on-line athttp://www.rstcorp.com/hostile-
applets/OBCArticle/Article.html.

Lewis, T. (1996) What's wrong with Java? IEEE Software, 29(6):8. Lewis's letter to the editor was
in response to Java criticism originally printed by him in The NC phenomena: Scenes from your
living room, IEEE Software, 29(6):8-10.

Lewis, T. (1998) Java Holy War '98. IEEE Computer, 31(3):126-128.

Macgregor, R., Durbin, D., Owlett, J. and Yeomans, A. (1998) Java Network Security. Prentice
Hall, Saddle River, NJ.

Martin, D., Rajagopalan, S, and Rubin, A. (1997) Blocking Java Applets at the
Firewall. Proceedings of the 1997 Network and Distributed System Security Symposium. San
Diego, March 1997. Also available on the Web at http://www.cs.bu.edu/techreports/96-026-java-
firewalls.ps.Z.

McGraw, G. and Felten, E. (1996) Java Security: Hostile Applets, Holes, and Antidotes. John
Wiley & Sons, New York. (The first edition of this book.)

McGraw, G. (1998) Testing for security during development: why we should scrap penetrate and
patch. IEEE Aerospace and Electronic Systems, 13(4):13-15, April 1998.

Neumann, P. (1995) Computer Related Risks. Addison-Wesley, Reading, MA.

Oaks, S. (1998) Java Security. O'Reilly & Associates, Sebastopol, CA.

Rubin, A, Geer, D. and Ranum, M. (1997) The Web Security Sourcebook. John Wiley & Sons, New
York

Schneier, B. (1995) Applied Cryptography: Protocols, Alogorithms, and Source Code in C. John
Wiley & Sons, New York. Second edition.

Shimomura, T. and Markoff, J. (1996) Takedown: The Pursuit and Capture of Kevin Mitnick,
America's Most Wanted Computer Outlaw-By the Man Who Did It. Hyperion, New York.

Spafford, E. (1989) The Internet worm program: An analysis. Computer Communications Review,
19(1):17-57.

Stata, R. and Abadi, M. (1998) A type system for Java bytecode subroutines. In Proceedings of the
25th ACM Symposium on Principles of Programming Languages, pages 149-160, January 1998.

Sun Microsystems (1995) The Java language: An Overview. Available from Sun and also as a Web
document on-line athttp://java.sun.com/docs/overviews/java/java-overview-1.html.

Sun Microsystems (1996b) The Java Virtual Machine specification. Web document at
URLhttp://www.javasoft.com/docs/books/vmspec/html/VMSpecTOC.doc.html. Available as a
book by Lindholm and Yellin from Adison-Wesley.

Sun Microsystems (1996c) Low-level security in Java. Web document at

URL http://www.javasoft.com/sfaq/verifier.html/ by Frank Yellin.

Sun Microsystems (1997) Java card 2.0 programming concepts revision 1.0 final. Web document at
URLhttp://www.javasoft.com/products/javacard/index.html.

Venners, B. (1998) Inside the Java Virtual Machine. McGraw-Hill. New York.
Voas, J. and McGraw, G. (1998) Software Fault Injection: Inoculating Programs Against Errors.
John Wiley and Sons. New York. See the Web site at http://www.rstcorp.com/books/sfi/.

Wallach, D., Balfanz, D., Dean, D. and Felten, E. (1997) Extensible Security Architectures for
Java. In Proceedings of the 16th Symposium on Operating Systems Principles (Saint-Malo, France),
October, 1997.

Wallach, D. and Felten, E. (1998) Understanding Java Stack Inspection. In Proceedings of the 1998
IEEE Symposium on Security and Privacy, Oakland, CA.

Wallach, D. (1998) A New Approach to Mobile Code Security. Ph.D. dissertation, Department of
Computer Science, Princeton University.

Young, Boebert, and Kain (1985) Article in an IEEE Tutorial on Computer Network Security.
IEEE Press.

Web sites Referenced in the Text

All of the following links can be found on a page of the companion Web site for this book
at www.securingjava.com.

Chapter 1
Don't Push Me: The Security Implications of Push. developer.com TechFocus article by Gary
McGraw.

Java Developer's Kit (JDK) available free from Javasoft. Also other official Java information.

Javasoft's Frequently Asked Questions: Applet Security

Security Tradeoffs: Java versus ActiveX. Princeton Safe Internet Programming FAQ. Also
see Appendix A.

JavaScript Problems I've Discovered. John LoVerso's JavaScript Security site.

developer.com, an on-line publication for Java developers.

JavaWorld, an on-line publication for Java enthusiasts and developers.

MindQ, an on-line training company specializing in Java.

Yahoo! An excellent starting point for Web surfing. A large Web index.

AltaVista. One of the top search engines on the Web.

Java Security Hotlist. Also see Appendix B.

Princeton's Secure Internet Programming Team. Includes the Java Security FAQ.

The Java Books list. An extensive list of all books published about Java (way too many).

The Java Security Web Site. This book's companion Web site. Includes the Java Security Hotlist.

Chapter 2
The Hostile Applets Home Page, a collection of hostile applets written by Mark LaDue.

Chapter 3
Understanding Java Stack Inspection by Wallach and Felten.

Sun's document explaining the security API change.

Chapter 4
The Hostile Applets Home Page

DigiCrime (disable Java and JavaScript before you surf this site)

The Java Security Hotlist: Hostile Applets and Other Toys

Digicrime's Blue Screen of Death page.

The actual byte code of the bluescreen applet.

Ahpah Software makes the SourceAgain decompiler.

Earthweb's Java applet database. Sun Microsystem's Frequently Asked Questions - Java Security

Princeton's Java Security: Frequently Asked Questions (included as Appendix A)

Princeton's Security Tradeoffs: Java vs. ActiveX (included as Appendix A)

The Java Security Web Site, companion Web site for this book

Chapter 5
An archive of the security-related bugtraq archive

Javasoft's Frequently Asked Questions: Java Security

Princeton Secure Internet Programming Team's Java Security FAQ. Also see Appendix A.
Major Malfunction and Ben Laurie explain the security holes they discovered

Princeton's Secure Internet Programming Team

University of Washington's Kimera Project

Type safety problems discovered in Sun's Verifier by the Kimera Project

Ben Mesander's applet WhereDoYouWantToGoToday

Chapter 6
Princeton's seminal paper, Java Security: From HotJava to Netscape and Beyond

Formalizing the JVM at Computational Logic, Inc.

Javasoft's Security Reference Model for JDK 1.0.2

The Jasmin byte code assembler

Ahpah Software sells the SourceAgain Java Decompiler

Finjan Software, Ltd.

Mark LaDue takes on Finjan

Mark LaDue takes on Finjan again

Digitivity

Security7

WithinReach

Cult of the Dead Cow produces the Back Orifice exploit

esafe

Princeton Secure Internet Programming Team's Java Filter Class Loader

International Computer Security Association

Marcus Ranum discusses firewall certification

Mark LaDue's Hostile Applet Mutation Generator

Chapter 7
The Java Security Web Site, companion site for this book

The Java Security Hotlist

Sun's Java Security FAQ

Martin et al.'s paper Blocking Java Applets at the Firewall

Chapter 8
Gemplus: JavaCard and GemXpresso

Schlumberger: Cyberflex

Javasoft: Java Card Technology, specifications for Card Java can be found here

Boneh, DeMillo, and Lipton's On the Importance of Checking Cryptographic Protocols for Faults

Anderson and Kuhn's Tamper Resistance-A Cautionary Note

Crptography Research, Inc. information on Differential Power Analysis