A vulnerability was found that can cause shell code execution after receiving a specially crafted answer. This issuecan only be triggered if unbound was compiled with `--enable-ipsecmod`support, and ipsecmod is enabled and used in the configuration.
Created unbound tracking bugs for this issue: Affects: fedora-all [bug 1776763]
Upstream fix: https://github.com/NLnetLabs/unbound/commit/34e52a4313d59b9d57e928c44300fd81e1a48910
External References: https://nlnetlabs.nl/downloads/unbound/CVE-2019-18934.txt https://www.nlnetlabs.nl/news/2019/Nov/19/unbound-1.9.5-released/
Command injection is possible when a DNS request is performed for a name with an IPSECKEY record associated. The "DNS Gateway" field of an IPSECKEY DNS answer is not properly sanitized and it is used as an argument to the command specified by the ipsecmod-hook option, in the unbound.conf configuration file, which is executed with a system() call. This makes it possible to inject shell commands that are executed from the unbound process.
Several conditions are necessary to be affected by this flaw: - unbound is compiled with `--enable-ipsecmod` - ipsecmod module is listed in the `module-config` option of the unbound configuration file - ipsecmod is enabled in the configuration file (with `ipsecmod-enabled: yes`) or through the unbound-control (when enabled through the `control-enable: yes` option, it is indeed possible to change the ipsecmod-enabled option while the unbound service is running) - a domain is part of the ipsecmod-whitelist (when ipsecmod-whitelist is not specified, all domains are whitelisted) - a A/AAAA query is received for a domain that has an A/AAAA record(s) and an IPSECKEY record(s) available.
The version of unbound shipped with Red Hat Enterprise Linux 8 is compiled with `--enabled-ipsecmod` and, although ipsecmod is not enabled in the configuration file (`ipsecmod-enabled: no` in /etc/unbound/unbound.conf), it is possible for unbound-control to change the setting while the unbound service is running. However only an high-privilege user can change the options through unbound-control. If the system runs with SELinux in Enforcing mode, it is not possible for unbound to use the system() function, thus preventing this flaw from being exploited.
Due to the `username` option in the unbound configuration file, it is possible to make the service drop privileges after high-privilege operations are performed. By default, RHEL 7 and RHEL 8 provide a configuration file which sets `username: unbound`, making the service drop privileges to the `unbound` user/group. In case this flaw is abused, the attacker will only be able to execute shell commands with the privileges of the unbound user/group, which has access to just few files in the system.
According to upstream, this flaw affects upstream version of Unbound from 1.6.4 up to and including 1.9.4.
Statement: The versions of unbound as shipped in Red Hat Enterprise Linux 7 and 8 have `ipsecmod` disabled by default, even though it could be activated through the unbound-control command, it would only be executable by high-privilege users. Moreover, the `username` option is enabled, reducing the impact of a successful attack, and DNSSEC is used by default, preventing an attacker from modifying DNS packets on the wire. Finally, the default SELinux policies prevent unbound from running any shell command.
Mitigation: * Do not enable ipsecmod in the unbound.conf configuration file nor via unbound-control, if DNSSEC based Opportunistic IPsec is not used. * Use the `username` option in unbound.conf to make unbound drop privileges and reduce the impact of a successful attack. * Enable SELinux to prevent unbound from executing shell commands, apart from the expected one specified in the `ipsecmod-hook` option.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:1716 https://access.redhat.com/errata/RHSA-2020:1716
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-18934