Linux CIFS filesystem development
 help / color / mirror / Atom feed
From: samba-bugs@samba.org
To: cifs-qa@samba.org
Subject: [Bug 15026] Partial arbitrary file read via mount.cifs
Date: Mon, 21 Mar 2022 16:36:48 +0000	[thread overview]
Message-ID: <bug-15026-10630-Rz7JhL3pu6@https.bugzilla.samba.org/> (raw)
In-Reply-To: <bug-15026-10630@https.bugzilla.samba.org/>

https://bugzilla.samba.org/show_bug.cgi?id=15026

--- Comment #3 from David Disseldorp <ddiss@samba.org> ---
(In reply to Jeffrey Bencteux from comment #2)
> (In reply to David Disseldorp from comment #1)
> 
> > Please correct me if I'm wrong, but I don't expect that this would be exploitable
> > on regular systems unless mount.cifs is installed with setuid-root, or an attacker
> > somehow has access to the "credentails" path fed into a mount.cifs invocation.
> 
> That is partially correct, note that on a vanilla Debian 10, mount.cifs is
> setuid-root by default:
> 
> $ ls -l /usr/sbin/mount.cifs 
> -rwsr-xr-x 1 root root 35600 Jun 17  2018 /usr/sbin/mount.cifs

Ouch. I assume Ubuntu inherits this default setting.

> And likely it is the case on other distributions as otherwise the following
> message is returned:
> 
> $ ./mount.cifs //127.0.0.1/share /mnt/share -v -o credentials=/etc/sudoers
> This program is not installed setuid root -  "user" CIFS mounts not
> supported.
> 
> It however seems needed to either:
> 
> 1) have privileged user rights to trigger the bug, such as the below line in
> /etc/sudoers:
> 
> testuser ALL=NOPASSWD: /usr/sbin/mount.cifs
> 
> Which is less likely but possible.
> 
> 2) Have the scenario you depict where a user can tamper a mount with a rogue
> "credentials" option value.
> 
> This greatly reduce the risk IMO.
> 
> I think the explanation is in these lines of mount.cifs.c:
> 
>  115  * When an unprivileged user runs a setuid mount.cifs, we set certain
> mount
>  116  * flags by default. These defaults can be changed here.
>  117  */
>  118 #define CIFS_SETUID_FLAGS (MS_NOSUID|MS_NODEV)
> 
> I expect some people to use rules such as the above sudo one to circumvent
> the problem.

I don't completely follow - so for the setuid-root case, can root-readable
files be dumped by regular users (ignoring apparmor/selinux) using
credentials=<root-only-path>, or do the dropped privileges mean that a
different approach (sudo) is needed?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

      parent reply	other threads:[~2022-03-21 16:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21 11:03 [Bug 15026] New: Partial arbitrary file read via mount.cifs samba-bugs
2022-03-21 12:13 ` [Bug 15026] " samba-bugs
2022-03-21 12:42 ` samba-bugs
2022-03-21 13:49 ` samba-bugs
2022-03-21 16:36 ` samba-bugs [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-15026-10630-Rz7JhL3pu6@https.bugzilla.samba.org/ \
    --to=samba-bugs@samba.org \
    --cc=cifs-qa@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox