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

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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@xxxxxxxxxxx
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux