source: http://www.securityfocus.com/bid/1545/info

A set of flaws in multiple vendors' Java implementation allows a malicious applet to open a listening socket to accept network connections against the security policy.

Java applications use the java.net.ServerSocket class to create a listening network socket on which to accept network connections. The server socket class should use the SecurityManager.checkListen() method to determine whether a class is allowed to create a server side listening socket. A SecurityException should be thrown if the class is not allowed to create such socket. By default untrusted classes such as applets should not be allowed to create such sockets. The implementation of Java fails to throw a SecurityException when an applet create a ServerSocket.

After a ServerSocket object has been created an application must accept network connections by called the ServerSocket.accept() method or by subclassing the ServerSocket class an using the ServerSocket.implAccept() method of ServerSocket to implement their own accept method. The ServerSocket.accept() method normally calls the SecurityManager.checkAccept() method to determine if a class can accept a server connection.

The ServerSocket.accept() and the ServerSocket.implAccept() methods both accept the network connection before determining if the class can accept the connection. This is done to determine the remote address and remote port number of the connection. If the connection should not be accepted these methods shutdown the connection by calling the socket's Socket.close() method, and then throwing a SecurityException.

Because the ServerSocket.implAccept() method takes as an argument a Socket object to use for the connection a malicious class can pass it an object which is subclass of the Socket class that overloads its close() method not to close the socket. By then ignoring the SecurityException the malicious class can now accept the connection and make use of the socket.

Sun's implementation of the ServerSocket.implAccept() method seems to have closed the second vulnerability by calling the Socket.impl.close() method instead of the Socket.close() method.

By combining these two flaws a malicious applet can accept connections from any host.

Both Netscape and Microsoft Java Virtual Machines are affected by this vulnerability, however in Microsoft products the file: URL type will not be effective in reading files, meaning that only web-available documents can be retreived via this method. However, the file: method will verify the existence of a file. It will check to see if the file exists and if it does not, it will return a SecurityException error message. Netscape browsers will pass both web documents and local files to the attacker. 

https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/20139.tar.gz