Bug 2264183 (CVE-2024-1488)

Summary: CVE-2024-1488 unbound: unrestricted reconfiguration enabled to anyone that may lead to local privilege escalation
Product: [Other] Security Response Reporter: TEJ RATHI <trathi>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: pemensik, sbroz
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: unbound 1.19.1-2.fc40 Doc Type: If docs needed, set a value
Doc Text:
A vulnerability was found in Unbound due to incorrect default permissions, allowing any process outside the unbound group to modify the unbound runtime configuration. If a process can connect over localhost to port 8953, it can alter the configuration of unbound.service. This flaw allows an unprivileged attacker to manipulate a running instance, potentially altering forwarders, allowing them to track all queries forwarded by the local resolver, and, in some cases, disrupting resolving altogether.
Story Points: ---
Clone Of: Environment:
Last Closed: 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: 2264184    
Bug Blocks: 2264186    

Description TEJ RATHI 2024-02-14 12:41:40 UTC
unbound allows by default not only members of unbound group to change any unbound runtime configuration, but any process able to connect over localhost to port 8953, can change configuration of unbound.service. Unbound is somehow powerful in what can be changed runtime. Different forwarders can be set, allowing unprivileged process to track all queries forwarder by local resolver and of course it can be configured in a way it stops resolving completely.

Introduced by commit 
https://src.fedoraproject.org/rpms/unbound/c/39b47dbaf1ebe59e71a0e4269a6bb62d3126ba7d
https://src.fedoraproject.org/rpms/unbound/c/2cd0b94125f7cd88cdb777a8f546f3480bbd750a

Comment 1 TEJ RATHI 2024-02-14 12:47:26 UTC
Created unbound tracking bugs for this issue:

Affects: fedora-all [bug 2264184]

Comment 8 errata-xmlrpc 2024-04-10 09:58:17 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2024:1750 https://access.redhat.com/errata/RHSA-2024:1750

Comment 9 Petr Menšík 2024-04-10 11:24:42 UTC
This vulnerability were caused by not correctly updated configuration file initial value. The core problem were presence of remote-control: section option control-use-cert: "no". That has caused unbound to not require certificate on localhost control interface. Default value of control-interface is to use ipv4 and ipv6 localhost addresses, unless specified explicitly. Without using certificate, there is nothing ensuring only unbound group members or root user can change runtime configuration.

Test options using command "unbound-control get_option control-interface". If it returns only unix domain socket path, it will enforce only unbound members can use it. It can be tested by command:

# ls -l $(unbound-control get_option control-interface)

It should list used rights as:
srw-rw----. 1 unbound unbound

If only unix domain socket is used for control, this is sufficient to ensure only privileged members. It does not need any change of unbound-control command configuration, it will use main /etc/unbound/unbound.conf file anyway.

#  unbound-control status | grep control
options: reuseport control(namedpipe)

If at least one IPv4 or IPv6 address is used in control-interface option or it is empty, network socket is used (also). In that case, ensure control-key-file is accessible only to members of unbound group or alternative similar. Or only root user, as is current default.

# ls -l $(unbound-control get_option control-key-file)
-rw-------. 1 root unbound 2459 Apr 10 06:25 /etc/unbound/unbound_control.key

Ensure also remote-control: section contains control-use-cert: "yes", which is built-in default in case it is missing.

Of course mitigation of this vulnerability is also disabling control channel completely.

Enforcement can be checked trivially by using sudo with unprivileged user, for example nobody:
# sudo -u nobody unbound-control status
[1712747431] unbound-control[6183:0] error: connect: Permission denied for /run/unbound/control

This should fail in correct configuration. But with unbound or root user it should succeed.
# sudo unbound-control status

If using both IP addresses and unix domain socket, put addresses first. That should ensure SSL is required over addresses connections, ensuring only allowed users can see or change the configuration.

Check chosen control mode uses ssl:
# unbound-control status | grep control
options: reuseport control(ssl)

unbound-control -s ::1 can be used to manually specify which socket address to use. First is used by default, whatever (type) it is.

Comment 11 Petr Menšík 2024-04-10 11:36:55 UTC
We strongly recommend to not mix unix domain socket and addresses in control-interface option. They may lead to unexpected behaviour.

Comment 12 errata-xmlrpc 2024-04-11 10:20:07 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2024:1751 https://access.redhat.com/errata/RHSA-2024:1751

Comment 13 errata-xmlrpc 2024-04-11 10:46:28 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.2 Extended Update Support

Via RHSA-2024:1780 https://access.redhat.com/errata/RHSA-2024:1780

Comment 14 errata-xmlrpc 2024-04-15 01:26:14 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.0 Extended Update Support

Via RHSA-2024:1801 https://access.redhat.com/errata/RHSA-2024:1801

Comment 15 errata-xmlrpc 2024-04-15 01:38:51 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.6 Extended Update Support

Via RHSA-2024:1804 https://access.redhat.com/errata/RHSA-2024:1804

Comment 16 errata-xmlrpc 2024-04-15 01:39:09 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.8 Extended Update Support

Via RHSA-2024:1802 https://access.redhat.com/errata/RHSA-2024:1802

Comment 17 errata-xmlrpc 2024-04-30 15:06:18 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.4 Telecommunications Update Service
  Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions
  Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support

Via RHSA-2024:2587 https://access.redhat.com/errata/RHSA-2024:2587

Comment 18 errata-xmlrpc 2024-05-06 01:12:02 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.2 Advanced Update Support
  Red Hat Enterprise Linux 8.2 Telecommunications Update Service
  Red Hat Enterprise Linux 8.2 Update Services for SAP Solutions

Via RHSA-2024:2696 https://access.redhat.com/errata/RHSA-2024:2696