Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 602722 - <net-misc/asterisk-13.32.0-r1: root privilege escalation in init script checkperms command
Summary: <net-misc/asterisk-13.32.0-r1: root privilege escalation in init script check...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B1 [glsa+]
Keywords: PullRequest
: 630918 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-12-15 01:41 UTC by Michael Orlitzky
Modified: 2020-06-15 15:54 UTC (History)
3 users (show)

See Also:
Package list:
=net-misc/asterisk-13.33.0 amd64 x86
Runtime testing required: No


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Orlitzky gentoo-dev 2016-12-15 01:41:31 UTC
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.
Comment 1 Thomas Deutschmann gentoo-dev Security 2017-01-08 23:30:29 UTC
@ 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?
Comment 2 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2020-04-03 23:16:38 UTC
Unrestricting and reassigning to security@ per bug #705894
Comment 3 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2020-04-03 23:18:18 UTC
unrestricting per bug 705894
Comment 4 Jaco Kroon 2020-04-04 08:06:18 UTC
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().
Comment 5 Michael Orlitzky gentoo-dev 2020-04-04 11:07:15 UTC
(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.
Comment 6 Larry the Git Cow gentoo-dev 2020-04-09 12:38:11 UTC
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(+)
Comment 7 Agostino Sarubbo gentoo-dev 2020-04-14 16:43:47 UTC
amd64 stable
Comment 8 Agostino Sarubbo gentoo-dev 2020-04-15 06:58:34 UTC
x86 stable.

Maintainer(s), please cleanup.
Security, please add it to the existing request, or file a new one.
Comment 9 Larry the Git Cow gentoo-dev 2020-04-17 07:36:37 UTC
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(-)
Comment 10 Sam James archtester gentoo-dev Security 2020-04-17 16:11:15 UTC
thanks!
Comment 11 NATTkA bot gentoo-dev 2020-05-14 22:32:26 UTC
Unable to check for sanity:

> no match for package: =net-misc/asterisk-13.32.0-r1
Comment 12 Jaco Kroon 2020-05-15 07:42:46 UTC
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"
Comment 13 Jaco Kroon 2020-05-22 07:04:45 UTC
*** Bug 630918 has been marked as a duplicate of this bug. ***
Comment 14 GLSAMaker/CVETool Bot gentoo-dev 2020-06-15 15:54:21 UTC
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).