mina-sshd
mina-sshd copied to clipboard
apache
Gc socks timing
There is a race condition when using SOCKS proxies with the SSHD server. After the initial SOCKS negotiation the SOCKS proxy creates a channel. When notified that the SOCKS channel is open the SOCKS proxy then sends the final accept SOCK packet. However there is a timing issue where very fast hosts could have already sent a packet over the now open channel - which will arrive at the client before the final SOCKS proxy packet. This confuses the SOCKS client connected to the server as its expected a SOCKS packet and instead gets a packet from the underlying stream.
I'm uncertain if you will want to use this code or not. The way I have fixed the race condition is a little odd in this pull request. In the patch I couldn't find an easy way to delay the underlying protocol packets until after the connection was created, so instead I send the socks response before opening the channel (which is technically wrong) and then I delay any SOCKS responses until the channel is open. The reason I did this was because this confines all of the required changes to the proxy, so it was a quicker fix for me.
I can't reproduce the problem, and I'm skeptical how it can happen. The reason is that the onChannelOpened is called when the SSH_MSG_CHANNEL_OPEN_CONFIRMATION message is received for the underlying ssh channel, and afaik, it always happen before SSH_MSG_CHANNEL_DATA. Please provide a unit test or any way to reproduce the problem.
I can't reproduce the problem, and I'm skeptical how it can happen. The reason is that the
onChannelOpenedis called when theSSH_MSG_CHANNEL_OPEN_CONFIRMATIONmessage is received for the underlying ssh channel, and afaik, it always happen beforeSSH_MSG_CHANNEL_DATA. Please provide a unit test or any way to reproduce the problem.
Actually, I found a way to reproduce the problem : https://github.com/gnodet/mina-sshd/commit/26c0f090bc7a1935c19724241184f021eba6afcd
The problem is indeed that the channel does not synchronise channel requests and the channel opening answer, so that messages can be sent on the channel before the SSH_MSG_CHANNEL_OPEN_CONFIRMATION. This looks similar to https://issues.apache.org/jira/projects/SSHD/issues/SSHD-849 but on the server side of the tcpip tunnel.
