Bug 1902960

Summary: QEMU doesn't honour system crypto policies
Product: Red Hat Enterprise Linux 8 Reporter: Danilo de Paula <ddepaula>
Component: qemu-kvmAssignee: Danilo de Paula <ddepaula>
qemu-kvm sub component: General QA Contact: liunana <nanliu>
Status: CLOSED ERRATA Docs Contact: Jiri Herrmann <jherrman>
Severity: high    
Priority: unspecified CC: berrange, chayang, ddepaula, jen, jherrman, jinzhao, juzhang, lmiksik, nanliu, rjones, virt-maint
Version: 8.4Keywords: Triaged
Target Milestone: rc   
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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.
 Story Points: ---
Clone Of: 1902219
: 1934509 (view as bug list) Environment:
Last Closed: 2021-05-18 15:22:56 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: 1902219    
Bug Blocks: 1934509    

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