Is your browser a blabbermouth? Are your ports being scanned?

In a world where security matters more than anything, the unsuspecting always are the last to know that they aren't as safe as they thought.

In a February 25 post to comp.lang.java.security and BUGTRAQ, Major Malfunction and Ben Laurie followed through with their decision to inform the unsuspecting of a couple of new Java-based attacks that crack a "secure" client machine wide open. Although the pair (and assorted friends) hacked their way through firewalls back in January to prove that things aren't always as secure as they seem, they thought it only fair to provide Netscape and Microsoft with ample time to address the problem before they went public.

The first hole, accessible via Netscape's browser (both Navigator 3 and Communicator 4), allows a miscreant "to gain access to information from the client machine which would normally be considered secure." The attack works as advertised on the Java/MSIE/Netscape Cache Exploit page (see the Resources section of this article), 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), 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 second type of attack, which works with Microsoft's Internet Explorer browser, is much more disturbing. Major Malfunction and Ben Laurie claim "this loophole allows an attacker to connect to any TCP/IP port on the client's machine." That's a bit of an overstatement, but interesting information about listening ports can be gathered (for possible later use), which may leave a firewalled host more susceptible to standard TCP/IP-based attacks. And that's bad news.

The Java Security Manager usually disallows port-scanning behavior, but the crackers use the well-known trick of sticking some Java code (in this case, a port scanner) in the browser's cache and later executing it through a file: URL (using frames in the usual way). This attack works because Microsoft's cache layout is transparent.

Note: This is an interesting variation on the Hopwood slash-and-burn attack that Ed Felten and I describe on page 69 of Java Security: Hostile Applets, Holes, and Antidotes. The attackers cheat a bit for demonstration purposes by having the patsy clear their cache, but even without this exercise, guessing the cache location (one of four possibilities) would not be all that much of a challenge.

Contrary to their claim, however, Java security rules are no longer relaxed for code loaded out of the cache (unless the cache happens to be in the CLASSPATH, which is not recommended). That problem has been fixed.

In any case, Microsoft apparently places HTML and class files in the same directory stored with their original names (remember, a Java class will only run if it is correctly named). Although MSIE can't browse cache files directly, HTML pages can reference cache files by explicit name. Thus, the file: URL, if properly constructed, can invoke the Java class. The applet stuffed in your cache is a port scanner. The port scanning attack works because an applet is allowed to open a socket connection back to where it came from. And guess where it came from: Yep, the client machine. So a port scan is carried out by their cache-bomb applet. Unlike the first attack I discussed, port scanning is very serious. Using this attack a cracker might be able to discover things like weak sendmails listening on port 25, leaving only the problem of getting the port-scan information back to the cracker site. Accomplished crackers can simply use the URL-lookup covert channel to do this. (The Princeton team has explained this in a paper.) Unfortunately, this approach is only one of many ways of sending interesting tidbits out from an applet.

The information released last week by Major Malfunction and Ben Laurie has prompted Microsoft to release a patch to solve this problem, which you can find in the RESOURCES section of this article.

We are in the age of information. That's a good thing. But the path is still being forged. And that means you need to keep your eyes open to the hazards that are still unknown (or only partially known). My goal in this article is to help educate you and other Web users about the risks of executable content, not to stir up unnecessary panic.

This story, "Is your browser a blabbermouth? Are your ports being scanned?" was originally published by JavaWorld.