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.
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.
Created attachment 453808 [details] patch for DOS attack Patch for Remoting release 2.5.3.SP1, which ships with EAP 5.1.0.
Created attachment 453810 [details] patch for DOS attack Patch for Remoting release 2.2.3.SP3, which will ship with EAP 4.3.CP09
I have added two patches with the same solution, one for EAP 4 and one for EAP 5.
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.
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.
Acknowledgements: Red Hat would like to thank Ole Husgaard of eXerp.com for reporting this issue.
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
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
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
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.
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 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
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
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
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
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
(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.
I created JBREM-1261 "Prevent DOS attack on BisocketServerInvoker$SecondaryServerSocketThread" for applying the patch to the 2.2 and 2.5 versions of Remoting.
I committed the changes to Remoting branches 2.2 (for versions 2.2.x) and branch 2.x (for versions 2.5.x).
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).