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]

 



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



[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