pseudo-flaw.net

PDP from GNUCITIZEN suggested that Java applets can be load from corrupted JAR files. I'm not sure what browser or JRE he was working with, but after following his documented steps I was ready to call shenanigans. Combining a JPEG and a JAR did result in a file that could be opened as an image as well as extracted as a PKZIP archive (this is a totally old-school, ghetto stego trick). On Mac OS X (with Firefox 2.0.0.9) the corrupted file wouldn't load as an applet. And on Linux, the 1.6u3 Sun JRE exhibited the same behavior. The applet would be downloaded but when processed it wouldn't load.

Finally, as a last resort, I tried using Windows and was able to get some success with Firefox and 1.6u3. The JRE would generally load the applet no matter what the garbage content was in front of it. I decided I had done something wrong in my Mac and Linux tests and went back to re-test.

After re-testing, Linux appears to be susceptible to this trick as well, but not as consistently. There is some strange cache behavior that appears to influence whether or not the file is recognized as an applet. I'm thinking that if a user visits the file before it has been corrupted, it won't be recognized as an applet later.

I've come to the conclusion that Mac OS X isn't affected by this issue. Apple provides its own Java Environment and there must be some difference that is preventing this trick from working.

Online demonstration coming soon.

In early October, Sun updated the Java Runtime Environment (JRE) to close some of the gaping holes in the handling of network connections: Security Vulnerabilities in Java Runtime Environment May Allow Network Access Restrictions to be Circumvented. As a result, the ever popular DNS rebinding and document.domain bypass vectors were effectively shut down. The JRE now attempts to validate that the network address and hostnames are linked when establishing socket connections (see the end of my Attacking the Tor Control Port with Java for more discussion and a network trace).

Of course, it is possible that these changes have not been effective. There may yet be some means of bypassing the restrictions either through DNS rebinding or the document.domain exception. The comments in the code seem to indicate the solution is not fully baked.

From InetAddress.java:

     //XXX: if it looks a spoof just return the address?
     if (!ok) {
	

From SocketPermission.java:

     // XXX: if all else fails, compare hostnames?
     // Do we really want this?
	

One of the other points of attack in DNS rebinding exploits are proxy servers. The latest JRE (6u3) seems to take a different code path when a proxy has been explicitly configured through the network settings:

Arbitrary socket connections are still not permitted, but connections made through the URLConnection class are allowed. The setRequestProperty can be used to set HTTP header values, but depending on the proxy that you are going through these may be adjusted. Remember, the proxy is the one making the request.

I've only tested using the document.domain exception bypass and LiveConnect, but I would assume that something similar can be performed using a DNS rebinding approach and applets. Also, I haven't fully investigated the impact of the "Bypass proxy server for local addresses" option.

I've put up an online demonstration. You'll need Firefox, a 1.6 JRE, and a proxy server with a locally configured web server. The demo attempts to connect to the local web server by requesting the root document through the proxy.

The site has been completely switched over. I'll be watching the logs for 404s.

Gadi's keen sense of the human condition shining through: when it comes to porn we are all fools.

Honestly, who still runs Fedora Core 3? The default install has nearly 500MB of updates to download and that still leaves it dreadfully out of date. It was EOL'd in early 2006.

Maybe there is a good reason for it, but I'm just not seeing it.

What is with all the sky is falling stridency lately? From Gadi Evron's OS X is the new Windows 98 to PDP's dire predictions of data: and jar: protocol attacks, there seems to be an onslaught of apocalyptic posts without anything backing them up. Just throwing out random predictions is easy, but presenting actual metrics and actionable information is where the true value lies. Not that there aren't interesting data points and insightful content to be found, it is just buried under the grand-standing and the annoying self-righteousness. Unless some people dial it down a little bit, they risk not being taken seriously.

In an effort to make the site more accessible and bring the site design out of the 1990's, I've performed a complete makeover. What originally started out as a simple update to include an RSS feed for notification of software changes morphed into a much bigger project than I expected.

I had very specific requirements in what I wanted to see with the site redesign, and I wasn't able to find any simple, secure blogging or CMS software that met my needs. So of course I set out and built a new site from scratch. The biggest hurdle has been migrating the old content to the new layout and setting up appropriate 301 redirects. This has proved quite challenging. Thank goodness for Google's site: operator.

So expect some problems as I work the kinks out.

Use WordPress. Get Hacked.

When I looked at WordPress as a blogging option, I was less than impressed. And I think that was a good choice given the most excellent pwnPress.

Updated: Kim Cameron observes: Given the current state of blogging software I expect I’ll be breached again (this is the second time my site has been hacked through a WordPress vulnerability). How is that even acceptable? If you are running a popular and trusted community-site and it gets popped, the best you can hope for is a "pwned by me" defacement. At the other end of the spectrum, you end up silently serving up drive-by exploits that own your visitors.

Wow, can you say totally clueless?