Bug 1712436

Summary:	MD5 is used when writing password protected PEM
Product:	Red Hat Enterprise Linux 8	Reporter:	Ondrej Moriš <omoris>
Component:	openssh	Assignee:	Jakub Jelen <jjelen>
Status:	CLOSED ERRATA	QA Contact:	Ondrej Moriš <omoris>
Severity:	medium	Docs Contact:
Priority:	high
Version:	8.0	CC:	ansasaki, rrelyea, szidek, tmraz
Target Milestone:	rc	Flags:	jjelen: mirror+
Target Release:	8.1
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	openssh-8.0p1-1.el8	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1713256 (view as bug list)		Environment:
Last Closed:	2019-11-05 22:41:32 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:
Bug Depends On:
Bug Blocks:	1713256

Description Ondrej Moriš 2019-05-21 14:04:19 UTC

Description of problem:

When ssh-keygen is used to generate key in PEM format protected by password, the following error is produced in FIPS mode:

# fips-mode-setup --check
FIPS mode is enabled.

# ssh-keygen -t rsa-sha2-256 -m PEM -f id_test -N "fo0m4nchU"
Generating public/private rsa-sha2-256 key pair.
Saving key "id_test" failed: error in libcrypto

It seems to fail on "if (!EVP_BytesToKey(enc, EVP_md5(), iv, kstr, klen, 1, key, NULL))" probably because of EVP_md5().

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

openssl-1.1.1-8.el8
openssh-7.8p1-4.el8

How reproducible:

Always when FIPS mode is enabled.
Never when FIPS mode is disabled.

Steps to Reproduce:

1. See above.

Actual results:

See above.

Expected results:

Password protected PEM file is created successfully.

Additional info:

This issues happens in FIPS only.

Comment 1 Tomas Mraz 2019-05-22 13:16:13 UTC

This cannot be fixed on the openssl side. The use of MD-5 for this file format is hardcoded. The modern RSA ENCRYPTED KEY format needs to be used in openssh ssh-keygen instead.

Comment 2 Jakub Jelen 2019-05-22 13:25:07 UTC

Tomas, you mean that in FIPS mode, the PEM format should not be used at all and Ondrej should use the default OpenSSH format? In that case, we can

1) Modify OpenSSH ssh-keygen not to allow PEM key generation in FIPS
2) Document this, since this is certainly a change from RHEL7.

Comment 3 Tomas Mraz 2019-05-22 14:06:56 UTC

OpenSSH should use PEM_write_bio_PrivateKey() function to write the RSA key when the PEM format is requested. Regardless of the FIPS mode.

Comment 5 Jakub Jelen 2019-05-23 09:26:19 UTC

Do I understand this right that reading of the old PEM files will break in FIPS mode completely? The libssh testsuite have several of them embedded in the testsuite and I do not seem to be able to read them in FIPS mode at all with the following errors:

[2019/05/23 11:17:55.434672, 2] ssh_pki_import_privkey_base64:  Trying to decode privkey passphrase=true
[2019/05/23 11:17:55.434700, 1] pki_private_key_from_base64:  Parsing private key: error:060800C8:digital envelope routines:EVP_DigestInit_ex:disabled for FIPS

I think this is expected, but we will need something to do with the libssh testsuite, which heavily depends on them. But lets follow this discussion in upstream/libssh bug.

Comment 6 Ondrej Moriš 2019-05-23 09:54:01 UTC

Yes, that is correct - in FIPS you cannot read PEM files previously generated (in non-FIPS mode).

Comment 11 Jakub Jelen 2019-07-23 07:40:33 UTC

FYI, based on the Fedora bug #1722285 and the progress in the upstream bug [1], I propose to adapt the upstream version of this patch, which allows to generate both legacy PEM files, the new PKCS8 format.

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=3013

Comment 12 Tomas Mraz 2019-07-23 08:12:14 UTC

Unless you modify the upstream patch to always output PKCS8 in FIPS mode, this new patch will not solve this bug. It will just provide a workaround.

Comment 23 errata-xmlrpc 2019-11-05 22:41:32 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, 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/RHSA-2019:3702