Implementation Flaws: A Litany of Bugs

Most web browsers implement a security policy that is designed to protect the user from both malicious eavesdropping and hostile web pages. Unfortunately, bugs in the browser can effectively subvert such a policy, leaving the user open to those attacks.

Throughout 1995, Netscape's early browsers were subject to a high degree of scrutiny. Often, reports of these bugs appeared on the front pages of major daily newspapers, rather than the academic press. The public's confidence in Netscape Navigator's security was so shaken, in fact, that Netscape announced that it would pay users up to $1000 for each bug that was discovered. Netscape's theory was that the increased scrutiny that its product received as a result of the bounty program would make the product more secure. Netscape has also made its source code available on some occasions to academics involved in security-related research.

Here are some of the more important bugs that were discovered in Netscape Navigator:

•

In September 1995, Ian Goldberg and David Wagner, two graduate students at the University of California at Berkeley working with professor Eric Brewer, discovered a flaw in the way that the UNIX version of the Netscape Navigator generated random numbers. Instead of seeding the random number generator with a number that was unpredictable, such as the user's mouse motions, programmers at Netscape had decided to use the computer's time-of-day clock, the Navigator's process number, and other information that was trivial to determine. The students discovered that they could determine this information and predict the results of the random number generator. Some articles describing this attack can be found at http://www.cs.berkeley.edu/~iang/press/.

•

In October 1995, the same group of students discovered an even more impressive attack against Navigator: they could simply patch out the random number generator, so that it always used the same key.

•

During the first half of 1996, three researchers at Princeton University, Drew Dean, Ed Felten, and Dan Wallach, discovered a number of flaws in the Netscape Navigator 2.0 Java run-time

environment. One flaw allowed a malicious applet to open connections to any Internet host,

potentially allowing applets running behind firewalls to attack other computers behind a firewall. The Princeton team also discovered numerous flaws that allowed Java applets to execute arbitrary machine code. The Princeton group's findings are summarized at http://www.cs.princeton.edu/sip/.

•

Early versions of the JavaScript implementation in Netscape Navigator Version 2.0 allowed

information from the user's environment to be automatically filled into HTML forms and to then have those forms automatically posted or sent by email to other sites on the Internet. These bugs allowed the creation of web pages that caused the user to reveal his or her email address and browser "history" (the list of URLs previously visited by the browser).

•

Also under Netscape Navigator Version 2.0, a vandal could create a link on a WWW page that, when clicked, would cause the user to send email with contents and destination of the vandal's choice. This was frequently directed against high-profile targets, such as whitehouse.gov. Users were sending harassing or threatening email without even realizing it!

In response to these problems, the U.S. Government's Naval Research Lab, which sets the Navy's computer security policy, finally turned its thumbs down to Netscape Navigator in the fall of 1996. "The NRL Information Systems Security Office recommends that use of all Netscape products be disallowed on computers NRL- wide," wrote Rick Perry, NRL's IS Security Officer, in an internal memorandum. "It should also be noted that Netscape versions prior to Version 2.0 have reported security problems. Even though Netscape claimed to have fixed those earlier problems, the fact that new security vulnerabilities continue to be reported in subsequent releases leads us to conclude that all versions of Netscape are suspect from a security standpoint and should not be used on NRL computers."

On October 2, 1996, the U.S. Navy and Microsoft issued a joint press release saying that the Navy had chosen Microsoft's Internet Explorer as its official web browser.

As we mentioned in the Preface, on March 3, 1997, Paul Greene, a student at Worcester Polytechnic Institute in Massachusetts, discovered a security-relevant flaw in Microsoft's Internet Explorer Versions 3.0 and 3.0.1. The bug made it possible to create a web page that, when viewed by Internet Explorer, ran any program at all. Greene created a web page (http://www.cybersnot.com/ ) with links that, when clicked, would create directories, delete directories, and run other programs on the user's machine - all in violation of Internet Explorer's security model. Greene's bug had nothing to do with ActiveX or any other Microsoft proprietary technology. The bug was merely the result of an error in Internet Explorer's registry entries, which told Internet Explorer that it was "safe" to open files of type .URL and .LNK without first asking the user.

Microsoft's developers swung into action and had a fix for the bug on its web site within 48 hours. But within three days, a bug was found in Internet Explorer 3.0.1 that had the similar consequences. Another bug fix was quickly prepared and released.

Chapter 3. Java and JavaScript

Java and JavaScript are both languages for adding interactivity to web pages. Both languages can be run on either a web browser or a web server (or even stand-alone). Both languages have a syntax that resembles the C++ language.

Despite these apparent similarities, Java and JavaScript are actually two completely different languages with different semantics, different user communities, and different security implications. This chapter explores the security issues in each language.

3.1 Java

Although today Java is widely thought of as a language for writing programs that are downloaded over the Internet to web browsers, it wasn't designed for that purpose. Indeed, Java's security model was largely added as an afterthought. To understand the security issues with Java today, it's important to understand the history of the language.

Java's history started in 1991 when a group of engineers at Sun Microsystems were hard at work on a stealth project designed to catapult Sun into the world of consumer electronics. Sun envisioned a future in which toasters, remote control systems, stereos, and cable decoder boxes were all programmed using a common computer language with programs that could be easily downloaded over a network. The stealth project was designed to leverage Sun's experience with computer languages, system design, and silicon manufacturing to turn the company into a major supplier for this new world order.

The key to dominating this new world was a new computer language developed by James Gosling. Called Oak, the language was designed to produce programs that would be compact and highly reliable.

Compactness was necessary because Oak programs were going to be downloaded over networks whenever it was necessary to change them. And reliability was necessary too, because programs in this language had to be able to run for weeks or months at a time without outside intervention: you can't expect to dominate the market if you sometimes need to tell the average American that his toaster oven has to be rebooted to continue operation.

Instead of being compiled for a specific microprocessor, Oak was designed to be compiled into an interpreted bytecode that would run on a virtual machine. Simple economics drove the decision to use a virtual machine: a portable bytecode would allow a consumer electronics manufacturer to change its microprocessor without losing compatibility with existing programs. Unlike today's desktop computers, the microprocessor would truly become a commodity.

The first test for Oak was an interactive cable TV decoder box that Sun was designing for Time Warner. In April 1993, Time Warner assured Sun that it would be awarded the contract for the interactive cable TV trial because it had superior technology. But on June 14, 1993, Time Warner awarded the set-top box contract to Silicon Graphics, Inc. It was perhaps just as well: interactive cable TV was a failure.13

In the months that followed, the Oak team repositioned their language for the world of CD-ROMs and multimedia publishing. Oak was designed to create compelling, multiplatform programs. Why not have those programs run on traditional PCs, Macs, and UNIX workstations? Right around that time, another multiplatform phenomenon was sweeping the computer industry: the World Wide Web. That was great for the Oak team: they had a language that was designed to be small and portable. The team quickly realized they could use the Web to download programs to an end user's computer and have the programs run instantly on the user's desktop.

In July 1994, Patrick Naughton, a member of the team, wrote a "throwaway" web browser to demonstrate the idea. Within a month, the browser was rewritten from scratch in Oak, and a system for running downloaded applets was designed and implemented. Eight months later, Sun formally announced Java and its HotJava web browser at the 1995 SunWorld tradeshow. That same day, Netscape announced its intention to license

3.1.1 Java the Language

Java is a modern object-oriented language that has a syntax similar to C++, dynamic binding, garbage collection, and a simple inheritance model. Although Java was largely promoted as a language for the World Wide Web, Java is in fact a general-purpose computer language that can be used for writing anything from simple five-line toy programs to complicated applications.

What initially distinguished the typical Java implementation from other computer languages is the run-time environment. Instead of being compiled for a particular microprocessor, Java programs are compiled into a processor-independent byte-code . This bytecode is loaded into a computer's memory by the Java Class Loader . Finally, the bytecode is run on a Java virtual machine ( JVM).

The Java virtual machine can run Java programs directly on an operating system such as Windows or MacOS; alternatively, the JVM can be embedded inside a web browser, allowing programs to be executed as they are downloaded from the World Wide Web. The JVM can execute the Java bytecode directly using an interpreter. Alternatively, it can use a "just-in-time" compiler to convert the bytecode into the native machine code of the particular computer on which it is running. This whole Java cycle is depicted in Figure 3.1.

Java can also be compiled directly into machine code and run on a target system. Used this way, Java loses its run-time advantage of being able to run on any computer and any operating system that has a Java virtual machine, but it retains its advantage of generating code that has automatic memory management.

Figure 3.1. The Java cycle

http://java.sun.com/docs/white/langenv/

Sun's official "white paper" on the Java programming language and environment, written by James Gosling and Henry McGilton

http://www.sun.com/sunworldonline/swol-07-1995/swol-07-java.html SunWorld Online's history of Java

3.1.2 Java Safety

From the beginning, the Oak team wanted to create a language that would encourage programmers to write code that was inherently reliable. Starting with C++, Gosling and his team removed many of the features from C++ that are confusing or commonly misused. In this way, they sought to increase the safety of the language and the sanity of programs written with it.

The main way that Java achieves reliability is by providing automatic memory management. Specifically:

•

Instead of forcing the programmer to manually manage memory with malloc( ) and free( ), Java has a working garbage collection system. As a result, Java programmers don't need to worry about memory leaks, or about the possibility that they are using memory in one part of an application that is still in use by another.

•

Java has built-in bounds checking on all strings and arrays. This eliminates buffer overruns, which are another major source of C and C++ programming errors and security bugs.

•

The Java language doesn't have pointers. That's good, because many C/C++ programmers don't understand the difference between a pointer to an object and the object itself.14

•

Java only has single inheritance, making Java class hierarchies easier to understand. And since Java classes can implement multiple interfaces, the language supports many of the advantages of multiple-inheritance languages.

•

Java is strongly typed, so you don't have problems where one part of a program thinks that an object has one type, and another part of a program thinks that an object has another type.

•

Java has a sophisticated exception handling system.

All of these features combine to make Java a safe programming language: Java programs rarely misbehave wildly when given data that is slightly unexpected. (Instead, they simply generate an exception, which usually causes the program to terminate with a run-time error.) And because most security problems are the result of bugs and programming errors, it is thought that programs written in the Java language will be more secure than programs written in traditional languages such as C and C++.

3.1.3 Java Security

Java was not designed to be a secure programming language. Under Java's original vision, programs would only be downloaded by an equipment manufacturer or an approved content provider. Java was designed for a closed programmer community and for a somewhat constrained set of target environments.

When Java was repositioned for the Web, security immediately became a concern. By design, the World Wide Web allows any user to download any page from anyone on the Internet, whether it is from an approved content provider or not. If web users can download and run a program by simply clicking on a web page, then there needs to be some mechanism for protecting users from malicious and poorly constructed programs. 3.1.3.1 Safety is not security

Having a safe programming language protects users from many conventional security problems. That's because many security-related problems are actually the result of programming faults.15 _{Java eliminates}

many traditional sources of bugs, such as buffer overflows.

But a safe programming language alone cannot protect users from programs that are intentionally

malicious.16 _{To provide protection against these underlying attacks (and countless others), it's necessary to}

Java employs a variety of techniques to limit what a downloaded program can do. The main ones are the Java sandbox, the SecurityManager class, the Bytecode Verifier, and the Java Class Loader. These processes are illustrated in Figure 3.2 and described in the following sections.

Figure 3.2. The Java sandbox, SecurityManager class, Bytecode Verifier, and Class Loader

3.1.3.2 Sandbox

Java programs are prohibited from directly manipulating a computer's hardware or making direct calls to the computer's operating system. Instead, Java programs run on a virtual computer inside a restricted virtual space.

Sun termed this approach to security the Java "sandbox," likening the Java execution environment to a place where a child can build things and break things and generally not get hurt and not hurt the outside world. 3.1.3.3 SecurityManager class

If all Java programs were restricted so that they couldn't send information over the network, couldn't read or write from the user's hard disk, and couldn't manipulate the computer's input/output devices, they would probably be nearly secure: after all, there would be little damage that the programs could do.17 _{Of course,}

these limitations would also make Java a much less exciting programming environment: that's because there wouldn't be much of anything interesting that Java programs could do either.

Java uses a series of special classes that allow programs running inside the sandbox to communicate with the outside world. For example, the Java class FileOutputStream allows a Java program to open a file for writing to the user's hard disk.

The creators of Java believed that programs that are downloaded from an untrusted source, such as the Internet, should run with fewer privileges than programs that are run directly from the user's hard disk. They created a special class, called SecurityManager, which is designed to be called before any "dangerous" operation is executed. The SecurityManager class determines whether the operation should be allowed or not.18

17

_{However, the code could replicate itself and tie up processing resources, resulting in a denial of service.}

18

_{In Netscape Navigator, the java.lang.SecurityManager base class is subclassed by the netscape.lang.AppletSecurity class that implements}

In document Web Security & Commerce pdf (Page 42-47)