systemd-resolved does not properly enforce any access control to its dbus methods, allowing any unprivileged user to access its API. An attacker may use this flaw to configure the DNS, the Default Route or other properties of a network link. Those operations should be performed only by an high-privileged user.
The DBus interface exposed by systemd-resolved provides APIs to change the DNS servers, search domains, default route, DNSSEC and other properties of a link. However everybody can access those methods, thus allowing unprivileged users to force the usage of a rogue DNS server, disable DNSSEC or change the default route address. This could be used to hijack network traffic, abuse DNS resolution to redirect to malicious servers or have other effects on network connections.
Function bus_open_system_watch_bind_with_description() defined in bus-util.c and used by systemd-resolved to connect to the system bus, calls the sd_bus_set_trusted(bus, true) method which marks all connections on the bus as trusted and access to all privileged and unprivileged methods is granted.
On Red Hat Enterprise Linux 8 the DBus method org.freedesktop.resolve1.SetLinkDefaultRoute is not implemented, thus it is not possible for an attacker to abuse this flaw to change the default route of a link.
Mitigation: Disable systemd-resolved service by using `sudo systemctl disable systemd-resolved`.
On Red Hat Enterprise Linux 8 systemd-resolved service is disabled by default so it is not possible to change any network link settings as an unprivileged user.
Statement: This issue does not affect the versions of systemd as shipped with Red Hat Enterprise Linux 7 as the shipped systemd-resolved does not provide any privileged DBus method. This issue does affect the versions of systemd as shipped with Red Hat Enterprise Linux 8, however the systemd-resolved service is not enabled by default, so the flaw cannot be exploited unless the service was manually enabled. The flaw was rated as Moderate as it requires a local attacker and changing the DNS servers cannot compromise the system by itself, though it could be used for phishing attacks or to redirect the users to malicious websites. Moreover, on Red Hat Enterprise Linux 8 systemd-resolved needs to be manually enabled by an administrator to make the system vulnerable. OpenShift Container Platform 4 includes a vulnerable version of systemd on RHEL CoreOS nodes. However, the systemd-resolved service is removed from RHEL CoreOS instances, making this vulnerability not exploitable. This flaw is rated Low for OpenShift Container Platform 4.
The complete upstream fix is at: https://github.com/systemd/systemd/pull/13457 However the following commit is enough to address the vulnerability: https://github.com/systemd/systemd/pull/13457/commits/35e528018f315798d3bffcb592b32a0d8f5162bd
Created systemd tracking bugs for this issue: Affects: fedora-all [bug 1748767]
oss-security thread: https://www.openwall.com/lists/oss-security/2019/09/03/1
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2019:3592 https://access.redhat.com/errata/RHSA-2019:3592
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-15718
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.1 Via RHSA-2019:3941 https://access.redhat.com/errata/RHSA-2019:3941