Bug 1724195
| Summary: | manpages mix crypto-policy defaults and hardcoded defaults, prompting dangerous misconfiguration | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Alexander Sosedkin <asosedki> |
| Component: | openssh | Assignee: | Jakub Jelen <jjelen> |
| Status: | CLOSED ERRATA | QA Contact: | Ondrej Moriš <omoris> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | low | ||
| Version: | 8.1 | CC: | noah+fedoraproject, omoris, szidek, tmraz |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | openssh-8.0p1-5.el8 | Doc Type: | No Doc Update |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-04 01:31:59 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 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. (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. (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. 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.
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" 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 |
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.