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