Sun says:

There are two reasons why this DNS Spoofing attack works:

1. It's relatively easy for someone to advertise false IP addresses. That is, it's relatively easy for someone to run their own domain name resolver.
2. The applet security manager allows an applet to connect to any of the IP addresses associated with the name of the computer that it came from.

That's correct. Number 1 is a well-known feature of the Internet protocols - surely Sun knew about it. Number 2 was Sun's mistake.

According to Sun's Java security documentation, a Java applet is allowed to connect only to the machine it was loaded from. Rather than enforcing this simple and secure rule, Sun enforced condition number 2, which is much weaker.

Sun can fix the bug by simply enforcing the rule they said they were enforcing. They should make sure that an applet can connect only to the IP address it came from.

The right solution for this problem is to make the Domain Name Service more secure. It shouldn't be so easy for anyone to advertise false names or false addresses.

This is true, but irrelevant. Changing DNS would mean changing the fundamental structure of the Internet. That's just not going to happen any time soon. Java should be secure in today's Internet.

A fix for the applet security manager is to be more strict about deciding which computers an applet is allowed to connect to. The Java system needs to take note of the actual IP address that the applet truly came from (getting that numerical address from the applet's packets, as the applet is being loaded), and thereafter only allow the applet to connect to that exact same numerical address. Additionally, the Java system could be even stricter than that, by declaring that an applet can only connect to the same port number that it came from, in addition to only being allowed to connect to the same IP address that it came from.

We agree. This is the best way for Sun to fix the problem.

But this is not something a Java user can fix. Until Sun issues a fix, a user cannot defend themselves against the attack, except by disabling Java.

An applet on its own cannot carry out this attack. It would have to be working in conjunction with a hacked DNS server owned and ascribed to some domain.

A single person, acting alone, can carry out this attack. The person would need to get their own DNS domain, but that's easy. All you need is $100, a computer, and a connection to an Internet Service Provider.

Also, the attack applet would have to know the name and IP address of machines inside a corporate firewall, in order to try to establish a connection to machines behind the firewall.

Actually, the attack applet only needs to know the range of IP addresses available behind the firewall. The InterNIC Registration Service, a publicly accessible database, tells IP address ranges for any sub-network connected to the Internet. With this, an applet just needs to scan the available range of addresses.

In any case, even if the applet cannot guess the IP addresses of any machines behind the firewall, it can always use the IP loopback address, 127.0.0.1, to attack the network services of the machine running the applet.

Sun will be distributing a patch to the applet security manager to implement the more rigorous checking described above. That fix will be available within a few days, and it will be distributed in source code and in bytecode format.

We compliment Sun for addressing this problem seriously and fixing it quickly.