Bug 1776762 (CVE-2019-18934) - CVE-2019-18934 unbound: command injection with data coming from a specially crafted IPSECKEY answer
Summary: CVE-2019-18934 unbound: command injection with data coming from a specially c...
Alias: CVE-2019-18934
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1772061 1776763 1781169
Blocks: 1776764
TreeView+ depends on / blocked
Reported: 2019-11-26 10:40 UTC by Marian Rehak
Modified: 2021-02-16 20:59 UTC (History)
4 users (show)

Fixed In Version: unbound 1.9.5
Doc Type: If docs needed, set a value
Doc Text:
A shell command injection vulnerability was discovered in the way unbound handles DNS queries for systems with a public key used for IPsec. When ipsecmod is enabled, a malicious DNS server could send a DNS reply which would be used during a following DNS query to execute shell commands with the privileges of the unbound process. The same attack could be performed by an attacker who can modify data transmitted over the network, before it reaches the unbound server, if DNSSEC is not used.
Clone Of:
Last Closed: 2020-04-28 16:34:58 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:1716 0 None None None 2020-04-28 15:44:07 UTC

Description Marian Rehak 2019-11-26 10:40:25 UTC
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.

Comment 1 Marian Rehak 2019-11-26 10:40:41 UTC
Created unbound tracking bugs for this issue:

Affects: fedora-all [bug 1776763]

Comment 6 Riccardo Schirone 2019-12-06 16:36:24 UTC
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.

Comment 7 Riccardo Schirone 2019-12-06 16:42:25 UTC
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.

Comment 8 Riccardo Schirone 2019-12-06 16:49:54 UTC
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.

Comment 9 Riccardo Schirone 2019-12-06 17:00:43 UTC
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.

Comment 16 Riccardo Schirone 2019-12-09 13:26:20 UTC
According to upstream, this flaw affects upstream version of Unbound from 1.6.4 up to and including 1.9.4.

Comment 17 Eric Christensen 2019-12-09 21:12:19 UTC

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.

Comment 18 Eric Christensen 2019-12-09 21:12:21 UTC

* 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.

Comment 19 errata-xmlrpc 2020-04-28 15:44:06 UTC
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

Comment 20 Product Security DevOps Team 2020-04-28 16:34:58 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


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