[JBoss JIRA] Created: (JBREM-1261) Prevent DOS attack on BisocketServerInvoker$SecondaryServerSocketThread
by Ron Sigal (JIRA)
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.2.3.SP3, 2.5.3.SP1
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.5.3.SP2, 2.2.3.…
[View More]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
[View Less]
14 years, 1 month
[JBoss JIRA] Created: (JBREM-1263) ClientSocketWrapper.checkConnection() should check returned value
by Ron Sigal (JIRA)
ClientSocketWrapper.checkConnection() should check returned value
-----------------------------------------------------------------
Key: JBREM-1263
URL: https://issues.jboss.org/browse/JBREM-1263
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.3.SP3, 2.5.3.SP1
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.5.3.SP2, 2.2.3.SP4
The …
[View More]old and new connection checking tests used by org.jboss.remoting.transport.socket.ClientSocketWrapper and ServerSocketWrapper interact in a negative way. In the old test, turned on when socket.check_connection is set to true, ClientSocketWrapper sends a 1, ServerSocketWrapper returns it, and if ClientSocketWrapper is able to read a byte, the test passes. But in the new test, ServerSocketWrapper writes two 254 bytes as it is closing. If ClientSocketWrapper is doing the old test and it reads one of these bytes, it thinks the test has passed. It should check for the actual value of the returned byte.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
14 years, 2 months
[JBoss JIRA] Created: (JBREM-1246) Can't authenticate using TransporterClient
by Sebastian Dietrich (JIRA)
Can't authenticate using TransporterClient
------------------------------------------
Key: JBREM-1246
URL: https://jira.jboss.org/browse/JBREM-1246
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.5.2.SP3 (Flounder)
Reporter: Sebastian Dietrich
I'd like to introduce basic authentication in my project which uses TransporterClient to connect to the server. …
[View More]According to the documentation (http://docs.jboss.org/jbossremoting/2.5.3.SP1/html_single/#d0e2251 5.4.11. HTTP(S) Client Invoker - proxy and basic authentication) this is not supported with TransporterClient, but only via response = client.invoke(payload, metadata);
TransporterClient uses response = remotingClient.invoke(request); (see TransporterClient.class Line 321)
Unfortunately I can neither subclass TransporterClient (since its constructors are private) nor decorate it (since its invoke method I'd like to change uses private attributes & methods).
==> Please provide a way to use basic authentication in TransporterClient
This could be done easily via a further constructor/factory method which accepts metadata.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
14 years, 2 months
[JBoss JIRA] Created: (JBREM-1238) Need invocation timeouts in synchronized blocks in MicroRemoteClientInvoker that create and terminate leases
by Ron Sigal (JIRA)
Need invocation timeouts in synchronized blocks in MicroRemoteClientInvoker that create and terminate leases
-------------------------------------------------------------------------------------------------------------
Key: JBREM-1238
URL: https://jira.jboss.org/browse/JBREM-1238
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.5.3.SP1
Reporter: Ron Sigal
…
[View More] Assignee: Ron Sigal
Fix For: 2.5.2.SP2 (Flounder)
org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network invocations inside synchronized blocks, and, if the invocations get hung up, then it becomes impossible to create new connections with leasing enabled. Setting the 'timeout" parameter appropriately would work around the problem, but some users, notably JBossMessaging, set "timeout" to 0.
A speclal case timeout parameter should be used, along with the per invocation timeout facility, to prevent MicroRemoteClientInvoker from getting stuck in establishLease() or terminateLease().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
14 years, 2 months