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
Created unbound tracking bugs for this issue: Affects: fedora-all [bug 2264184]
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
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.
We strongly recommend to not mix unix domain socket and addresses in control-interface option. They may lead to unexpected behaviour.
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
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
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
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
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
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