oss-security - cantata: cantata-mounter D-Bus service local privilege escalation and other security issues

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180618090836.GB8123@f195.suse.de>
Date: Mon, 18 Jun 2018 11:08:36 +0200
From: Matthias Gerstner <mgerstner@...e.de>
To: oss-security@...ts.openwall.com
Subject: cantata: cantata-mounter D-Bus service local privilege escalation
 and other security issues

Hello list,

this is a report about local privilege and local denial of service
issues found in cantata, a graphical client for MPD
(<https://github.com/CDrummond/cantata/wiki/About-Cantata>).

cantata supports a D-Bus helper daemon "cantata-mounter" for mounting
remote samba shares by calling `mount.cifs` on Linux systems. This
daemon is configured for on-demand activation, running as root and its
D-Bus interface is accessible by unprivileged users by default.

The daemon code is part of cantata since version 2.0.0 and it is built
by default in versions 2.3.0 and 2.3.1. Before 2.3.0 it was only built
if `-DENABLE_REMOTE_DEVICES=ON` was passed to the cmake invocation.

Due to the issues explained below the upstream maintainer decided to
drop the D-Bus service completely from future versions. This already
happened through upstream commit afc4f8315d3e96574925fb530a7004cc9e6ce3d3.
Therefore there are no fixes available except not building and shipping
the D-Bus service in question.

Following are four distinct security issues found in the
cantata-mounter D-Bus service:

A) The mount target path check in mounter.cpp `mpOk()` is insufficient.
  A regular user can this way mount a CIFS filesystem anywhere, and not
  just beneath /home by passing relative path components. Example D-Bus
  call:

  dbus-send --system --print-reply --dest=mpd.cantata.mounter /Mounter mpd.cantata.mounter.mount 'string:smb://workgroup\user:password@...t:port/path?domain=domain' string:/home/../usr/bin int32:$$ int32:0 int32:0

  By replacing data in system paths like /usr/bin by data from an
  attacker controlled samba share, a local attacker can cause root to
  execute modified programs or to read modified configuration files.
  Therefore it opens the avenue for a local root escalation.

B) Arbitrary unmounts can be performed by regular users the same way.
  For example this D-Bus call unmounts /sys/kernel/security:

  dbus-send --system --print-reply --dest=mpd.cantata.mounter /Mounter mpd.cantata.mounter.umount string:/home/../sys/kernel/security int32:$$

  This allows for a local denial of service and possible further
  unspecified kinds of system manipulation.

C) A regular user can inject additional mount options like file_mode= by
  manipulating e.g. the domain parameter of the samba URL. This D-Bus
  call injects the 'file_mode=777' parameter:

  dbus-send --system --print-reply --dest=mpd.cantata.mounter /Mounter mpd.cantata.mounter.mount 'string:smb://workgroup\user@...t:port/path?domain=domain,file_mode=777' string:/home/user int32:$$ int32:0 int32:0

  This way the user can use all options that mount.cifs offers to e.g.
  produce files with arbitrary ownership and mode.

D) The wrapper script 'mount.cifs.wrapper' uses the shell to forward the
  arguments to the actual mount.cifs binary. The shell evaluates
  wildcards which can also be injected like this:

  dbus-send --system --print-reply --dest=mpd.cantata.mounter /Mounter mpd.cantata.mounter.mount 'string:smb://workgroup\user:password@...t:port/path?domain=domain' 'string:/home/../tmp/*' int32:$$ int32:0 int32:0

  In this case all files in /tmp/* will be expanded and passed to
  mount.cifs as parameters. This shouldn't allow further attack vectors,
  because there are no additional arguments that mount.cifs supports.
  But it still shouldn't happen.

  The reason for "Calling mount.cifs directly from DBUS service seems to
  mess things up?" which is stated in 'mount.cifs.wrapper' most probably
  is that the D-Bus service has an empty PATH variable and can't find
  mount.cifs. At least it is this way on openSUSE Tumbleweed where I
  tested this.

Furthermore the mount D-Bus method allows unprivileged users to specify
the owner uid and gid of the mounted samba shared (passed as `uid=` and
`gid=` mount.cifs parameters). The daemon should instead determine the
callers uid and gid and use them, because this way the user can produce
files with arbitrary user and group ownership, which is normally not
possible.

Cheers

Matthias

-- 
Matthias Gerstner <matthias.gerstner@...e.de>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
https://www.suse.com/security
Telefon: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553

SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nuernberg)

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.