Security Hole in Java by Jim Buzbee

New (Old) Security Hole in Java


This was first reported in 1998. The hole may not still be present in most browsers


This is to announce the discovery of a security hole in the current implementation of Java. I do not believe that this attack has been reported previously.

In most Java implementations, security policy forbids applets from reading the local directory structure. I have discovered that it is possible for an applet, using only Java, to determine if specified files exist on the file system of the client machine. The applet I have prototyped cannot read or write to the file, but it can detect its presence. My applet is then free to surreptitiously Email the result of the file search to any machine on the Internet, for example MarketResearch@microsoft.com.

Ramifications of the attack

Potential uses of this type of applet include market research for determining which products are installed on a system ( e.g. d:/Excel ), hackers probing for specific versions of programs or libraries ( e.g. /lib/libc.so.4.7.2 ) or just generally hostile applets that choose to invade the privacy of the user on the client machine. Due to the device naming scheme that Microsoft Windows uses, it is also possible to search for devices such as c:, d:, or a CDROM drive normally located at e:. Any software product or device that has a "signature" file can be detected.

Description of the attack

My applet is not complicated, just observant. It sits back and watches the state of the virtual machine as attempts are made to access files. There is a difference in behavior when the file exists, vs. when the file does not exist. If you consider the "sand box" paradigm of Java security, it's a bit like poking around out of the sand box in the dark and watching the reaction of the playground monitor.

As in previous security holes, the flaw is in the Java implementation, not the Java model. I believe correcting this bug will be easy for the various vendors. They must make the behavior of the virtual machine the same when the file exists, vs. when the file does not exist.

For the time being, I will not release a more detailed description of the attack or the code in source or object form until I have given Microsoft, Sun, Netscape and all other vendors a chance to respond.

[ New ] I've now got an example applet on-line. If you don't want my applet to poke around for a few files on your system, turn Java off before viewing it. I didn't integrate the applet with my Hostile email applet ( yet ), let's just see how it goes as a stand-alone hostile applet. I also haven't made the applet smart enough to only look for Unix-type files on Unix systems, Windows type files on a windows system etc. It would be easy to do, but who has the time ? The applet will not always be sucessful as it uses a bit of a "fuzzy" search techinque. It will not always work well on re-load either. It's just a proof of concept.

I have tested my applet under various versions of Netscape on Solaris, Linux, Windows 95, and Windows NT. Tests on the current version of Internet Explorer are inconclusive. Either bugs in Internet Explorer prevent the attack from working, or Internet Explorer is not susceptible.


Czech Translation by Andrey Fomin



This page is created, copyrighted and maintained by Jim Buzbee .


I have some other Java pages :