The ebuild for asterisk gives its user ownership of three directories: diropts -m 0770 -o asterisk asterisk keepdir /var/lib/asterisk keepdir /var/spool/asterisk ... keepdir /var/log/asterisk/{cdr-csv,cdr-custom} The checkperms() function in the init script then searches through those directories, looking for files that are not owned by the asterisk user: for path in "${ast_rundir}" "${ast_spooldir}" "${ast_logdir}"; do ... find "${path}" ! -user "${ast_user}" | while read element; do ... If any matching files or links are found, the init script attempts to fix their permissions and ownership: chown ${ast_user} "${element}" chmod u+rwX "${element}" However, the "chown" here can be exploited to gain root privileges. The asterisk user is free to place a hardlink in any one of those three directories pointing to a root-owned file. The call to chown will affect the target of the link, giving ownership of it to the asterisk user. I didn't try very hard, but at first glance, symlinks don't seem to work because they will be owned by the asterisk user if he creates them, and are thus excluded from the "find" command. Hard links, on the other hand, share their ownership with the link target even when created by the asterisk user.
@ Maintainer(s): Please tell us how you want to proceed here. Are you going to look into this or do you want security to take actions?
Unrestricting and reassigning to security@ per bug #705894
unrestricting per bug 705894
How? Because of the way my partitions are split be default I actually had to create a weakness first: plastiekpoot ~ # mkdir /tmp2 plastiekpoot ~ # chown jkroon: /tmp2 plastiekpoot ~ # Then as jkroon: jkroon@plastiekpoot /tmp2 $ ln /etc/passwd ln: failed to create hard link './passwd' => '/etc/passwd': Operation not permitted So please provide me an actionable example and I'll happily figure out a workaround, but as of right now, I'm unable to reproduce. This may relate in /etc/sysctl.conf: # Improved security for filesystem symlink based attacks. fs.protected_symlinks = 1 fs.protected_hardlinks = 1 Which is also the default for gentoo-sources. I can confirm without that without the protected_hardlinks option it becomes possible to hard link: jkroon@plastiekpoot /tmp2 $ ln /etc/passwd jkroon@plastiekpoot /tmp2 $ Secondary question, can anyone envision a way to use symlinks here? I know the op stated "doesn't seem to affect", but that's empirical, I'd like a more concrete answer. I tend to concur with Michael, however, you don't know what you don't know, so whilst I'm not aware of a way to exploit symlinks here I can't guarantee that no one else does. jkroon@plastiekpoot /tmp2 $ ln -s /etc/passwd passwd2 jkroon@plastiekpoot /tmp2 $ Would adding a check for the relevant sysctl option be satisfactory? Please also note that this code doesn't run standard. It's an extra_commands="checkperms" option. I personally never use this, and am quite happy to remove this completely. In fact, I argue that this permissions isn't actually right, and as a general rule a lot of /var/lib/asterisk/ are generally root: owned on my systems. As evidenced by the newer net-misc/asterisk-*-sounds and net-misc/asterisk-moh-opsound packages. Thus I see three (four) options: 1. Add a warning and read confirmation in the code asking whether the user really wants to do this and highlight the risk. 2. Completely remove the code. One less thing I need to worry about :). 3. Add a "(-type d -o links 1)" which will at least make it somewhat harder to exploit (an attacker would need to remove an existing file and create a hard link between the find and chown). (4. Rely on the sysctl option.) @ Michael, I note the bug was originally filed in 2016-12-15, at that point I believe the relevant code was still part of start().
(In reply to Jaco Kroon from comment #4) > > jkroon@plastiekpoot /tmp2 $ ln /etc/passwd > ln: failed to create hard link './passwd' => '/etc/passwd': Operation not > permitted > > So please provide me an actionable example and I'll happily figure out a > workaround, but as of right now, I'm unable to reproduce. This may relate > in /etc/sysctl.conf: > > # Improved security for filesystem symlink based attacks. > fs.protected_symlinks = 1 > fs.protected_hardlinks = 1 > > Which is also the default for gentoo-sources. > The protected_hardlinks option stops this for hardlinks, but it's not standard. It's not in the vanilla kernel, or in bliss-kernel-bin, or necessarily available to someone using prefix. It may never be enabled upstream in the linux kernel since it messes with POSIX semantics. The same thing works with symlinks, too, however -- and the protected_symlinks option doesn't stop it. (Symlinks are used more often, so they're harder to restrict without breaking everything.) Both chown and chmod will act on the target of a symlink. If checkperms() is no longer a part of start(), then I would say deleting it is the easy/correct option. If there are permission problems, it's usually a symptom of something else (e.g. wrong stuff in the ebuild) rather than something to be bluntly fixed after things are already messed up.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c9be2eb04d1594bd7b236692d8244a9cda247470 commit c9be2eb04d1594bd7b236692d8244a9cda247470 Author: Jaco Kroon <jaco@uls.co.za> AuthorDate: 2020-04-06 16:01:11 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2020-04-09 12:37:45 +0000 net-misc/asterisk: security bump (init script). The details is outlined in: Bug: https://bugs.gentoo.org/602722 This only affects things if you can trick the sysadmin to run /etc/init.d/asterisk checkperms. Took the opportunity to tighten permissions on /var/lib/asterisk and /var/spool/asterisk as well, and double checked that on new install these are in fact correct. Permissions on /var/spool/asterisk/recording was missed previously and left root:root as per the standard asterisk install Makefile. Package-Manager: Portage-2.3.89, Repoman-2.3.20 Signed-off-by: Jaco Kroon <jaco@uls.co.za> Closes: https://github.com/gentoo/gentoo/pull/15246 Signed-off-by: Joonas Niilola <juippis@gentoo.org> net-misc/asterisk/asterisk-13.32.0-r1.ebuild | 331 ++++++++++++++++++++++++ net-misc/asterisk/files/initd-13.32.0-r1 | 362 +++++++++++++++++++++++++++ 2 files changed, 693 insertions(+)
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=a11218e8b8cebddcca01bf3d4198dd08497bcbc8 commit a11218e8b8cebddcca01bf3d4198dd08497bcbc8 Author: Jaco Kroon <jaco@uls.co.za> AuthorDate: 2020-04-15 07:33:27 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2020-04-17 07:35:54 +0000 net-misc/asterisk: cleanup. Bug: https://bugs.gentoo.org/602722 Bug: https://bugs.gentoo.org/689796 Package-Manager: Portage-2.3.89, Repoman-2.3.20 Signed-off-by: Jaco Kroon <jaco@uls.co.za> Closes: https://github.com/gentoo/gentoo/pull/15350 Signed-off-by: Joonas Niilola <juippis@gentoo.org> net-misc/asterisk/Manifest | 4 - net-misc/asterisk/asterisk-13.23.1.ebuild | 327 ----------------------------- net-misc/asterisk/asterisk-13.29.1.ebuild | 325 ----------------------------- net-misc/asterisk/asterisk-13.31.0.ebuild | 325 ----------------------------- net-misc/asterisk/asterisk-13.32.0.ebuild | 332 ------------------------------ 5 files changed, 1313 deletions(-)
thanks!
Unable to check for sanity: > no match for package: =net-misc/asterisk-13.32.0-r1
https://bugs.gentoo.org/show_bug.cgi?id=720184 cleanup triggered the nattka issue after cleanup for that. stabling has already been handled that side: asterisk-13.33.0.ebuild:KEYWORDS="amd64 ~ppc ~ppc64 x86"
*** Bug 630918 has been marked as a duplicate of this bug. ***
This issue was resolved and addressed in GLSA 202006-20 at https://security.gentoo.org/glsa/202006-20 by GLSA coordinator Aaron Bauman (b-man).
