The ebuild for arpwatch does... fowners arpwatch:0 "${ROOT}"/var/lib/arpwatch after which the arpwatch user controls the /var/lib/arpwatch directory. In particular, he can replace the files therein with symlinks. The init script for arpwatch has, DATAFILE=/var/lib/arpwatch/${IFACE}.dat ... chown ${ARPUSER} ${DATAFILE} (behind some conditional, but run by default) which calls "chown" on a location that the arpwatch user controls. By replacing ${IFACE}.dat with a symlink to another file, the arpwatch user can gain ownership of that file the next time the init script is run.
As we discovered over in bug #602550, users of vanilla-sources (and others) are vulnerable to the same attack using hard links, so simply adding "--no-dereference" to the "chown" call is not enough to fix this.
@ Maintainer(s): Please tell us how you want to proceed here. Are you going to look into this our should security take actions?
I'm fine with security doing what they feel is right here. bonus points for running it by me on irc (but not required) if it were me, I'd probably just not run fowners and leave it restricted to root.
(In reply to Rick Farina (Zero_Chaos) from comment #3) > > if it were me, I'd probably just not run fowners and leave it restricted to > root. This runs as the restricted ARPUSER=arpwatch by default, so the "fowners" is necessary to let that user write data files to /var/lib/arpwatch. Unfortunately, when you let the end user change something like ARPUSER between runs of the daemon, in order to "just make it work" you have to do something like chown ${ARPUSER} ${DATAFILE} because otherwise, the new ARPUSER won't be able to read the old ARPUSER's files after ARPUSER changes. Personally, I would just say: don't do that. Run it as the "arpwatch" user that is created specifically for this purpose. If somebody wants to change that (why???), then he will need to fix the permissions once himself, because it isn't safe to automate it. So my proposed fix is to drop the ARPUSER variable, hard-code the "arpwatch" username, and then there's no need to chown anything because "arpwatch" will always own his own stuff. I haven't checked this, but I think that changing ARPUSER is already broken, because "arpwatch" will always own /var/lib/arpwatch. If somebody changes ARPUSER and tries to run on a new interface, the new ARPUSER won't be able to create a new data file. ..also, why is fowners called in pkg_postinst and not in src_install?
Created attachment 497278 [details] arpwatch-2.1.15-r9.ebuild
Created attachment 497280 [details] arpwatch.confd-r1
Created attachment 497282 [details] arpwatch.initd-r1 I've updated the ebuild to EAPI=6 (somebody pleeease fix those two patches), and reworked the init script. The "chown" is gone, and the user is hard-coded to "arpwatch" which was necessary anyway for him to access /var/lib/arpwatch. Instead of attempting to have one init script start multiple daemons, I documented the fact that you should symlink the init script (and create a new conf.d file) to run a new instance. This makes the init script almost trivial, and lets us depend on the correct interface being up. Lightly tested, but it seems to start/stop OK.
Marcin, do you use arpwatch? The new ebuild/script I posted might also fix bug #554222, but since I don't use arpwatch myself, I've never experienced that problem and can't say for sure.
I don' use arpwatch now but it should be easy to run it again, I'll do it.
Arpwatch works correctly for me, saves state in file, resumes it after restart. Looks good.
Thank you! I've committed an -r10 with the fixed init script and conf.d file. Thanks also to Jeroen for cleaning up those patches I complained about =) commit 6739ee69e69a954bc27a3040ab59d46b82582229 Author: Michael Orlitzky <mjo@gentoo.org> Date: Sun Oct 22 13:22:30 2017 -0400 net-analyzer/arpwatch: new revision to fix privilege escalation. In previous revisions, the init script for arpwatch called "chown" as root on a location under /var/lib/arpwatch -- a path that is controlled by the "arpwatch" user per its ebuild. That could be exploited by the "arpwatch" user to take control of root-owned files. This new revision comes with a new init script and conf.d file that completely rework the way instances are created and run. The "arpwatch" user is hard-coded, because as was mentioned, the ebuild sets some important permissions for that user. Since it is not possible to change that user, the need for "chown" is eliminated. Separate instances are now created by symlinking the init script (like our network interface scripts), rather than by enumerating them in a single arpwatch init script. Upgraders will want to review their configurations. Bug: https://bugs.gentoo.org/602552 Package-Manager: Portage-2.3.8, Repoman-2.3.3
Unrestricting and reassigning to security@ per bug #705894
unrestricting per bug 705894
@maintainer(s), let us know if there's anything stopping stabilisation, or I'll go ahead in a few days.
hppa stable
ppc stable
sparc stable
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6386bce12b9bae7b7e123449d719203d757a1402 commit 6386bce12b9bae7b7e123449d719203d757a1402 Author: Aaron Bauman <bman@gentoo.org> AuthorDate: 2020-06-20 01:04:55 +0000 Commit: Aaron Bauman <bman@gentoo.org> CommitDate: 2020-06-20 01:04:55 +0000 net-analyzer/arpwatch: drop vulnerable Bug: https://bugs.gentoo.org/602552 Signed-off-by: Aaron Bauman <bman@gentoo.org> net-analyzer/arpwatch/Manifest | 1 - net-analyzer/arpwatch/arpwatch-2.1.15-r8.ebuild | 62 ------------------------ net-analyzer/arpwatch/arpwatch-2.1.15-r9.ebuild | 63 ------------------------- 3 files changed, 126 deletions(-)
GLSA opened.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9207fdd5442a659ef9e18c75bad1eb277bb62ea5 commit 9207fdd5442a659ef9e18c75bad1eb277bb62ea5 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2020-06-28 12:04:44 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2020-06-28 12:05:37 +0000 net-analyzer/arpwatch: Install new conf.d/init.d scripts Package-Manager: Portage-2.3.103, Repoman-2.3.23 Bug: https://bugs.gentoo.org/602552 Closes: https://bugs.gentoo.org/727220 Signed-off-by: Jeroen Roovers <jer@gentoo.org> net-analyzer/arpwatch/arpwatch-3.1.ebuild | 6 ++--- net-analyzer/arpwatch/files/arpwatch.confd-r2 | 18 +++++++++++++++ net-analyzer/arpwatch/files/arpwatch.initd-r2 | 33 +++++++++++++++++++++++++++ 3 files changed, 54 insertions(+), 3 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=403c29bc5a1f7aff555915962b083d292fdecdf1 commit 403c29bc5a1f7aff555915962b083d292fdecdf1 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2020-06-28 11:13:55 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2020-06-28 12:05:35 +0000 net-analyzer/arpwatch: Clean up FILESDIR Bug: https://bugs.gentoo.org/602552 Fixes: 6386bce12b9bae7b7e123449d719203d757a1402 Package-Manager: Portage-2.3.103, Repoman-2.3.23 Signed-off-by: Jeroen Roovers <jer@gentoo.org> net-analyzer/arpwatch/files/arpwatch.confd | 11 --------- net-analyzer/arpwatch/files/arpwatch.initd | 36 ------------------------------ 2 files changed, 47 deletions(-)
(In reply to Larry the Git Cow from comment #22) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=9207fdd5442a659ef9e18c75bad1eb277bb62ea5 > > commit 9207fdd5442a659ef9e18c75bad1eb277bb62ea5 > Author: Jeroen Roovers <jer@gentoo.org> > AuthorDate: 2020-06-28 12:04:44 +0000 > Commit: Jeroen Roovers <jer@gentoo.org> > CommitDate: 2020-06-28 12:05:37 +0000 > > net-analyzer/arpwatch: Install new conf.d/init.d scripts > > Package-Manager: Portage-2.3.103, Repoman-2.3.23 > Bug: https://bugs.gentoo.org/602552 > Closes: https://bugs.gentoo.org/727220 > Signed-off-by: Jeroen Roovers <jer@gentoo.org> > > net-analyzer/arpwatch/arpwatch-3.1.ebuild | 6 ++--- > net-analyzer/arpwatch/files/arpwatch.confd-r2 | 18 +++++++++++++++ > net-analyzer/arpwatch/files/arpwatch.initd-r2 | 33 > +++++++++++++++++++++++++++ > 3 files changed, 54 insertions(+), 3 deletions(-) I needed to bump the scripts in order to drop the '-u arpwatch' flag which version 3.1 does not support. The daemon effectively runs as root now. Not sure if that will cause additional problems.
(In reply to Jeroen Roovers from comment #23) > > I needed to bump the scripts in order to drop the '-u arpwatch' flag which > version 3.1 does not support. The daemon effectively runs as root now. Not > sure if that will cause additional problems. It might still be possible to run as an unprivileged user by setting command_user=arpwatch and command_background=true in the OpenRC service script. The daemon has a "-F" flag that runs it in the foreground (to be backgrounded by OpenRC). Or, maybe there's a good reason why they dropped the flag. No one can say we didn't try.
(In reply to Michael Orlitzky from comment #24) > (In reply to Jeroen Roovers from comment #23) > > > > I needed to bump the scripts in order to drop the '-u arpwatch' flag which > > version 3.1 does not support. The daemon effectively runs as root now. Not > > sure if that will cause additional problems. > > It might still be possible to run as an unprivileged user by setting > command_user=arpwatch and command_background=true in the OpenRC service > script. The daemon has a "-F" flag that runs it in the foreground (to be > backgrounded by OpenRC). That would require some more interference, I think. > Or, maybe there's a good reason why they dropped the flag. No one can say we > didn't try. The 3.1 daemon seemingly drops some of its privileges (setgid(getgid())/setuid(getuid())) after acquiring some privileged access (after pcap setup, arpwatch.c, lines 386-7). Not sure how to combine that with OpenRC script changes.
This issue was resolved and addressed in GLSA 202007-25 at https://security.gentoo.org/glsa/202007-25 by GLSA coordinator Sam James (sam_c).
