openssh bugs - May 2021 - [Bug 3313] New: CVE-2020-14145 - will it get fixed?

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

            Bug ID: 3313
           Summary: CVE-2020-14145 - will it get fixed?
           Product: Portable OpenSSH
           Version: 8.6p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: security
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: m.kaiser at bmlv.gv.at

The client side in OpenSSH 5.7 through 8.6 has an Observable
Discrepancy leading to an information leak in the algorithm
negotiation. This allows man-in-the-middle attackers to target initial
connection attempts (where no host key for the server has been cached
by the client).

https://docs.ssh-mitm.at/CVE-2020-14145.html

This tool is able to exploit this vulnerability. At the moment, it only
checks, if a client is vulnerable, but implementing a full exploit is
not hard.

Dropbear was not affected by such a vulnerability, because they are
allwys sending the default algorithm list.

PuTTy has integrated an option to disable/enable preffered host key
algorithm order.


Mitigation:

Clients should always preffere the strongest ciphers per default. By
using HostKeyAlgorithms in your configuration file, you need to
maintain the list and add new algorithms in the right order. This is
error prone and most users do not have enough knowledge about pros and
cons of those algorithms.

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

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

m.kaiser at bmlv.gv.at changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://docs.ssh-mitm.at/CV
                   |                            |E-2020-14145.html

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |djm at mindrot.org
         Resolution|---                         |WONTFIX

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
First, we consider the automatic ordering of host key algorithms an
important feature for security. It provides continuity of trust by
clients across changes in default algorithm preference in ssh and
servers offering hostkeys of different types.

Disabling this feature wholesale would IMO result in a net *loss* of
security as it would force more connections that already have learned a
hostkey to accept a new one of a different algorithm, thereby
needlessly exposing them to MITM risk.

That being said, commit b3855ff (shipped in openssh-8.4) adjusted the
ordering to always use the default if the client has learned a hostkey
matching the best-preference algorithm. openssh-8.5 enabled
UpdateHostkeys by default (with some restrictions) so most users will
automatically learn a best-preference hostkey if one is available at
the server. Between these, most users should end up using the default
algorithm list.

Speaking for myself - I plan to relax the restrictions around
UpdateHostkeys' activation, but do not plan to take other action around
this "vulnerability". In particular, I do not intend to offer an
option
to force the use of the default cipher list. IMO too many users would
flip it thinking it solved a security problem when the situation is
actually far more subtle and the reverse is likely the case.

-- 
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=3313

--- Comment #2 from m.kaiser at bmlv.gv.at ---
Thanks for the answer. Now I understand the problem better.

Mitigation might be possible, but with the risk of a changing
fingerprint due to different preferred algorithms. For most users, this
might be more error prone and it's more likely that the users accepts a
wrong fingerprint.

So the only real mitigation is setting up a CA and using certificates,
or is this a wrong assumption?

The documentation is updated with your answer and the recommendation
how to mitigate this vulnerability was changed.

Sorry, that I have escalated this vulnerability.

-- 
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=3313

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
closing bugs resolved before 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.