JDK-4415668 : UnmarshalException can leave conn in invalid state
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2001-02-15
  • Updated: 2013-04-12
Related Reports
Relates :  
JDK-4716483 - server-side unmarshalling failure can cause connection reset to client
Description
An exception thrown inside UnicastServerRef.dispatch is caught without being
rethrown to the caller (Transport.serviceCall).  The caller then assumes
that the call has completed and continues to read from the connection.
TCPTransport.handleMessages then reads from the same connection and assumes
that the next data read are an opcode from the RMI protocol.  If the
exception was thrown before the call was completely unmarshalled, then those
assumptions are false; handleMessages is reading and interpreting garbage
from the connection stream.  This could lead to a method being invoked
(if actively exploited).  There's no direct security hole, but the risk is
that a security policy (e.g. an RMI protocol analyzer which expects to parse
the methods called and filter out bad ones) could depend on handleMessages
doing the right thing here.
Comments
WORK AROUND None.
11-06-2004
SUGGESTED FIX Have dispatch() rethrow the exception.
11-06-2004
PUBLIC COMMENTS An exception thrown inside UnicastServerRef.dispatch is caught without being rethrown to the caller (Transport.serviceCall). The caller then assumes that the call has completed and continues to read from the connection. TCPTransport.handleMessages then reads from the same connection and assumes that the next data read are an opcode from the RMI protocol. If the exception was thrown before the call was completely unmarshalled, then those assumptions are false; handleMessages is reading and interpreting garbage from the connection stream. This could lead to a method being invoked (if actively exploited). There's no direct security hole, but the risk is that a security policy (e.g. an RMI protocol analyzer which expects to parse the methods called and filter out bad ones) could depend on handleMessages doing the right thing here.
10-06-2004
EVALUATION Yup; JRMP is indeed unable to recover from failures that occur in the middle of marshalling or unmarshalling, since there is no intermediate protocol on the connection to frame the marshalled data. In the vast majority of cases, this just causes an early detection of the invalid protocol state, and the server quickly drops the connection anyway, although especially with debug logging enabled, this can lead to some red herring error reports. The idea of having UnicastServerRef.dispatch() throw exceptions that it encounters generally seems like a viable approach, although it's a bit tricky: We would strongly prefer not to drop the connection for exceptions that occur as a result of the actual upcall on the server object, because such exceptions should not cause the stream state to be corrupted. Therefore, dispatch() will have to be a bit clever to indicate which exceptions get rethrown and which do not. Any UnmerahslException that occurs as a result of unmarshalling parameters should get rethrown, and any unchecked exception that occurs at any time other than the upcall should get re-thrown. dispatch() will have to be somewhat carefully adjusted to implement this approach. peter.jones@East 2001-02-15
15-02-2001