What though the spicy breezes
Blow soft o'er Java's isle;
Though every prospect pleases,
And only man is vile:
In vain with lavish kindness
The gifts of God are strown;
The heathen in his blindness
Bows down to wood and stone.
Bishop Heber.
Background
It is possible to exploit weaknesses in Netscape Navigator 3, Netscape Communicator 4, and Microsoft Internet Explorer 3.0 & 3.01 Java implementations to gain access to information from the client machine which would normally be considered 'secure'. Specifically, in the case of Netscape products, it is possible to determine the IP address and local hostname even if the machine is behind a firewall. Because of a lazy implementation of the java.net class by Microsoft, this is not possible on MSIE, but they more than make up for this by allowing the exploit to go one stage further and enable a local scan of all ports on the client machine, as well as a direct connection between any port on the client machine and any other machine on the Internet, again, even if the client machine is 'safely' behind a firewall.
When we discovered these problems in Jan '97, we alerted Netscape and Microsoft, and allowed them time to work with us to resolve them before public announcement. The public announcement was made on the 25th of February '97.
Details
Netscape Navigator / Communicator - and remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Whoops!"
Netscape actually get off pretty lightly... 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(), shake vigourously, light the blue touch paper, stand well back and...
OK, OK, enough of the waffle... Let me see the colour of your money... Go ahead, show me how it's done!
What? Show you my IP address??? Right here, in front of everyone??? You must be crazy!!! I'm outta here, buster! I've got safer things to do...
Microsoft Internet Explorer - "Where do you want (your data) to go today?"
The object of the exercise here is to open a connection to a port on the local machine, and provide a two-way pipe back to a remote machine on the Internet. This is achieved by using the Java net.socket class to talk to the local machine, and the showDocument() thingy for the remote. This exploit relies on the fact that Java behaves differently when loaded across the 'net, to a load from local hard disk. When loaded across the 'net, the applet is not allowed to open a network socket to anything other than the server that delivered it in the first place (see http://www.javasoft.com/sfaq/#socket for details). This is enforced by the centralised security manager class. However, if the applet is loaded from local disk, this limitation is relaxed, allowing a socket to be opened on the browsing machine. Note that it would appear to be Microsoft's intention to treat locally loaded Java in the same way as 'net loaded Java (that is, both are 'untrusted'), although Sun treat them differently. However, Microsoft's manuals are far from clear on this point, and certainly, in practise, they are not the same.
So, in order to avoid the security manager, we must load the class file from hard disk. To do this, we must put the class file somewhere on the browser's local disk. Class files are only allowed to be loaded from certain places: the server that delivered the applet, the default library (can be more than one directory, as defined by the CLASSPATH environment variable), and, if the calling HTML is loaded from disk, the directory the HTML was loaded from. In the usual run of things, it would not be possible to put the class file in any of these places (bearing in mind that it must be on hard disk, not on the server) as applets (and web pages generally) are not allowed to write to local disk (http://www.javasoft.com/sfaq/#read).
Here, our heroes Microsoft step in... They have thoughtfully arranged for the class file and HTML to be conveniently stored for us in the same place: the cache. Unlike Netscape, they store these files with their original names (this is important, as a Java class will only run if it is correctly named). They have made some feeble attempts to hide the files from you, but if you squint a bit you can see them. By default, they are in 'C:\Windows\Temporary Internet Files\Cache1, 2, 3 & 4'. The four subdirectories, cache1-4, have been marked hidden with the standard file attributes facility, and MSIE has been crippled so you cannot browse them. Sadly (or happily, depending on your viewpoint), they have neglected to cripple references from within another HTML document. It is therefore very easy to construct a URL that loads files directly from the local hard disk cache (this is nothing new... cache browsing utilities have been around for ages). Having done so, the applet will load in 'semi-trusted' mode, and your computer is my oyster...
Yeah, right. So I'm your oyster... Make yourself at home - eat me!
You must be out of your tiny, degenerate, evil, twisted, hacker mindset! I wouldn't let you scan my PC if you were Dr. Beverly Crusher... I'm off to have some real fun...
"This problem only affects users who use the same machine to run network services, such as a mail server, and execute applets from unknown sources on the Internet. This will not affect users who run mail clients or network client applications only. Microsoft encourages users to be careful when accessing executable code of any form over the Internet, and advises caution when running network services on a machine which is used to browse applets from untrusted sources. The fix for this problem is now available at http://www.microsoft.com/java/issue.htm."
Credit where credit's due...
The following people have contributed directly or indirectly to this exploit:
Paul Dawson of A.L. Digital Ltd., who spotted an applet, and, more importantly, realised it's potential and told us about it...
A.L. Digital themselves, for sponsoring this kind of work, lending technical resources, and liaising with software vendors.
Authors Major Malfunction, who spent many nights slaving over a hot cache, and Ben Laurie, who is the ultimate code warrior.
Stuntman Evel Knievel, who risked his life for the pretty picture at the top of this page...
BobbyRite (b) 1997, Major Malfunction & Ben Laurie, All Rites reserved, all Wrongs revenged.