openssh unix dev - Nov 2017 - RSA Signatures using SHA2 provided by different ssh-agent are not properly verified

Hello,
as a follow-up on my mail some time last month where we were facing
weird issues when authenticating to new OpenSSH servers, I went down
the road to investigate what is really going on there and I found out
that even though all the logs in client and server happily say that the
 SHA2 extension is used, under the hood there is just SHA1. This is
because the different agents are ignoring the flags passed with the
signature request. This can be simply reproduced with the following
patch, which dumps the actual hash algorithm used in the signature
itself:

https://gist.github.com/Jakuje/b1f7161d89472c4b6a3e2024675b0b46

The issue can be simply reproduced by running ssh-agent from gnome-
keyring (pageant or others should do the same) and connect to the
server with the above patch. In the server log, we can notice the
following messages (where hash_alg=1 is SSH_DIGEST_SHA1):

debug1: Verifying signature with ktype=ssh-rsa and hash_alg=1
debug2: userauth_pubkey: authenticated 1 pkalg rsa-sha2-512

So even though all the current messages say that sha2 is used,
something else is going on here. Nor client nor server is verifying
that the signature itself is done using the requested algorithm.

So how to get around that?

The most robust solution would be to use ssh-agent extension protocol
to negotiate these extensions also with the agent. The downside of this
is that current implementations do not know the extension messages and
fail if I remember well the gnome-keyring behavior. This would allow us
to know what signature will be used in advance.

Other thing should be checking what signature we got from agent and if
it is not the one we requested, downgrade the algorithm in the
authentication packet to reflect the reality (or fail some way?).
Similar thing should be done also on the server, where the verification
also does not compare authentication header algorithm and the algorithm
in the signature itself.

Is it intentional or did I miss something in my write-up?

This can be considered as a security issue, because all the logs say
that stronger algorithm is used even if it is not true.

Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.

could you please file a bug for this, I'll take a look.

On Thu, 9 Nov 2017, Jakub Jelen wrote:
> Hello,
> as a follow-up on my mail some time last month where we were facing
> weird issues when authenticating to new OpenSSH servers, I went down
> the road to investigate what is really going on there and I found out
> that even though all the logs in client and server happily say that the
>  SHA2 extension is used, under the hood there is just SHA1. This is
> because the different agents are ignoring the flags passed with the
> signature request. This can be simply reproduced with the following
> patch, which dumps the actual hash algorithm used in the signature
> itself:
> 
> https://gist.github.com/Jakuje/b1f7161d89472c4b6a3e2024675b0b46
> 
> The issue can be simply reproduced by running ssh-agent from gnome-
> keyring (pageant or others should do the same) and connect to the
> server with the above patch. In the server log, we can notice the
> following messages (where hash_alg=1 is SSH_DIGEST_SHA1):
> 
> debug1: Verifying signature with ktype=ssh-rsa and hash_alg=1
> debug2: userauth_pubkey: authenticated 1 pkalg rsa-sha2-512
> 
> So even though all the current messages say that sha2 is used,
> something else is going on here. Nor client nor server is verifying
> that the signature itself is done using the requested algorithm.
> 
> So how to get around that?
> 
> The most robust solution would be to use ssh-agent extension protocol
> to negotiate these extensions also with the agent. The downside of this
> is that current implementations do not know the extension messages and
> fail if I remember well the gnome-keyring behavior. This would allow us
> to know what signature will be used in advance.
> 
> Other thing should be checking what signature we got from agent and if
> it is not the one we requested, downgrade the algorithm in the
> authentication packet to reflect the reality (or fail some way?).
> Similar thing should be done also on the server, where the verification
> also does not compare authentication header algorithm and the algorithm
> in the signature itself.
> 
> Is it intentional or did I miss something in my write-up?
> 
> This can be considered as a security issue, because all the logs say
> that stronger algorithm is used even if it is not true.
> 
> Regards,
> -- 
> Jakub Jelen
> Software Engineer
> Security Technologies
> Red Hat, Inc.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

On Fri, 2017-11-10 at 11:11 +1100, Damien Miller wrote:
> could you please file a bug for this, I'll take a look.
Done. The bug is here:

https://bugzilla.mindrot.org/show_bug.cgi?id=2799
Hopefully, it will be more understandable with more references.

Jakub
> 
> On Thu, 9 Nov 2017, Jakub Jelen wrote:
> 
> > Hello,
> > as a follow-up on my mail some time last month where we were facing
> > weird issues when authenticating to new OpenSSH servers, I went
> > down
> > the road to investigate what is really going on there and I found
> > out
> > that even though all the logs in client and server happily say that
> > the
> >  SHA2 extension is used, under the hood there is just SHA1. This is
> > because the different agents are ignoring the flags passed with the
> > signature request. This can be simply reproduced with the following
> > patch, which dumps the actual hash algorithm used in the signature
> > itself:
> > 
> > https://gist.github.com/Jakuje/b1f7161d89472c4b6a3e2024675b0b46
> > 
> > The issue can be simply reproduced by running ssh-agent from gnome-
> > keyring (pageant or others should do the same) and connect to the
> > server with the above patch. In the server log, we can notice the
> > following messages (where hash_alg=1 is SSH_DIGEST_SHA1):
> > 
> > debug1: Verifying signature with ktype=ssh-rsa and hash_alg=1
> > debug2: userauth_pubkey: authenticated 1 pkalg rsa-sha2-512
> > 
> > So even though all the current messages say that sha2 is used,
> > something else is going on here. Nor client nor server is verifying
> > that the signature itself is done using the requested algorithm.
> > 
> > So how to get around that?
> > 
> > The most robust solution would be to use ssh-agent extension
> > protocol
> > to negotiate these extensions also with the agent. The downside of
> > this
> > is that current implementations do not know the extension messages
> > and
> > fail if I remember well the gnome-keyring behavior. This would
> > allow us
> > to know what signature will be used in advance.
> > 
> > Other thing should be checking what signature we got from agent and
> > if
> > it is not the one we requested, downgrade the algorithm in the
> > authentication packet to reflect the reality (or fail some way?).
> > Similar thing should be done also on the server, where the
> > verification
> > also does not compare authentication header algorithm and the
> > algorithm
> > in the signature itself.
> > 
> > Is it intentional or did I miss something in my write-up?
> > 
> > This can be considered as a security issue, because all the logs
> > say
> > that stronger algorithm is used even if it is not true.