RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1724195 - manpages mix crypto-policy defaults and hardcoded defaults, prompting dangerous misconfiguration
Summary: manpages mix crypto-policy defaults and hardcoded defaults, prompting dangero...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: openssh
Version: 8.1
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: rc
: 8.0
Assignee: Jakub Jelen
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-26 12:49 UTC by Alexander Sosedkin
Modified: 2020-11-04 01:33 UTC (History)
4 users (show)

Fixed In Version: openssh-8.0p1-5.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-04 01:31:59 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:4439 0 None None None 2020-11-04 01:32:19 UTC

Description Alexander Sosedkin 2019-06-26 12:49:26 UTC 
Description of problem:

TL;DR: overloading the term 'defaults' in the manpage can lead to
       dangerous misconfiguration that ignores crypto-policies.

Extract from the ssh_config manpage:
    Ciphers
        Specifies the ciphers allowed and their order of preference.
        Multiple ciphers must be comma-separated. 
        If the specified value begins with a ‘+’ character,
        then the specified ciphers will be appended to the default set
        instead of replacing them.
        If the specified value begins with a ‘-’ character,
        then the specified ciphers (including wildcards)
        will be removed from the default set instead of replacing them.

Here, the 'default set' refers so some list that is hard-coded inside openssh,
and not to what was set from the previously encountered directives from, e.g.,
configuration files.

This may, by itself, be a source of confusion, but it becomes outright dangerous
once crypto-policies come into play. From the same subsection:

        The default is handled system-wide by crypto-policies(7).
        To see the defaults and how to modifuy this default,
        see manual page update-crypto-policies(8).

If the user had any doubts by now, this would wrongfully clear them.
We explicitly state that the 'default' comes from crypto-policies.
But, in fact, it does not.
Crypto-policies configure the default behaviour by including a file
that does use the same Ciphers directive.
Any subsequent usage of the same directive invalidate the previous ones,
and that includes the '+-' varieties, which build off the hardcoded list.

The most glaring problem, in my opinion, lies in the fact that we explicitly
assure the user in the contrary.


Version-Release number of selected component (if applicable):

8.0p1-2


How reproducible:

N/A


Steps to Reproduce:

1. Read `man ssh_config` or `man sshd_config` on a system with crypto-policies.
2. Get the idea that '+-' modificators modify the actual default behaviour.
3. Use any of the '+-' modificators, for example,
   make an attempt at hardening the default configuration by excluding a cipher.


Actual results:

# update-crypto-policies --set FUTURE

$ ssh -G - | grep cipher
ciphers aes256-gcm,chacha20-poly1305,aes256-ctr,aes256-cbc

$ ssh -G - -o Ciphers=-aes256-cbc | grep cipher
ciphers chacha20-poly1305,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes256-gcm

Note how a misguided attempt at hardening the system by disabling a cipher
actually weakened it by enabling some other unrelated ones.


Expected results:

The algorithm list shrinks (or expands) accordingly.
Excluding one prevents its usage and hardens the system; including one allows it.
Other than that, no unrelated changes happen,
and the remaining algorithm list and their priorities
are otherwise still dictated by the currently active crypto-policy.


Additional info:

The problem is not specific to one particular option, be sure to update them all.

There's little hope in changing the behaviour of '+-', upstream or downstream,
but we should, at the very least, rework the documentation
to reflect the fact that any modification, including the seemingly minor '+-' one,
completely disregards the current crypto-policy with respect to that algorithm.
Comment 1 Jakub Jelen 2019-08-28 14:02:42 UTC 
I would be happy to improve the wording in the manual pages to be more clear. This was written as initial wording in the bug #1668325 [1] and nobody had any comments there (aside of fixing one typo).

What do you think about something like this for server:

> The values specified in configuration files will be overwritten by system-wide crypto-policies(7). To see the crypto policies defaults and how to modify them, see manual page update-crypto-policies(8).

And for clients:

> The values for this configuration option are provided by system-wide crypto-policies(7) by including a external configuration file in system-wide ssh_config. To see the crypto policies defaults and how to modify them, see manual page update-crypto-policies(8).

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1668325#c3
Comment 2 Alexander Sosedkin 2019-08-29 08:26:20 UTC 
I think that our options are either

* disable +- functionality altogether and only allow modifications through crypto-policies,
* describe the actual thing that happens when it is used (wrong defaults being modified) or
* outright declare this to be undefined behaviour loud and clear.

Just slightly nudging the users towards crypto-policies doesn't really solve the problem.
Comment 3 Jakub Jelen 2019-08-29 11:05:13 UTC 
(In reply to Alexander Sosedkin from comment #2)
> I think that our options are either
> 
> * disable +- functionality altogether and only allow modifications through
> crypto-policies,

We do not want to modify openssh functionality this drastically.

> * describe the actual thing that happens when it is used (wrong defaults
> being modified) or

The new proposed wording does not contain the only the ambiguous word "defaults", but "crypto policies defaults", which makes it clear that we do not talk about the "openssh defaults". I do not think that describing every corner case and combination of corner cases is right fit for the manual pages. The reader should be able to add one and one.

> * outright declare this to be undefined behaviour loud and clear.

The behavior is valid and clearly defined by the manual page and can be used for many use cases when overwriting crypto policies.
Comment 4 Alexander Sosedkin 2019-08-29 11:32:58 UTC 
(summary of in-person discussion:)

We don't want to change behaviour in any way.

We cannot leave this behaviour undocumented and unsupported.

It'd be nice to make the situation clear to the user who just skims to the '+-' part, but this is optional.

We want to present crypto-policies configuration as 'defaults' (as they, effectively, are defaults) to the user.

We'd also strongly prefer not to touch the upstream documentation paragraph,
but, as it talks about 'defaults' that effectively aren't defaults, it seems unavoidable.


The best course of action for now is probably:

1) Put the 'defaults are governed by crypto-policies' paragraph higher to increase its visibility.

2) In the '+-' description, somehow clarify that it modifies the upstream defaults and not the crypto-policies defaults.
   It's unclear to me whether any of 'OpenSSH defaults', 'built-in defaults', 'compiled defaults' or 'upstream defaults'
   serves this role better than the others for the users who, I assume, don't draw the upstream/downstream distinction.
Comment 11 Ondrej Moriš 2020-04-01 18:34:31 UTC 
Successfully verified.

OLD (openssh-8.0p1-4.el8_1) vs NEW (openssh-8.0p1-5.el8)
========================================================

OLD: Ciphers
             Specifies the ciphers allowed and their order of preference.  Multiple
             ciphers must be comma-separated.  If the specified value begins with a
             ‘+’ character, then the specified ciphers will be appended to the
             default set instead of replacing them.  If the specified value begins
             with a ‘-’ character, then the specified ciphers (including wildcards)
             will be removed from the default set instead of replacing them.

             The supported ciphers are:

                   3des-cbc
                   aes128-cbc
                   aes192-cbc
                   aes256-cbc
                   aes128-ctr
                   aes192-ctr
                   aes256-ctr
                   aes128-gcm
                   aes256-gcm
                   chacha20-poly1305

             The default is handled system-wide by crypto-policies(7).  To see the
             defaults and how to modify this default, see manual page
             update-crypto-policies(8).

             The list of available ciphers may also be obtained using "ssh -Q
             cipher".

NEW: Ciphers
             The default is handled system-wide by crypto-policies(7).  To see the
             current defaults and how to modify them, see manual page
             update-crypto-policies(8).

             Specifies the ciphers allowed and their order of preference.  Multiple
             ciphers must be comma-separated.  If the specified value begins with a
             ‘+’ character, then the specified ciphers will be appended to the
             built-in default set instead of replacing them.  If the specified value
             begins with a ‘-’ character, then the specified ciphers (including
             wildcards) will be removed from the built-in default set instead of
             replacing them.

             The supported ciphers are:

                   3des-cbc
                   aes128-cbc
                   aes192-cbc
                   aes256-cbc
                   aes128-ctr
                   aes192-ctr
                   aes256-ctr
                   aes128-gcm
                   aes256-gcm
                   chacha20-poly1305

             The list of available ciphers may also be obtained using "ssh -Q
             cipher".

---

OLD: MACs    Specifies the MAC (message authentication code) algorithms in order of
             preference.  The MAC algorithm is used for data integrity protection.
             Multiple algorithms must be comma-separated.  If the specified value
             begins with a ‘+’ character, then the specified algorithms will be
             appended to the default set instead of replacing them.  If the speci‐
             fied value begins with a ‘-’ character, then the specified algorithms
             (including wildcards) will be removed from the default set instead of
             replacing them.

             The algorithms that contain "-etm" calculate the MAC after encryption
             (encrypt-then-mac).  These are considered safer and their use recom‐
             mended.

             The default is handled system-wide by crypto-policies(7).  To see the
             defaults and how to modify this default, see manual page
             update-crypto-policies(8).

             The list of available MAC algorithms may also be obtained using "ssh -Q
             mac".

NEW: MACs    The default is handled system-wide by crypto-policies(7).  To see the
             current defaults and how to modify them, see manual page
             update-crypto-policies(8).

             Specifies the MAC (message authentication code) algorithms in order of
             preference.  The MAC algorithm is used for data integrity protection.
             Multiple algorithms must be comma-separated.  If the specified value
             begins with a ‘+’ character, then the specified algorithms will be
             appended to the built-in default set instead of replacing them.  If the
             specified value begins with a ‘-’ character, then the specified algo‐
             rithms (including wildcards) will be removed from the built-in default
             set instead of replacing them.

             The algorithms that contain "-etm" calculate the MAC after encryption
             (encrypt-then-mac).  These are considered safer and their use recom‐
             mended.

---
q
OLD: GSSAPIKexAlgorithms
             The list of key exchange algorithms that are offered for GSSAPI key
             exchange. Possible values are

                gss-gex-sha1-,
                gss-group1-sha1-,
                gss-group14-sha1-,
                gss-group14-sha256-,
                gss-group16-sha512-,
                gss-nistp256-sha256-,
                gss-curve25519-sha256-

             The default is handled system-wide by crypto-policies(7).  To see the
             defaults and how to modify this default, see manual page
             update-crypto-policies(8).  This option only applies to protocol ver‐
             sion 2 connections using GSSAPI.


NEW: GSSAPIKexAlgorithms
             The default is handled system-wide by crypto-policies(7).  To see the
             current defaults and how to modify them, see manual page
             update-crypto-policies(8).

             The list of key exchange algorithms that are offered for GSSAPI key
             exchange. Possible values are

                gss-gex-sha1-
                gss-group1-sha1-
                gss-group14-sha1-
                gss-group14-sha256-
                gss-group16-sha512-
                gss-nistp256-sha256-
                gss-curve25519-sha256-

             This option only applies to connections using GSSAPI.

---

OLD: KexAlgorithms
             Specifies the available KEX (Key Exchange) algorithms.  Multiple algo‐
             rithms must be comma-separated.  Alternately if the specified value
             begins with a ‘+’ character, then the specified methods will be
             appended to the default set instead of replacing them.  If the speci‐
             fied value begins with a ‘-’ character, then the specified methods
             (including wildcards) will be removed from the default set instead of
             replacing them.  The default is handled system-wide by
             crypto-policies(7).  To see the defaults and how to modify this
             default, see manual page update-crypto-policies(8).

             The list of available key exchange algorithms may also be obtained
             using "ssh -Q kex".

NEW: KexAlgorithms
             The default is handled system-wide by crypto-policies(7).  To see the
             current defaults and how to modify them, see manual page
             update-crypto-policies(8).

             Specifies the available KEX (Key Exchange) algorithms.  Multiple algo‐
             rithms must be comma-separated.  Alternately if the specified value
             begins with a ‘+’ character, then the specified methods will be
             appended to the built-in default set instead of replacing them.  If the
             specified value begins with a ‘-’ character, then the specified methods
             (including wildcards) will be removed from the built-in default set
             instead of replacing them.

             The list of available key exchange algorithms may also be obtained
             using "ssh -Q kex".

---

OLD: PubkeyAcceptedKeyTypes
             Specifies the key types that will be used for public key authentication
             as a comma-separated list of patterns.  Alternately if the specified
             value begins with a ‘+’ character, then the key types after it will be
             appended to the default instead of replacing it.  If the specified
             value begins with a ‘-’ character, then the specified key types
             (including wildcards) will be removed from the default set instead of
             replacing them.  The default is handled system-wide by
             crypto-policies(7).  To see the defaults and how to modify this
             default, see manual page update-crypto-policies(8).

             The list of available key types may also be obtained using "ssh -Q
             key".


NEW: PubkeyAcceptedKeyTypes
             The default is handled system-wide by crypto-policies(7).  To see the
             current defaults and how to modify them, see manual page
             update-crypto-policies(8).

             Specifies the key types that will be used for public key authentication
             as a comma-separated list of patterns.  Alternately if the specified
             value begins with a ‘+’ character, then the key types after it will be
             appended to the built-in default instead of replacing it.  If the spec‐
             ified value begins with a ‘-’ character, then the specified key types
             (including wildcards) will be removed from the built-in default set
             instead of replacing them.

             The list of available key types may also be obtained using "ssh -Q
             key".

---

OLD: CASignatureAlgorithms
             Specifies which algorithms are allowed for signing of certificates by
             certificate authorities (CAs).  The default is:

                   ecdsa-sha2-nistp256.ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
                   ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

             ssh(1) will not accept host certificates signed using algorithms other
             than those specified.

NEW: CASignatureAlgorithms
             The default is handled system-wide by crypto-policies(7).  To see the
             current defaults and how to modify them, see manual page
             update-crypto-policies(8).

             Specifies which algorithms are allowed for signing of certificates by
             certificate authorities (CAs).  ssh(1) will not accept host certifi‐
             cates signed using algorithms other than those specified.
Comment 13 Noah Friedman 2020-10-08 22:59:40 UTC 
I still think this change to the man page is clear as mud.  Even if you understand what it says it's not immediately obvious that the system crypto policy does not hold any special place and that the same behavior will apply to any prior settings, even your own.

I think a clear, concise paragaph that need not even mention the crypto policy (since the same behavior applies to everything else):



You cannot modify previous configuration directives, only replace them.  The +/-/^ operators only work on the compiled-in defaults, so if you use them you are replacing any previous configuration with an edit of the builtin values"
Comment 15 errata-xmlrpc 2020-11-04 01:31:59 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (openssh bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4439
Note You need to log in before you can comment on or make changes to this bug.