Bug 641389 - (CVE-2010-3862) CVE-2010-3862 JBoss Remoting Denial-Of-Service
CVE-2010-3862 JBoss Remoting Denial-Of-Service
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
public=20101201,reported=20101008,sou...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-08 11:18 EDT by Marc Schoenefeld
Modified: 2015-08-19 04:57 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-18 01:50:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBPAPP-5253 Major Resolved Apply jboss remoting 2.5.3SP1 fix 2015-08-04 11:33:57 EDT

  None (edit)
Comment 1 Marc Schoenefeld 2010-10-14 05:02:38 EDT
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.
Comment 2 Marc Schoenefeld 2010-10-15 11:16:48 EDT
Ron provided the patch description for Remoting release 2.5.3.SP1, which ships with EAP 5.1.0.GA.

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.
Comment 4 Ron Sigal 2010-10-15 17:51:39 EDT
Created attachment 453808 [details]
patch for DOS attack

Patch for Remoting release 2.5.3.SP1, which ships with EAP 5.1.0.
Comment 5 Ron Sigal 2010-10-15 17:54:59 EDT
Created attachment 453810 [details]
patch for DOS attack

Patch for Remoting release 2.2.3.SP3, which will ship with EAP 4.3.CP09
Comment 6 Ron Sigal 2010-10-15 17:56:00 EDT
I have added two patches with the same solution, one for EAP 4 and one for EAP 5.
Comment 8 Ron Sigal 2010-11-02 15:51:54 EDT
I've been asked by Permaine Cheung to comment on the assignment of "low" impact to this case.

The bisocket secondary ServerSocket that is in danger of being monopolized by a DOS attack serves two functions:

1. it creates sockets used for the bisocket "control" connection, and

2. it creates sockets used by JBossMessaging to send message payloads to JMS consumers.

At any given point in time, a JBossMessaging JMS connection has exactly one control connection.  The first one is set up when the JMS connection is created, and it would be quite hard, I think, to get the timing just right to prevent the first control connection from being set up.

There is, potentially, a ping on the control connection to determine if the control connection is functional.  In general, JBossMessaging doesn't use the ping facility, but if the ping is activitated, a control connection will be replaced if the ping fails.  So, in principle, it would be possible to prevent the recreation of a broken control connection by a DOS attack.  But that danger is relevant only in the case that the ping facility is turned on and the control connection fails.  The likelihood of this combination of events is relatively low.

When JBossMessaging wants to send a message payload to a consumer, it hands the payload off to Remoting, which then gets an available socket from a pool and sends the payload.  If the pool is empty because all sockets are in use, then it will use the control connection to try to create a new socket.  The creation of a new socket could be disabled by a DOS attack.  In that case, the attempt to send the message payload would fail.  In fact, if the "timeout" parameter is set to zero, which is typically the case in JBossMessaging, Remoting will wait forever for the socket, which will hang up the attempt to send the message payload.

I believe, though I don't know for sure, that JBossMessaging configures Remoting to maintain a pool of exactly zero or one sockets.  If that's the case, then a DOS attack would be effective only before the socket is created, which would occur when JBossMessaging attempts to send its first message payload. If the DOS attack is timed properly, then it would be possible to prevent JBossMessaging from sending any messages to a consumer, and it would be necessary to restart the server.  However, knowing when to time the attack might require knowing something about the JMS application.  

To conclude, a DOS attack on the bisocket secondary ServerSocket could be disruptive, but it may be difficult to get the timing right.
Comment 9 Ole Husgaard 2010-11-29 11:10:13 EST
It has now been almost two months since we reported this vulnerability, and almost one month with no activity here. Any progress?

Is it possible that we could get access to the proposed patch? This vulnerability is hitting us bad, and unless we have other options, we will soon have to start working on our own fix for this.
Comment 10 Vincent Danen 2010-12-01 17:38:34 EST
Acknowledgements:

Red Hat would like to thank Ole Husgaard of eXerp.com for reporting this issue.
Comment 11 errata-xmlrpc 2010-12-01 18:15:51 EST
This issue has been addressed in following products:

  JBEAP 4.3.0 for RHEL 4

Via RHSA-2010:0937 https://rhn.redhat.com/errata/RHSA-2010-0937.html
Comment 12 errata-xmlrpc 2010-12-01 18:36:28 EST
This issue has been addressed in following products:

  JBEAP 4.3.0 for RHEL 5

Via RHSA-2010:0938 https://rhn.redhat.com/errata/RHSA-2010-0938.html
Comment 13 errata-xmlrpc 2010-12-01 18:51:59 EST
This issue has been addressed in following products:

  JBoss Enterprise Application Platform 4.3.0

Via RHSA-2010:0939 https://rhn.redhat.com/errata/RHSA-2010-0939.html
Comment 14 Marc Schoenefeld 2010-12-07 08:55:09 EST
Unlike the errata stated, the RHSA-2010:0937, RHSA-2010:0938 and RHSA-2010:0939 updates did not fix the CVE-2010-3862 flaw. A future update will address this issue.
Comment 15 Ole Husgaard 2010-12-07 09:12:44 EST
Now that you have made the attack vector public (see comment 1), could you please, please make your patch for this public too, even if completely untested?
Comment 16 errata-xmlrpc 2010-12-08 14:21:48 EST
This issue has been addressed in following products:

  JBEAP 5 for RHEL 5

Via RHSA-2010:0960 https://rhn.redhat.com/errata/RHSA-2010-0960.html
Comment 17 errata-xmlrpc 2010-12-08 14:22:03 EST
This issue has been addressed in following products:

  JBEAP 5 for RHEL 4

Via RHSA-2010:0959 https://rhn.redhat.com/errata/RHSA-2010-0959.html
Comment 18 errata-xmlrpc 2010-12-08 14:27:20 EST
This issue has been addressed in following products:

  JBEWP 5 for RHEL 4
  JBEWP 5 for RHEL 5

Via RHSA-2010:0961 https://rhn.redhat.com/errata/RHSA-2010-0961.html
Comment 19 errata-xmlrpc 2010-12-08 14:32:32 EST
This issue has been addressed in following products:

  JBoss Enterprise Web Platform 5.1.0

Via RHSA-2010:0962 https://rhn.redhat.com/errata/RHSA-2010-0962.html
Comment 20 errata-xmlrpc 2010-12-08 14:37:42 EST
This issue has been addressed in following products:

  JBoss Enterprise Application Platform 5.1.0

Via RHSA-2010:0963 https://rhn.redhat.com/errata/RHSA-2010-0963.html
Comment 21 Vincent Danen 2010-12-08 17:37:21 EST
(In reply to comment #15)
> Now that you have made the attack vector public (see comment 1), could you
> please, please make your patch for this public too, even if completely
> untested?

This is now fixed, via:

RHSA-2010:0964 https://rhn.redhat.com/errata/RHSA-2010-0964.html and RHSA-2010:0965 https://rhn.redhat.com/errata/RHSA-2010-0965.html.
Comment 22 Ron Sigal 2010-12-17 21:07:35 EST
I created JBREM-1261 "Prevent DOS attack on BisocketServerInvoker$SecondaryServerSocketThread" for applying the patch to the 2.2 and 2.5 versions of Remoting.
Comment 23 Ron Sigal 2010-12-17 21:24:33 EST
I committed the changes to Remoting branches 2.2 (for versions 2.2.x) and branch 2.x (for versions 2.5.x).
Comment 24 Ron Sigal 2010-12-24 14:37:02 EST
I have closed JBREM-1261.  The fix will appear in Remoting releases 2.5.3.SP2 (for EAP 5) and 2.2.3.SP4 (for EAP 4).

Note You need to log in before you can comment on or make changes to this bug.