JCA
2014-Aug-04 14:51 UTC
Password authentication problem with 6.4p1 (and later) clients: An analysis
I have been looking into this over the weekend, and what I have found might be of interest to OpenSSH developers. First, the bug that triggers the problem is in the embedded system. Second, such as things were changed in 6.4p1, the OpenSSH client seems to be open to a potential DoS attack. The infinite loop described in my previous post is embodied in the last four messages of the 6.4p1 traces. That is, from that point onward client and server exchange that block of four messages, over and over again. The first SSH_MSG_USERAUTH_FAILURE message sent by the embedded server as a response to the the first SSH_MSG_USERAUTH_REQUEST message received from the client, for public key authentication and with the authentication Boolean set to TRUE, is formatted incorrectly. Indeed, the partial success Boolean should have been FALSE, rather than TRUE, because it was generated as a response to an SSH_MSG_USERAUTH_REQUEST message with an authentication Boolean set to TRUE (i.e. a real public key authentication request, rather than just a probe) and the authentication itself failed. In the OpenSSH side, when receiving an SSH_MSG_USERAUTH_FAILURE message, the OpenSSH client code will invoke a function called 'input_userauth_failure'. This function will retrieve the value of the partial success Boolean from the incoming message and will store it into a variable called 'partial'. Then, in 6.4p1 and later, 'input_userauth_failure' will do the following: if (partial != 0) { logit("Authenticated with partial success."); /* reset state */ pubkey_cleanup(authctxt); pubkey_prepare(authctxt); } debug("Authentications that can continue: %s", authlist); Before 6.4p1 the 'pubkey_cleanup' and 'pubkey_prepare' invocation were missing. The undesirable behavior is introduced by 'pubkey_prepare'. When invoked here, it will modify the OpenSSH authentication context 'authctxt' so that the client code will try public key authentication again - rather than falling back to the next authentication mechanism (password authentication, in this case) as it should. An infinite loop ensues. Before the 'pubkey_*' lines were introduced OpenSSH would still do the right thing, despite of the fact that it was getting a misleading message from the embedded server. Thus, although OpenSSH 6.4p1 and later clients are proceeding correctly according to the standards, because of the way the code is organized a malicious server could potentially cause problems to clients. This would probably be no more than a nuisance for actual interactive sessions, but might be a real issue for batch ones.
Damien Miller
2014-Aug-05 00:25 UTC
Password authentication problem with 6.4p1 (and later) clients: An analysis
On Mon, 4 Aug 2014, JCA wrote:> if (partial != 0) { > logit("Authenticated with partial success."); > /* reset state */ > pubkey_cleanup(authctxt); > pubkey_prepare(authctxt); > } > debug("Authentications that can continue: %s", authlist); > > Before 6.4p1 the 'pubkey_cleanup' and 'pubkey_prepare' invocation were > missing. The undesirable behavior is introduced by 'pubkey_prepare'. > When invoked here, it will modify the OpenSSH authentication context > 'authctxt' so that the client code will try public key authentication > again - rather than falling back to the next authentication mechanism > (password authentication, in this case) as it should. An infinite loop > ensues. Before the 'pubkey_*' lines were introduced OpenSSH would > still do the right thing, despite of the fact that it was getting a > misleading message from the embedded server.The idea here is that if a server supports multiple authentications, then it should be managing the list of authentications that can continue. In particular, once key based authentication is complete and the server won't accept any more keys then the server should no longer offer publickey in the list of accepted auth methods. I agree the client should be a bit smarter here about not trying things that have already succeeded or failed.> Thus, although OpenSSH 6.4p1 and later clients are proceeding > correctly according to the standards, because of the way the code is > organized a malicious server could potentially cause problems to > clients. This would probably be no more than a nuisance for actual > interactive sessions, but might be a real issue for batch ones.I don't think there is any new DoS here. A broken/malicious server could just hang after authentication and achieve the same result. -d
Maybe Matching Threads
- Password authentication problem with 6.4p1 (and later) clients
- [Bug 2642] New: [sshconnect2] publickey authentication only properly works if used first: pubkey_prepare doesn't work after pubkey_cleanup
- Attempts to connect to Axway SFTP server result in publickey auth loopin
- Authentication protocol
- [patch] Automatically add keys to agent