Password authentication problem with 6.4p1 (and later) clients: An analysis

[JCA]

> I don't think there is any new DoS here. A broken/malicious server
> could just hang after authentication and achieve the same result.

Not quite the same. The client would hang, whereas in this case it
enters an infinite loop. Anyhow, like you said, an extra dollop of
intelligence in the client's code would be welcome here.

On Mon, Aug 4, 2014 at 6:25 PM, Damien Miller <djm at mindrot.org> wrote:
> 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