openssh bugs - Dec 2021 - [Bug 3375] New: SHA1 is used as a proof of possession for the RSA key

https://bugzilla.mindrot.org/show_bug.cgi?id=3375

            Bug ID: 3375
           Summary: SHA1 is used as a proof of possession for the RSA key
           Product: Portable OpenSSH
           Version: 8.7p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: dbelyavs at redhat.com

If we need to get a proof of ownership for a RSA key on establishing a
connection, the SHA1 algorithm is used by default (see the ssh_rsa_sign
function). Not sure that it is the best possible option now. 

As it is possible to explicitly request the hash, it's worth analyze
the client's capabilities and use SHA2 for this purpose.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3375

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
I'm not sure what you're talking about - there are already extensive
negotiation mechanisms that default to SHA2 for user and host
authentication.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3375

--- Comment #2 from Dmitry Belyavskiy <dbelyavs at redhat.com> ---
When we have, say, an ECDSA key confirmed by fingerprint and RSA key to
be confirmed, we have EC-based KEX, so the KEX-based prevention of
using SHA1
(https://github.com/openssh/openssh-portable/blob/7a7c69d8b4022b1e5c0afb169c416af8ce70f3e8/serverloop.c#L725-L730)
will not work and SHA1 will be used for the proof of posession of the
RSA key.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3375

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jjelen at redhat.com

--- Comment #3 from Jakub Jelen <jjelen at redhat.com> ---
The condition `kexsigtype == KEY_RSA` in the above link will work only
if the rsa-sha2-* hostkey type was negotiated during key exchange and
we are sending a proof of possession of another RSA key.

In any other case, for example ECDSA or Ed25519 hostkey is negotiated,
the above condition will evaluate always to `false` and RSA with SHA1
will be used regardless the client capabilities.

I think the above condition should be rewritten to check not against
the negotiated hostkey type, but if the client supports the RSA with
SHA2 (regardless of the negotiated key type). But I did not have time
to look better into the implementation yet.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3375

--- Comment #4 from Dmitry Belyavskiy <dbelyavs at redhat.com> ---
Created attachment 3559
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3559&action=edit
Here is the proposed solution

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3375

Dmitry Belyavskiy <dbelyavs at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P5                          |P3

--- Comment #5 from Dmitry Belyavskiy <dbelyavs at redhat.com> ---
I suggest to increase the priority. The problem occurs when we use
OpenSSL in FIPS mode, so signing a SHA1 hash becomes not an option.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3375

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3559|0                           |1
        is obsolete|                            |

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
Created attachment 3561
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3561&action=edit
tweaked diff

IMO it's important to retain the current algorithm selection logic for
RSA keys, because otherwise the client will reject them for having the
wrong signature algorithm.

This patch does this and tweaks a few other things.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3375

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
Created attachment 3562
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3562&action=edit
client side

Similarly, if you want to avoid use of RSA-SHA1 completely then you
also need to ensure the client only accepts RSA-SHA2 signatures.

This patch to the client does this. It will disregard hostkey proofs if
they use ssh-rsa except when it has been explicitly negotiated as the
hostkey algorithm.

AFAIK this should be fine for backwards compatibility, except for the
case when a <openssh-8.9 server is configured with multiple RSA keys. I
expect this to be a rare situation.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3375

--- Comment #8 from Dmitry Belyavskiy <dbelyavs at redhat.com> ---
Thanks!

I need to test it, but your code looks great.

The problem is, when we are in FIPS mode, we shouldn't use sha1 for
signature (but still are allowed to use for the verification).

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3375

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
             Blocks|                            |3353

--- Comment #9 from Damien Miller <djm at mindrot.org> ---
These have been committed now. Thanks for spotting the bug and for
providing a fix. If there are any further problems then please reopen
this bug


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=3353
[Bug 3353] Tracking bug for openssh-8.9
-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3375

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #10 from Damien Miller <djm at mindrot.org> ---
closing bugs resolved before openssh-8.9

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.