Bug 1771725 (CVE-2018-21029)
| Summary: | CVE-2018-21029 systemd: incorrect certificate validation results in acceptance of any certificate signed by a trusted certificate authority for DNS over TLS | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Guilherme de Almeida Suckevicz <gsuckevi> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | bdettelb, bmontgom, eparis, jburrell, jokerman, lnykryn, lpoetter, msekleta, nstielau, sponnaga, s, systemd-maint-list, systemd-maint, zbyszek, zjedrzej |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-10-25 22:11:15 UTC | Type: | --- |
| 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: | 1771726, 1776995 | ||
| Bug Blocks: | 1771728 | ||
|
Description
Guilherme de Almeida Suckevicz
2019-11-12 20:25:46 UTC
Created systemd tracking bugs for this issue: Affects: fedora-all [bug 1771726] 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 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. 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. 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. 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. (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. |