Jakub Jelen
2017-Nov-09 10:13 UTC
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.
Damien Miller
2017-Nov-10 00:11 UTC
RSA Signatures using SHA2 provided by different ssh-agent are not properly verified
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 >
Jakub Jelen
2017-Nov-10 07:22 UTC
RSA Signatures using SHA2 provided by different ssh-agent are not properly verified
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.
Possibly Parallel Threads
- [Bug 2746] New: RFE: Allow to disable SHA1 signatures for RSA
- no mutual signature algorithm with RSA user certs client 7.8, server 7.4
- Server accepts key: pkalg rsa-sha2-512 vs ssh-rsa
- "ssh -Q key" does not list rsa-sha2 algorithms
- [Bug 2568] New: ssh fails to authenticate using RSA keys when agent does not support sha256/512 signatures