COMMAND
Java / Netscape / MSIE Cache Exploit
SYSTEMS AFFECTED
Systems using those programs
PROBLEM
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.
The following people have contributed directly or indirectly to
this exploit:
Scott Clark - The programmer who wrote the 'welcome' applet
User.class. This guy's applet inspired this work,
Digartz who host Scott's applet,
Paul Dawson of A.L. Digital Ltd., who spotted the applet,
and, more importantly, realised it's potential...
A.L. Digital 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.
More information can be obtained if you browse at:
http://www.alcrypto.co.uk/java/
This text is part of text from address above. Browse and try
exploit on your own skin. And now, some more details.
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...
Let's see how MSIE stands. 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...
SOLUTION
So far, Netscape have not made an official response, and appear
not to consider this problem to actually be a problem
(27.01.1997).
Microsoft said: "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."
The following updated class files provide a complete fix for this
problem. Users who run network facilities on a client machine and
who are concerned about this issue should download either
classr.exe or classd.exe, and chose 'Save As', rather than Open.
Classr.exe is a smaller download (1.17MB) for runtime use only.
Classd.exe is a larger download (2.98MB) which includes debug
information and certain sources useful to developers.
Once the files are downloaded and saved to the local disk, close
down the Internet Explorer and run the downloaded files to
install the new classes.