[jboss-remoting-issues] [JBoss JIRA] Commented: (JBREM-1261) Prevent DOS attack on BisocketServerInvoker$SecondaryServerSocketThread

[Ron Sigal (JIRA)]

    [ https://issues.jboss.org/browse/JBREM-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571178#comment-12571178 ] 

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