Multiple Vendor Java ServerSocket Security Bypass Vulnerability
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.
