Re: Bugs when using rsa-sha2 (+patches)

[Tilo Eckert <tilo.eckert@xxxxxxx>]

Hello Jakub

> With your proposed patch, we are basically opening us to the downgrade
> attack (the client request SHA2 signatures, the server sends the SHA1
> signature and it is properly verified and accepted by the client),
> similarly as it worked some time ago in OpenSSH (with client
> authentication):
> 
> https://bugzilla.mindrot.org/show_bug.cgi?id=2799

I see what you mean. However, having to allow sha-rsa alongside rsa-sha2
isn't any better, except that the downgrade attack is more obvious. ;-)

If I understand ssh_pki_signature_verify_blob() correctly, the server
could also perform an upgrade "attack", i.e. send a SHA2 signature when
only ssh-rsa is allowed.

The function ssh_pki_signature_verify_blob() is used by server
(messages.c) and client code (packet_cb.c). So, I think one way to fix
it is to remove the ssh_pki_import_signature_blob() call from
ssh_pki_signature_verify_blob(), move it to the two callers and pass sig
instead of sig_blob to the verify function. That would allow us to check
the signature type in ssh_packet_newkeys() depending on the allowed
hostkey types.

I think there may be another unrelated security issue in
ssh_pki_signature_verify_blob(): When compiling without ECC support and
the server sends an unexpected ECDSA signature, it would be imported
successfully, "if (key->type == SSH_KEYTYPE_ECDSA)" would be true, but
the block does nothing. The function returns rc, which is still 0 from
the import. Maybe I missed something, but this looks to me like a
signature verification bypass. We should return SSH_ERROR if ECC is
unsupported.

Regards
Tilo