Dr. Gary McGraw is a well-known expert in Java Security. He is one of the authors of a new book dedicated to this important field. At the beginning of this year, I happened across the advance notice for the book. Part of the notice was an invitation to be on Gary's mailing list for notification when the book was released. It was during this coorespondence that I learned that he had lived in Italy for a year! and still speaks Italian quite well. Later after the book was released, I asked if he would like to appear in our famous web-zine MokaByte. To my delight he said yes so we decided to do this e-interview. In addition to this, you will find my review of his book at the link at the top of this page (there is another link at the bottom). I asked Gary some questions about security, Java, and his interests and beliefs about it. This was our conversation:

GEM: Actually both things happened around the same time. Believe it or not, my background is in Cognitive Science and AI. I have a dual PhD from Indiana University in cognitive science and computer science. Anyway, I have been a Web user Webmaster since 1993. My first Web surfing was done in Italy at the Istituto per la Ricerca Scientifica e Technologica (in Trento). I was there with my advisor Doug Hofstadter.

When I first heard about Java (in the Fall of 1995), I was just starting my job as a Research Scientist at Reliable Software Technologies. One of my first projects at RST was to work on a computer security contract that we have with DARPA (the research arm of the US Defense Department). So I was deeply steeped in computer security in late 1995.

Around the same time, Java came out in its alpha version. It sounded so cool that I just had to start playing with it. Based on some of our research, we wrote a paper about software engineering tools and Java, and went to New York to talk about it. In New York I heard a talk on Java Security and began thinking about the security model in earnest. Then I met Ed Felten (leader of the Princeton team) at the 1996 IEEE Security and Privacy conference where the Princeton team published their now famous paper on Java security. Ed and I started talking about a book then.

The cool thing about the Web is that it allows people with every different kind of computer to communicate. Enter Java. Java is a full-fledged programming language as powerful as C and C++, but because it is truly cross-platform it is perfect for ``executable content.'' But here's the rub (and why we wrote the book). When you run a Java applet off the Web, you are actually running somebody else's untrusted code *on your machine*. That's dangerous. What if the applet tried to erase your hardisk or install a backdoor onto your system?

Java's designers were well aware of the dangers of executable content, and they developed a security model to make running untrusted code possible. The model is basically well-designed, but it isn't perfect. Security researchers, most notably Princeton's Safe Internet Programming team, have been involved in both educating people about the risks, and trying to help improve the security model.

I should mention, just briefly that there are other forms of executable content. The best hyped of these is ActiveX. But Microsoft didn't address the problem of running untrusted code. As a result, ActiveX is exceptionally dangerous kind of executable content. If you decide to run an ActiveX control, you are placing your entire machine (and all the data on it) in the hands of somebody else. You must trust them completely not to do something bad to you.

MB: How long have you been involved with computer security? How did you become interested in it?

GEM: I have only been working in security for a couple of years now. But it is amazing how much work there is to be done in the field! The real problem in computer security is that the ``penetrate and patch'' mentality once again prevails. The same old bugs keep showing up over and over. Software gets released on a ridiculously short production schedule, gets installed out in the world, and then ends up being debugged by users. Users and hackers find holes, vendors patch holes, sometimes users install patches. If we really want to solve many of today's most prevalent security problems on the Net and Web, we need to focus on stomping out these bugs during development. One of RST's DARPA-sponsored research projects is looking into this problem.

"Featurism" (adding more bells and whistles to programs like Web servers) and the "Internet year" (in which three months equals an old developing year) have made the security problem that much harder to deal with. The good thing about the Web is that it has made the Internet accessible to millions. The bad thing is that many of these millions are completely in the dark when it comes to security. Don't make the mistake of thinking the Web is completely safe (it isn't). Learn as much as you can about security, especially if you have something to lose.

MB: How did the RST security research group get started? Can you give a little history and credentials about that?

GEM: RST specializes in software assurance. We're especially concerned with dependability and reliability, and much of our work in the past has been inventing ways to analyze software's safety. It is critical that code controlling a nuclear power plant or an airplane behave properly. Otherwise people could die.

One of our favorite analysis techniques involves injecting faults into software to perform dynamic analysis. (In fact we sell a commercial safety analysis tool to do this automatically.) We thought extending this methodology to security analysis was a natural way to go. DARPA agreed, and we started doing security research for them. Since then, we've become very heavily involved in security research at RST.

In addition, RST has been involved in software assurance of Internet and Web based systems for several years. When Java first came out in alpha, we prototyped a code coverage tool that helps in testing your software. Since that time, we have developed a mature commercial code coverage tool for Java that is being used by many major Java development organizations. If you're using Java to develop serious code (moving beyond dancing pigs), you may find out tool useful.

MB: Do you focus on applets or do you give applications equal time? I know that applications don't "run in a browser" but they still could present problems related to security and the web, couldn't they?

GEM: Most attention has been paid to analyzing the security model that stops applets from misbehaving. That's because in this case security is essential. There is a strict and important difference between two types of Java programs --- applets and applications. Java applets are Java programs, usually small, that are meant to be run in the context of a Web browser. Applets are usually written by one person and run on another person's machine --- they are ``executable content''. Java's security policies exist in order to make applets feasible. Java runtime enforces severe limitations on the sorts of things that applet-related classes (obtained through the network) may do. Applets, for example, are not allowed to read and write files on the local disk.

On the other side of the fence, Java applications do not have any such restrictions imposed on them. Applications are full-fledged programs that unleash the complete power of Java without any security restrictions. Thus, just as C programs can read and write files and manipulate memory, so too can Java applications. Java is a powerful language. Clearly, applet access to the more powerful features of Java must be properly restricted.

Java applets are executed by Web browsers with embedded Java virtual machines (VMs) and run-time 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 all of these parts of the model: the Java language itself, the run-time class libraries, and the security manager of the browser.

Though applets are not supposed to do many things in the interest of security, it turns out they can do more than they should. Applets that don't play by the rules are called *hostile applets*. The most serious kind of hostile applet is an attack applet. By ``serious'' I mean that attacks based on some of the flaws that have been discovered could go beyond annoyance: they could corrupt data on your hard disk, reveal private data on your hard disk to third parties, infect your machine with a virus, or install a trapdoor on your machine. By exploiting some of the vulnerabilities that we discuss in our book, a cracker could attain the ultimate cracker goal --- complete control of your machine.

Security is important for applications too. But securing an application is much more of a problem for the programmer. Mark LaDue (who brings you the Hostile Applets Home Page) has recently turned his attention to creating viruses and other such things as Java applications, but not much other work has been done in that direction. In the case of a hostile applet, Web users are counting on the Java security model to protect them. It's a pretty good system, but it is by no means perfect.

MB: Are you saying that it is possible to circumvent the built-in security features of applets - say, for example, in JDK 1.0.2? If so, how?

GEM: Unfortunately yes. When you read of security flaws in the Press, this is what they're talking about.

To date, nine serious security problems have been discovered in implementations of Java. Flaws have been discovered in many parts of the Java security model and involve problems ranging from DNS name resolution to type confusion. You can read about eight of the security flaws in out book. Chapter three is called "Serious Holes in the Security Model". The latest serious flaw (number nine), discovered in April 1997, involved the newly-added code signing system in JDK 1.1.1.

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 recent hole was a fairly straightforward problem in the implementation Java's Class class as explained on both the Princeton site and JavaSoft's security site. The problem was that the method %Class.getsigners()% returns a mutable array of all signers known to the system. It is possible for an applet to mis-use this information (by cycling through the array). 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 JavaSoft statement about the bug claims, 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 is currently the only commercial product that supports JDK 1.1.1) loads an applet signed by Alice, that applet can still 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 use the %getsigners()% call 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, an 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 says the flaw will be fixed in the next release (1.1.2) of the JDK. A patch has been created and is on its way to the various Java licensees now. Since neither Netscape nor Microsoft support JDK 1.1 code signing, they are not vulnerable. Interestingly, Netscape Communicator will have a completely different model of code signing. See the Princeton technical report ``Extensible Security Architectures for Java'' (available on their Website) for details.

MB: How do you find these problems with Java security? Do you have an idea of what you are looking for then try to make it happen or do you randomly try things or something else?

GEM: First a caveat. Though I often collaborate with the guys at Princeton, I have not been directly involved in the discovery of any new holes. But I do know how they go about it (and if I had more time, I would love to join them in their efforts!). The most usual scenario involves someone on the team coming up with an idea like, "I wonder how they implemented such-and-such? Think they did it right?"

Sometimes the implementation is correct, but often it isn't. So this is a pretty intuition-based effort. You think of what might be done incorrectly, then you look at the code and see what it does. The major constraint on this sort of effort is the time it takes to investigate things.

A different approach works just as well. A team of researchers at the University of Washington recently discovered a whole list of problems in the Java implementation. They found the problems using an automated testing methodology. Over 2.5 million automated tests were run against the Verifier. They found 26 problems, some of which were serious enough to warrant patching. Javasoft is sending a patch to Java licensees now. [See the report at JavaSoft's website.]

MB: Do you think Java will ever be unbreakable security-wise?

GEM: Probably not. It's not like Java has stopped changing! JDK 1.1 introduced new things like code signing. This opens up another can of worms wriggling with potential problems. (Witness the hole explained above.) Java is evolving very very quickly. Unless it stops, I find it unlikely that all the bugs will be discovered and removed.

This is not just a Java problem, this is a problem for almost all Web-based programs including browsers, plugins, and any sort of executable content.

MB: Is there something better than Java, in your opinion, that does substantially the same thing (progamming-for-the-internet) but has better security? Explain.

GEM: No. I think Java has the best model of any commercially-available system. In fact, by contrast, the ActiveX approach is *far inferior*. ActiveX has no security model. ActiveX is useful only for running completely trusted code. What ActiveX does provide is a digital-signature--based authentication system that allows users to know who vouches for a piece of code. That puts the power to control security policy directly in the hands of users. I'm not convinced that's a good idea.

For me, Java is clearly superior. I am interested in running code from all over the Web, not just code written by giant companies (who presume I trust them). I like the idea of running untrusted code safely. The problem is, it ain't easy.

The reason Internet and Web security is becoming a hot topic is because more people than ever before are using the Net and the Web. Even my 89 year old grandmother just got WebTV so she could be part of the McGraw family e-mail fest! Plus, business are falling all over themselves to get on the Net.

As businesses go on-line and Web commerce evolves, security will become even more critical than it is today. In the Information Age, Information is the currency. Unscrupulous people have always wanted to steal things. The new thing to steal is electronic blips.

The other thing about the Web is how rapidly it is changing. The Web only started in 1993! Here we are four years later with Java, ActiveX, Plugins, and now server-push executables. These systems are new, and still have some kinks to be worked out. Plus they all interact in often unpredictable ways. Some of us are working as hard as we can to assess these systems and inform people about their risks in an objective way. That's why Ed Felten and I wrote the Java security book, and that's why we like to do interviews like these.

MB: Why do you think it is wise to broadcast these security issues? Wouldn't it be better to quietly tell JavaSoft/Sun instead of telling all the "bad-guys" (that's the generic "guy") too?

GEM: Nope. Security by obscurity is a very bad idea. The way to get things fixed is to talk about them honestly and openly. JavaSoft has been especially good in their interactions with people who have found problems. They cooperate and try to be as honest as possible (with minimal, but noticeable PR spin). Plus there are many more Java vendors than just JavaSoft. Browser vendors, for example, implement two key parts of the Java security model themselves. And Netscape's implementation differs from Microsoft's.

A few months ago there was some hubub over Java security raised by a couple of English hackers. They annouced the discovery of two new holes. See: http://www.alcrypto.co.uk/java/, but note that some of us think their holes are good examples of known problems rather than completely new things.

One interesting thing about these two holes is that one of them (the least serious) worked only with Netscape Navigator's Java, and the other (a truly serious attack) worked only with Microsoft Internet Explorer's Java. There's an example of different security implementations of Java.

As far as the Netscape hole went, Sun fixed the exact problem that the hackers exploited some time ago in JDK 1.0.2. In Sun's java.net, an applet that calls getLocalHost() will *not* get the true hostname/address, but instead gets the loopback host ("localhost/127.0.0.1"). This is a generic handle from which it is impossible to infer any juicy private info (like a host's true IP). Microsoft also got this part right --- the same applet in IE does the right thing --- but Navigator does the wrong thing. For the more serious bug, Netscape does the right thing while Microsoft does the wrong thing. In any case, neither of the problems is Java-wide.

The second attack worked only against the Microsoft Internet Explorer. The hackers 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). This may leave a firewalled host more susceptible to standard TCP/IP based attacks. That's bad.

The Java Security Manager usually disallows port scanning behavior. But the crackers use the well-known trick of sticking some Java code in the browser's cache and later executing it through a file: URL (using frames). Since Microsoft's cache layout is transparent, this attack works. The attackers cheat a bit for demonstration purposes by having the patsy clear their cache to begin with, but even without this exercise, guessing the cache location (one of four possibilities) would not be all that much of a challenge.

The applet the crackers stuff in your cache is a port scanner. In this case, the port scanning attack works because an applet is allowed to open a socket connection back to where it came from. Guess where it came from? The client machine. So a port scan is carried out by their cache-bomb applet. Port scanning is *very bad* since a cracker might be able to discover things like weak sendmails listening on port 25.

MB: Do you have a "dream system" for ultra-security on the web? Explain.

GEM: If I did, I would keep it to myself and become a gazillionaire. Alas, I do not. I think we need some major infrastructure changes before we'll get high-security systems. Packet authentication and encryption, for example, would be very useful. IPv6 and smart cards will probably play an important role in improving Internet security.

MB: Do you generally "like Java"?

GEM: I like Java, but Java is risky. My main goal in life is *not* to make people stop using Java and other kinds of executable content. That would be futile (like trying to stop a tidalwave with your hand). But I do want people to become aware of the risks and think about them.

Learn as much as you can about the Java security model. Know that when you use Java on the Web, you are putting faith in the Java security model to protect you from possibly hostile attack. Learn more about the Byte Code Verifier, the Applet Class Loader, and the Security Manager and how they interact. Pick up a copy of our book, and check out the Java Security Web site http://www.rstcorp.com/java-security.html which includes an annotated hotlist to every major Java security site on the Web.

Because everyone's situation is unique, there is no one answer to the question "Should I avoid using Java because of the possible risks that applets may pose?". A business on the Net needs to think about exposing their information to robbery or corruption. A user at home with no critical data probably has no worries. That is, even if they get hacked it basically doesn't matter. If your information is valuable or if you are highly visible, you make a good target.

Here's a little poem that Peter Neumann wrote for us. I think it provides a great summary.

Java is hot. Java is cool. Its use is riddled with risks that fool. ``Java Security'' takes us all back to school.