[Bug 1173619] New: VUL-0: unbound: LPE from unbound to root
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619 Bug ID: 1173619 Summary: VUL-0: unbound: LPE from unbound to root Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: darin@darins.net Reporter: wolfgang.frisch@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- via security@suse.de: I believe to have found a configuration issue in the Unbound package. Or, depending on how you look at it, in the Unbound server itself. 1. Before starting the Unbound server, systemd routinely runs unbound-anchor. From 'systemctl cat unbound': ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem As you can see this process is run as user unbound. 2. The Unbound server writes a pid file before dropping privileges, i.e. as root. It then chown's the file in a second step. 'grep username /etc/unbound/unbound.conf': username: "unbound" And from the Unbound source: https://github.com/NLnetLabs/unbound/blob/2a90e8fa1e22aa75d1cf67a1f71ebbf3f9... As you can see in the source, Unbound doesn't check if there is already a symbolic link in place of the pid file. 3. openSUSE configures Unbound to create the pid file in a directory owned by the unbound user. 'grep pidfile /etc/unbound/unbound.conf': pidfile: "/var/run/unbound/unbound.pid" 'cat /usr/lib/tmpfiles.d/unbound.conf': D /run/unbound 0755 unbound unbound - 4. unbound-anchor is a nice little "do-one-thing-and-do-it-right" tool. But if it is compromised, and as it has write permission in the pid file directory and reliably runs before the server, an attacker could easily gain full root privileges by just creating a symbolic link /run/unbound/unbound.pid. 5. IMHO this would be best fixed in openSUSE by creating a root owned /run/unbound directory, or changing the pid file path to /run/unbound.pid or something like that. I think this would have the added advantage that openSUSE could ship and maybe enforce the Unbound AppArmor profile used in Debian and Ubuntu: https://gitlab.com/apparmor/apparmor-profiles/-/blob/master/ubuntu/20.04/usr... With the current openSUSE setup there is the problem that if AppArmor filters CAP_DAC_OVERRIDE, Unbound has no permission to create a pid file in /run/unbound anymore. If you have questions please don't hesitate to contact me. Thanks for taking a look. Kind regards, Detlef -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619#c1
--- Comment #1 from Wolfgang Frisch
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619#c15
--- Comment #15 from Detlef Eppers
Hmm, does this affect intended usage of unbound-control? The man-page is not clear on that.
AFAICT all that unbound-control does is telling the server to update its internal state at runtime, or to print some information. It needs read access to the server configuration files, but I don't think it will ever issue writes.
But for a general purpose package we unfortunately have to clarify whether changes to the .spec file makes using some features impossible.
It looks that write access to the config files is a SUSE specific setting currently and other distributions don't do this. Do you carry patches that make that necessary? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
Michael Str�der
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619#c16
--- Comment #16 from Detlef Eppers
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
Wolfgang Frisch
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619#c17
Wolfgang Frisch
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619#c18
--- Comment #18 from Wolfgang Frisch
(In reply to Wolfgang Frisch from comment #13)
Michael, can you please have a look and adjust the .spec file? The attached patch should do the trick.
Hmm, does this affect intended usage of unbound-control? The man-page is not clear on that.
But for a general purpose package we unfortunately have to clarify whether changes to the .spec file makes using some features impossible.
I just experimented with latest version of unbound in Tumbleweed, adjusted the permissions, and could not detect any problems. `unbound-control` also continues to function normally. We can proceed with the changes. On a different, less important note: `unbound-control-setup` doesn't work out of the box because its missing `openssl` as a dependency. This is matter of taste of course, but it would improve the user experience to include it, in my humble opinion. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
Wolfgang Frisch
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619#c19
--- Comment #19 from Michael Str�der
I just experimented with latest version of unbound in Tumbleweed, adjusted the permissions, and could not detect any problems. `unbound-control` also continues to function normally.
Thanks for testing that. How to proceed? IMHO the use of ExecStartPre= in unbound.service is kind of a mess. Do we really still need it? Could we set User= and Group= to unbound in unbound.service? Worth to note is this discussion on the unbound-users list: "unbound itself manages root trust anchor automatically these days" see https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-May/007747.html Also this thoughts on Linux distros distributions shipping root.key and root.hints: https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-May/007749.html -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619#c20
--- Comment #20 from Wolfgang Frisch
(In reply to Wolfgang Frisch from comment #18)
I just experimented with latest version of unbound in Tumbleweed, adjusted the permissions, and could not detect any problems. `unbound-control` also continues to function normally.
Thanks for testing that.
How to proceed? We can definitely apply the aforementioned permission changes: https://bugzilla.opensuse.org/attachment.cgi?id=849858
IMHO the use of ExecStartPre= in unbound.service is kind of a mess. Do we really still need it? Could we set User= and Group= to unbound in unbound.service? I agree, it's not very elegant, and it ties in with your research below:
"unbound itself manages root trust anchor automatically these days" see https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-May/007747.html This indeed appears to work, but if I'm not mistaken we would then have to ship the DNS root data ourselves as well, similar to Debian:
Also this thoughts on Linux distros distributions shipping root.key and root.hints:
https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-May/007749.html
I'm all for it but we should test it carefully. Breaking DNS servers are not a fun experience ;) There's currently a version bump underway (sr#980737). Let's wait for it to go through and then test and submit our changes: - adjust permissions - build a separate package with DNS root data - remove unbound-anchor from the systemd .service files - remove dependency on unbound-anchor -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619#c21
--- Comment #21 from Wolfgang Frisch
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619#c22
--- Comment #22 from Wolfgang Frisch
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619#c23
Wolfgang Frisch
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619#c24
Wolfgang Frisch
participants (1)
-
bugzilla_noreply@suse.com