[
https://issues.jboss.org/browse/JBREM-1261?page=com.atlassian.jira.plugin...
]
Ron Sigal commented on JBREM-1261:
----------------------------------
When a socket request comes in to the ServerSocket managed by
org.jboss.remoting.transport.bisocket.BisocketServerInvoker$SecondaryServerSocketThread,
all processing on the newly created socket is handed off to a separate thread. The
existing variable "maxPoolSize" (which defaults to 300) is used to limit the
number of such threads, which eliminates the possibilty of an alternative DOS attack which
creates an unmanageable number of threads. Also, the timeout value of each socket is set
to 30 seconds so that an attempt to hang up socket processing threads by withholding
expected bytes will fail in a timely manner.
Unit test: org.jboss.test.remoting.transport.bisocket.dos.DosTestCase
Waiting for results in hudson.
Prevent DOS attack on
BisocketServerInvoker$SecondaryServerSocketThread
-----------------------------------------------------------------------
Key: JBREM-1261
URL:
https://issues.jboss.org/browse/JBREM-1261
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 2.5.3.SP1, 2.2.3.SP3
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.5.3.SP2, 2.2.3.SP4
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
org.jboss.remoting.transport.bisocket.BisocketServerInvoker$SecondaryServerSocketThread.run(),
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
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira