RSA Signatures using SHA2 provided by different ssh-agent are not properly verified

[Jakub Jelen]

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.