1902960 – QEMU doesn't honour system crypto policies

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 1902960 - QEMU doesn't honour system crypto policies

Summary: QEMU doesn't honour system crypto policies

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 8
Classification:	Red Hat
Component:	qemu-kvm
Sub Component:
Version:	8.4
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	high
Target Milestone:	rc
Target Release:	8.0
Assignee:	Danilo de Paula
QA Contact:	liunana
Docs Contact:	Jiri Herrmann
URL:
Whiteboard:
Depends On:	1902219
Blocks:	1934509
TreeView+	depends on / blocked

Reported:	2020-12-01 01:04 UTC by Danilo de Paula
Modified:	2021-05-18 15:24 UTC (History)
CC List:	11 users (show)
Fixed In Version:	qemu-kvm-4.2.0-46.module+el8.4.0+10218+7dabd3c0
Doc Type:	Bug Fix
Doc Text:	QEMU now uses the host's cryptographic policy settings Previously, the QEMU emulator always offered the TLS 1.0 and TLS 1.1 cryptographic protocols when negotiating a TLS session, and did not reflect RHEL cryptographic policy settings. With this update, QEMU upholds the cryptographic policy settings on the host, as determined by the local administrator. This makes it possible for QEMU to use stronger security policies, with only TLS 1.2 offered under the RHEL default policy. Note that if QEMU requires compatibility with legacy applications that use TLS 1.0 and TLS 1.1, you must adjust the host cryptographic policy accordingly. However, Red Hat recommends using such a setting only temporarily.
Clone Of:	1902219
Clones:	1934509 (view as bug list)
Environment:
Last Closed:	2021-05-18 15:22:56 UTC
Type:	Bug
Target Upstream Version:
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Description Danilo de Paula 2020-12-01 01:04:52 UTC

+++ This bug was initially created as a clone of Bug #1902219 +++

Description of problem:

Because the QEMU in RHEL-8 was derived from QEU in RHEL-7, rather than that in Fedora, it inherited the "--tls-priority=NORMAL" arg to configure.

This was used in RHEL-7, because that distro lacks the crypto policies concept.

In RHEL-8, however, it should have been built to use "--tls-priority=@QEMU,SYSTEM" as is done in Fedora.

This would make QEMU use the "@QEMU" crypto policy profile, and if that doesn't exist, then it would use the @SYSTEM crypto policy profile.

The upshot of using "NORMAL" is that QEMU is exposing the GNUTLS defaults which are undesirable because they still allow TLS-1.0 and TLS-1.1

The DEFAULT RHEL8 crypto policies only allow TLS-1.2

To illustrate create some certs for a server and then run:

  /usr/libexec/qemu-kvm -object tls-creds-x509,dir=/root,endpoint=server,id=tls0 -chardev socket,host=localhost,port=9000,tls-creds=tls0,id=char0,server,nowait

Now in another terminal

  wget  http://nmap.org/svn/scripts/ssl-enum-ciphers.nse
  nmap --script ssl-enum-ciphers -p9000 localhost 

In the results you will see TLS-1.0, 1.1 and 1.2.

If /etc/crypto-policies/config is set to DEFAULT, it should only report TLS 1.2

Version-Release number of selected component (if applicable):
qemu-kvm-4.2.0-19.module+el8.2.0+6296+6b821950.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Run QEMU with a chardev using TLS
2. Scan algorithms exposed by QEMU

Actual results:
Includes TLS 1.0 and 1.1

Expected results:
Should honour /etc/crypto-policies/config and only expose TLS_1.2 for "DEFAULT"

Additional info:

--- Additional comment from Daniel Berrangé on 2020-11-27 12:32:24 UTC ---

To help QE, here's a bit of further explanation about expected behaviour with:

  --tls-priority=@QEMU,SYSTEM

"SYSTEM" refers to the profile defined in /etc/crypto-policies/config, which is "DEFAULT" normally.

It is possible to create a  local override, eg to turn back on TLS-1.1

  # cat /etc/crypto-policies/local.d/gnutls-qemu.config
  QEMU=NONE:+MAC-ALL:-MD5:+GROUP-ALL:-GROUP-X25519:-GROUP-X448:+SIGN-ALL:-SIGN-RSA-MD5:-SIGN-RSA-SHA1:-SIGN-DSA-SHA1:-SIGN-ECDSA-SHA1:-SIGN-DSA-SHA224:-SIGN-DSA-SHA256:-SIGN-DSA-SHA384:-SIGN-DSA-SHA512:-SIGN-EDDSA-ED25519:-SIGN-EDDSA-ED448:+CIPHER-ALL:-CHACHA20-POLY1305:-CAMELLIA-256-GCM:-CAMELLIA-128-GCM:-CAMELLIA-256-CBC:-CAMELLIA-128-CBC:-3DES-CBC:-ARCFOUR-128:+ECDHE-RSA:+ECDHE-ECDSA:+DHE-RSA:+VERS-ALL:-VERS-DTLS0.9:+VERS-SSL3.0:-VERS-TLS1.0:+VERS-TLS1.1:-VERS-DTLS1.0:+COMP-NULL:%PROFILE_MEDIUM
  # update-crypto-policies

If QEMU is restarted, it will now honour this custom override and advertize TLS-1.1 and TLS-1.2, instead of the "SYSTEM" settings which only advertize TLS-1.2

Comment 2 Danilo de Paula 2021-02-04 02:57:13 UTC

QA_ACK, please?

Comment 4 liunana 2021-02-04 03:03:05 UTC

(In reply to Danilo Cesar Lemes de Paula from comment #2)
> QA_ACK, please?

done.

Comment 11 Danilo de Paula 2021-03-01 19:38:05 UTC

We lived without this for the whole RHEL-8 life cycle until now.

@berrange Do you think we have a case for exception+ to get it in 8.4?
I think we don't, but AV is making the move in 8.4 and we might want to be in sync with it....

What do you think?

Comment 21 liunana 2021-03-04 03:29:44 UTC

Test environments:
    dell-per740xd-07.lab.eng.pek2.redhat.com
    kernel-4.18.0-293.el8.x86_64
    qemu-kvm-4.2.0-46.module+el8.4.0+10218+7dabd3c0.x86_64

Test Three scenarios to verify this bug.


- - Scenario 1:
Test steps:

  1). Run QEMU with a chardev using TLS
#/usr/libexec/qemu-kvm -object tls-creds-x509,dir=/etc/pki/qemu/,endpoint=server,id=tls0 -chardev socket,host=localhost,port=9000,tls-creds=tls0,id=char0,server,nowait --monitor stdio

  2). Scan algorithms exposed by QEMU
# nmap --script ssl-enum-ciphers -p9000 localhost
Starting Nmap 7.70 ( https://nmap.org ) at 2021-03-03 21:56 EST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000082s latency).
Other addresses for localhost (not scanned): ::1

PORT     STATE SERVICE
9000/tcp open  cslistener
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CCM (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CCM (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 3072) - A
|       TLS_RSA_WITH_AES_128_CCM (rsa 3072) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 3072) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 3072) - A
|       TLS_RSA_WITH_AES_256_CCM (rsa 3072) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 3072) - A
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       Key exchange (dh 2048) of lower strength than certificate key
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 1.91 seconds


  3). Additonal info:
cat /etc/crypto-policies/config 
# This file should contain a single keyword, the crypto policy to
# be applied by default to applications. The available policies are 
# restricted to the following profiles.
#
# * LEGACY: Ensures maximum compatibility with legacy systems (64-bit
#   security).
#
# * DEFAULT: A reasonable default for today's standards (112-bit security).
#
# * FUTURE: A level that will provide security on a conservative level that is
#   believed to withstand any near-term future attacks (128-bit security).
#
# * FIPS: Policy that enables only FIPS 140-2 approved or allowed algorithms.
#
# After modifying this file, you need to run update-crypto-policies
# for the changes to propagate.
#
DEFAULT



- - Scenario 2
Steps:
  1). # echo LEGACY > /etc/crypto-policies/config

  2). # update-crypto-policies
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

  3). restart qemu and execute cmd 'nmap'.
# nmap --script ssl-enum-ciphers -p9000 localhost
Starting Nmap 7.70 ( https://nmap.org ) at 2021-03-03 22:04 EST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000078s latency).
Other addresses for localhost (not scanned): ::1

PORT     STATE SERVICE
9000/tcp open  cslistener
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 3072) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 3072) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 3072) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 3072) - C
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Key exchange (dh 2048) of lower strength than certificate key
|   TLSv1.1: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 3072) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 3072) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 3072) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 3072) - C
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Key exchange (dh 2048) of lower strength than certificate key
|   TLSv1.2: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CCM (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CCM (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 3072) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 3072) - A
|       TLS_RSA_WITH_AES_128_CCM (rsa 3072) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 3072) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 3072) - A
|       TLS_RSA_WITH_AES_256_CCM (rsa 3072) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 3072) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 3072) - C
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Key exchange (dh 2048) of lower strength than certificate key
|_  least strength: C

Nmap done: 1 IP address (1 host up) scanned in 5.00 seconds

  4). Additonal info:
# cat /etc/crypto-policies/config 
LEGACY



- - Scenario 3:
Steps:
  1). # cat /etc/crypto-policies/local.d/gnutls-qemu.config
QEMU=NONE:+MAC-ALL:-MD5:+GROUP-ALL:-GROUP-X25519:-GROUP-X448:+SIGN-ALL:-SIGN-RSA-MD5:-SIGN-RSA-SHA1:-SIGN-DSA-SHA1:-SIGN-ECDSA-SHA1:-SIGN-DSA-SHA224:-SIGN-DSA-SHA256:-SIGN-DSA-SHA384:-SIGN-DSA-SHA512:-SIGN-EDDSA-ED25519:-SIGN-EDDSA-ED448:+CIPHER-ALL:-CHACHA20-POLY1305:-CAMELLIA-256-GCM:-CAMELLIA-128-GCM:-CAMELLIA-256-CBC:-CAMELLIA-128-CBC:-3DES-CBC:-ARCFOUR-128:+ECDHE-RSA:+ECDHE-ECDSA:+DHE-RSA:+VERS-ALL:-VERS-DTLS0.9:+VERS-SSL3.0:-VERS-TLS1.0:+VERS-TLS1.1:-VERS-DTLS1.0:+COMP-NULL:%PROFILE_MEDIUM

  2). # update-crypto-policies
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

  3). restart qemu and execute cmd 'nmap'.
# nmap --script ssl-enum-ciphers -p9000 localhost
Starting Nmap 7.70 ( https://nmap.org ) at 2021-03-03 22:11 EST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000057s latency).
Other addresses for localhost (not scanned): ::1

PORT     STATE SERVICE
9000/tcp open  cslistener
| ssl-enum-ciphers: 
|   TLSv1.1: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       Key exchange (dh 2048) of lower strength than certificate key
|   TLSv1.2: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CCM (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CCM (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       Key exchange (dh 2048) of lower strength than certificate key
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 2.29 seconds


  4). Additional info:
# cat /etc/crypto-policies/config 
DEFAULT


Seems that one local custom QEMU policy in /etc/crypto-policies/local.d/gnutls-qemu.config is not effected by the config of "/etc/crypto-policies/config", I can get the right and same results with the config 'LEGACY' or 'DEFAULT', is this expected?


Besides, do we need to test the below policies which are in "/etc/crypto-policies/config"?
#
# * FUTURE: A level that will provide security on a conservative level that is
#   believed to withstand any near-term future attacks (128-bit security).
#
# * FIPS: Policy that enables only FIPS 140-2 approved or allowed algorithms.


If no necessary, can we move to verified according to the above tests?
Please help to check, thanks.


Best regards
Liu Nana

Comment 22 Richard W.M. Jones 2021-03-04 09:43:06 UTC

Scenario 2:

Some key features which show that the crypto policy has changed to "LEGACY":

(1) The RC4 cipher is enabled.  This is an infamously weak cipher, which is
enabled in the LEGACY policy (/usr/share/crypto-policies/policies/LEGACY.pol)
but not in the DEFAULT policy (/usr/share/crypto-policies/policies/DEFAULT.pol).

(2) The "Least strength" has changed from A to C, showing that weaker ciphers
are enabled.  These ratings come from:
https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide

Scenario 3:

This test is a bit tricky to follow.  I think what the test is trying to
show is that TLS 1.0 has been disabled (-VERS-TLS1.0) and TLS 1.1 has been
enabled (+VERS-TLS1.1).  The nmap output does seem to confirm that.

I wonder if there's a simpler/clearer way to demonstrate Scenario 3.

Comment 23 Daniel Berrangé 2021-03-04 10:16:03 UTC

(In reply to Richard W.M. Jones from comment #22)
> Scenario 2:
> 
> Some key features which show that the crypto policy has changed to "LEGACY":
> 
> (1) The RC4 cipher is enabled.  This is an infamously weak cipher, which is
> enabled in the LEGACY policy (/usr/share/crypto-policies/policies/LEGACY.pol)
> but not in the DEFAULT policy
> (/usr/share/crypto-policies/policies/DEFAULT.pol).
> 
> (2) The "Least strength" has changed from A to C, showing that weaker ciphers
> are enabled.  These ratings come from:
> https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide
> 
> Scenario 3:
> 
> This test is a bit tricky to follow.  I think what the test is trying to
> show is that TLS 1.0 has been disabled (-VERS-TLS1.0) and TLS 1.1 has been
> enabled (+VERS-TLS1.1).  The nmap output does seem to confirm that.

Yes, that is working, as we see TLS 1.0 gone.

Comment 24 liunana 2021-03-05 02:54:42 UTC

Hi Daniel,


Could you please help to check the questions in the last of comment 21?
If no more tests and issues, we can move this bz to VERIFIED.
Thanks.



Best regards
Liu Nana

Comment 25 Daniel Berrangé 2021-03-08 11:48:30 UTC

It looks good to me.

Comment 26 liunana 2021-03-08 11:53:46 UTC

(In reply to Daniel Berrangé from comment #25)
> It looks good to me.

Thanks, move to verified according to comment 21 and comment 25.

Comment 28 errata-xmlrpc 2021-05-18 15:22:56 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 (Moderate: virt:rhel and virt-devel:rhel security, 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/RHSA-2021:1762

Note You need to log in before you can comment on or make changes to this bug.