JBoss Remoting
  1. JBoss Remoting
  2. JBREM-1261

Prevent DOS attack on BisocketServerInvoker$SecondaryServerSocketThread

    Details

    • Type: Bug Bug
    • Status: Resolved 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
    • Security Level: Public (Everyone can see)
    • 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

        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: