JBoss Remoting
  1. JBoss Remoting
  2. JBREM-1261

Prevent DOS attack on BisocketServerInvoker$SecondaryServerSocketThread

    Details

    • Type: Bug Bug
    • Status: Resolved (View Workflow)
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: 2.5.3.SP1, 2.2.3.SP3
    • Fix Version/s: 2.5.4.SP1, 2.2.4
    • Component/s: None
    • Labels:
      None
    • Steps to Reproduce:
      Hide

      See problem description.

      Show
      See problem description.
    • Similar Issues:
      Show 10 results 

      Description

      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

        Gliffy Diagrams

          Activity

          Hide
          Ron Sigal added a comment -

          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.

          Show
          Ron Sigal added a comment - 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.
          Hide
          Ron Sigal added a comment -

          Tests are passing in hudson.

          Show
          Ron Sigal added a comment - Tests are passing in hudson.

            People

            • Assignee:
              Ron Sigal
              Reporter:
              Ron Sigal
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development