Status: Resolved (View Workflow)
Affects Version/s: 2.5.3.SP1, 2.2.3.SP3
Security Level: Public (Everyone can see)
Similar Issues:Show 10 results
JBREM-610 Prevent org.jboss.remoting.callback.CallbackPoller from delivering callbacks out of order. JBREM-1005 Prevent build up of cancelled TimerTasks in bisocket transport JBREM-1055 ConnectionValidator.run() should have a sanity test to prevent calls from application code JBREM-247 Check for localSocketId == null in MultiplexingManager.unRegisterSocket() JBREM-1268 RemoteClientInvoker can change configuration map and prevent InvokerRegistry from reusing client invokers JBREM-457 Prevent race between socket group closing new invoker looking for a shareable MultiplexingManager. JBREM-706 In socket transport, prevent client side oneway invocations from artificially reducing concurrency JBREM-1123 SocketServerInvoker needs an immediate shutdown option JBREM-202 getUnmarshaller always calls Class.forName operation for creating Unmarshallers JBREM-989 Move reference to javax.servlet.ServletException out of SecurityUtility
From the original bug report:
Exploiting and thus confirming this vulnerability is extremely simple: Simply
connect to the bisocket control connection (ie. "telnet <jboss-host>
<control-connection-port>") without sending any data on the connection. As long
as this connection is open, no clients can connect to the bisocket control port
because the connections are not accepted at server side.
The cause of this vulnerability is found in method
which contains the accept-loop for the bisocket control connection. After
having accepted a connection, the accept loop thread reads from the newly
created connection expecting the client to send an action code and a listener
id. If the client sends nothing, the accept loop thread will block in the read
call, causing no other connections to be accepted.
To fix, the accept loop thread should not do the read on the new connection.
Instead it should start a new thread that does the read