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.
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... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
