Bug 1771725 (CVE-2018-21029) - CVE-2018-21029 systemd: incorrect certificate validation results in acceptance of any certificate signed by a trusted certificate authority for DNS over TLS
Summary: CVE-2018-21029 systemd: incorrect certificate validation results in acceptanc...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2018-21029
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1771726 1776995
Blocks: 1771728
TreeView+ depends on / blocked
 
Reported: 2019-11-12 20:25 UTC by Guilherme de Almeida Suckevicz
Modified: 2021-10-25 22:11 UTC (History)
15 users (show)

Fixed In Version: systemd 244
Doc Type: If docs needed, set a value
Doc Text:
A flaw in systemd-resolved was found to incorrectly verify certificates of a DNS resolver used for DNS Over TLS when the DNSOverTLS option is set to `yes`. A remote attacker in the network path between the vulnerable system and the DNS resolver may use this flaw to perform a man-in-the-middle attack and eavesdrop or modify DNS queries and responses. The attacker can learn the sites visited by a victim user, or redirect the victim user to malicious sites.
Clone Of:
Environment:
Last Closed: 2021-10-25 22:11:15 UTC
Embargoed:


Attachments (Terms of Use)

Description Guilherme de Almeida Suckevicz 2019-11-12 20:25:46 UTC
systemd 239 through 243 accepts any certificate signed by a trusted certificate authority for DNS Over TLS. Server Name Indication (SNI) is not sent, and there is no hostname validation with the GnuTLS backend.

Reference:
https://github.com/systemd/systemd/issues/9397

Comment 1 Guilherme de Almeida Suckevicz 2019-11-12 20:26:00 UTC
Created systemd tracking bugs for this issue:

Affects: fedora-all [bug 1771726]

Comment 2 Riccardo Schirone 2019-11-14 09:07:48 UTC
Since version 239, systemd supports DNSOverTLS, however from v239 to v242 only `opportunistic` mode is implemented and the man page resolved.conf explicitly explain the limitation of the implementation, by saying `Note as the resolver is not capable of authenticating the server, it is vulnerable for "man-in-the-middle" attacks.` [1]. Moreover, according to RFC 7858, section 4.1 [2], the opportunistic privacy profile could be implemented in such a way to let the client validate the server or not. The latter option is used by systemd.

[1] https://www.freedesktop.org/software/systemd/man/resolved.conf.html#DNSOverTLS=
[2] https://tools.ietf.org/html/rfc7858#section-4.1

Comment 3 Riccardo Schirone 2019-11-14 09:11:14 UTC
In systemd v243 the "strict" profile has been implemented, where no DNS queries can be done in clear text by the resolver. In this version, the server certificate is incorrectly checked, because any certificate signed by a trusted certificate authority is accepted by systemd-resolved.

Comment 4 Riccardo Schirone 2019-11-14 09:11:45 UTC
Upstream patch:
https://github.com/systemd/systemd/commit/b7a4129ca946ed49e161a03283faf5bbab96d110

Comment 5 Riccardo Schirone 2019-11-14 09:39:28 UTC
A remote attacker may use this flaw to eavesdrop or modify DNS queries performed by systemd-resolved to a DNS server over TLS. DNS Over TLS should ensure that the DNS replies are confidential and they are coming from the expected server. However, in systemd v243 function dnstls_stream_connect_tls() in src/resolve/resolved-dnstls-gnutls.c does not correctly validate the server certificate and it accepts any certificate signed by a trusted Certificate Authority, even if not valid for the resolver hostname or IP address. The attacker could exploit this by performing a man-in-the-middle attack.

Comment 6 Riccardo Schirone 2019-11-14 09:54:16 UTC
The version of systemd as shipped in RHEL 8 is compiled with gnutls support and it supports DNSOverTLS option in the resolved.conf file. However, the only accepted values are `no` and `opportunistic`, so it can only provide privacy at best, as the opportunistic mode could fall back to clear text DNS queries/replies in case of issues with the secure communication. Moreover, as explained in comment 2, in opportunistic mode the client is not required to validate the resolver, which is not done at all and is documented as well.

Comment 8 Sam Fowler 2019-11-15 02:14:05 UTC
Statement:

Versions of systemd as shipped with Red Hat Enterprise Linux 7 are not affected by this issue as they did not include support for DNSOverTLS option.
Versions of systemd as shipped with Red Hat Enterprise Linux 8 are not affected by this issue as they did not support the `yes` value of the DNSOverTLS option.

OpenShift Container Platform 4.1 ships a version of systemd from Red Hat Enterprise Linux 8 and is thus also not affected by this issue.

Comment 9 Zbigniew Jędrzejewski-Szmek 2019-11-18 16:59:58 UTC
(In reply to Riccardo Schirone from comment #2)
> Since version 239, systemd supports DNSOverTLS, however from v239 to v242
> only `opportunistic` mode is implemented and the man page resolved.conf
> explicitly explain the limitation of the implementation, by saying `Note as
> the resolver is not capable of authenticating the server, it is vulnerable
> for "man-in-the-middle" attacks.` [1]. Moreover, according to RFC 7858,
> section 4.1 [2], the opportunistic privacy profile could be implemented in
> such a way to let the client validate the server or not. The latter option
> is used by systemd.
(In reply to Riccardo Schirone from comment #3)
> In systemd v243 the "strict" profile has been implemented, where no DNS
> queries can be done in clear text by the resolver. In this version, the
> server certificate is incorrectly checked, because any certificate signed by
> a trusted certificate authority is accepted by systemd-resolved.

That description is accurate.


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