[
https://issues.apache.org/jira/browse/SSHD-1197?focusedWorklogId=622897&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-622897
]
ASF GitHub Bot logged work on SSHD-1197:
----------------------------------------
Author: ASF GitHub Bot
Created on: 15/Jul/21 07:26
Start Date: 15/Jul/21 07:26
Worklog Time Spent: 10m
Work Description: tomaswolf commented on a change in pull request #201:
URL: https://github.com/apache/mina-sshd/pull/201#discussion_r670204650
##########
File path:
sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java
##########
@@ -109,6 +109,16 @@
*/
public static final String SESSION = "org.apache.sshd.session";
+ /**
+ * A last-resort timeout for waiting after having received a KEX_INIT
message from the peer until we have prepared
+ * our own KEX proposal. This timeout should actually never be hit unless
there is a serious deadlock somewhere and
+ * the session is never closed.
+ *
+ * @see <a
href="https://issues.apache.org/jira/browse/SSHD-1197";>SSHD-1197</a>
+ * @see #doKexNegotiation()
+ */
+ private static final Duration KEX_PROPOSAL_SETUP_TIMEOUT =
Duration.ofSeconds(42);
Review comment:
I've been thinking more about this -- I'll add it with validation for
now. Reason: we are indeed waiting until sendKexInit has sent the buffer (or
rather, has queued it for sending on the IOSession). But I'm still not happy
with that whole KEX implementation. In particular, this having to wait until
the buffer is sent should not be necessary, but with the current implementation
is unavoidable because of the
`ReservedSessionMessagesHandler.sendKexInitRequest` hook added for SSHD-1097,
which can modify the buffer and even might send it on its own.
That hook was added recently, and is used only in that "endless tarpit"
thing, where it actually only suppresses writing the buffer. If that were
changed to something that could only say "don't send the message", I could
extract that whole KEX state machine in a separate class and it would even
possible to do an implementation that didn't have to wait at all for this race
condition case handled here.
I wouldn't add a full explanation of how KEX works, that's explained in the
RFCs. But the new timeout property will have a comment explaining what it is
for.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 622897)
Time Spent: 2h 20m (was: 2h 10m)
> Race condition in KEX
> ---------------------
>
> Key: SSHD-1197
> URL: https://issues.apache.org/jira/browse/SSHD-1197
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 2.7.0
> Reporter: Thomas Wolf
> Assignee: Thomas Wolf
> Priority: Critical
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> There is a race condition in the KEX implementation. A simple reproducer can
> be obtained by modifying {{SftpTransferTest}} by inserting the following in
> method {{doTestTransferIntegrity()}} just before the main {{try-finally}}:
> {code:java}
> CoreModuleProperties.REKEY_BLOCKS_LIMIT.set(client, Long.valueOf(65536));
> CoreModuleProperties.REKEY_BLOCKS_LIMIT.set(sshd, Long.valueOf(65536));
> try (ClientSession session = createAuthenticatedClientSession();
> ...
> {code}
> This forces rekeying every 512kB; the test roundtrips a 10Mb file twice,
> which gives ample opportunity to run into this race condition. Typically the
> test fails very quickly and hangs.
> The hang is always caused by an async write not being cancelled when the
> session gets disconnected. The session disconnects during KEX because KEX
> state is corrupted because of the race condition.
> Most of the time the race condition causes a signature verification failure
> during KEX, but I also got
> "Disconnecting(ClientSessionImpl[testTransferIntegrity@/127.0.0.1:62186]):
> SSH2_DISCONNECT_KEY_EXCHANGE_FAILED - Unable to negotiate key exchange for
> mac algorithms (server to client) (client: null / server:
> [email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1)",
> which is easier to understand than the signature verification failure.
> The precise sequence of events in that case is
> {code:java}
> Server Client
> 1. thread-nio-4 requestNewKeyExchange DONE->INIT
> 2. thread-nio-4 sendKexInit
> 3. main
> requestNewKeyExchange DONE->INIT
> 4. thread-nio-3
> handleKexInit
> 5. thread-nio-3
> doKexNegotiation INIT->RUN
> 6. thread-nio-3
> negotiate -> Exception: client proposal null
> 7. main
> sendKexInit
> 8. thread-nio-2 receive KEX_INIT INIT->RUN
> 9. thread-nio-3
> Exception caught
> 10. thread-nio-3
> Disconnecting
> 11. thread-nio-5 process SSH_MSG_DISCONNECT (KexState RUN)
> {code}
> There is window between steps 3 and 7 in
> {{AbstractSession.requestNewKeyExchange()}} during which the KEX state is
> INIT, but the client proposal isn't initialized yet; it's initialized only
> after {{sendKexInit()}} has been done. However, the client already got the
> server's KEX_INIT message, and in {{doKexNegotiation()}} proceeds as if the
> client proposal was already set up.
> So, theres' two problems here:
> # KEX fails due to a race condition.
> # The client hangs after disconnecting because an async write future is not
> terminated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
