Bug 1171721 - VUL-0: pam: pam_setquota.so can be tricked to operate on arbitrary block devices by using fusermount
VUL-0: pam: pam_setquota.so can be tricked to operate on arbitrary block devi...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security
Current
Other Other
: P3 - Medium : Normal (vote)
: ---
Assigned To: Josef Möllers
E-mail List
https://smash.suse.de/issue/259731/
:
Depends on:
Blocks: 1171563
  Show dependency treegraph
 
Reported: 2020-05-15 09:34 UTC by Matthias Gerstner
Modified: 2020-10-15 12:35 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Gerstner 2020-05-15 09:34:45 UTC
+++ This bug was initially created as a clone of Bug #1171563

So this pam_setquota module iterates over all mounted file systems using
`setmntent()` and `getmntent()`. It tries to find the longest match of a file
system mounted on /home/$USER or above (except when the fs=/some/path
parameter is passed to the pam module).

The thing is that /home/$USER is owned by the unprivileged user. And there
exist tools like fusermount from libfuse which is by default installed
setuid-root for everybody. fusermount allows to mount a FUSE file system using
an arbitrary "source device name" as the unprivileged user.

Thus considering the following use case:

1) there is only the root file system (/) or a file system is mounted on
   /home, but not on /home/$USER.
2) the attacker mounts a fake FUSE file system over its own home directory:

  ```
  user $ export _FUSE_COMMFD=0
  user $ fusermount $HOME -ononempty,fsname=/dev/sda1
  ```

  This will result in a mount entry in /proc/mounts looking like this:

  ```
  /dev/sda1 on /home/$USER type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
  ```
3) when the attacker now logs in with pam_setquota configured then
   pam_setquota will identify /dev/sda1 and the file system where to apply the
   user's quota on.

As a result an unprivileged user has full control over onto which block device
the quota is applied.
Comment 2 Matthias Gerstner 2020-05-15 09:37:11 UTC
To fix this issue I suggest to filter out "fuse" mount entries like I did in
the suggested patch in attachment 837826 [details]. Even better would be a whitelist of
file systems, however. I'm not sure how simple that would be to implement.

It looks like you are upstream yourself so I won't attempt to contact upstream
directly. Otherwise please tell me which people I should involve by e-mail. I
think this finding warrants a CVE assignment.

For the moment this finding is private until upstream tells me how the
disclosure process should be handled. Our SUSE security disclosure policy can
be found in [1].

[1]: https://en.opensuse.org/openSUSE:Security_disclosure_policy
Comment 7 Matthias Gerstner 2020-05-15 13:30:45 UTC
(In reply to josef.moellers@suse.com from comment #6)
> Just to let me get this straight:
> 
> This means that through this a user can disable any quota on his $HOME the system administrator might want to impose upon him?

That wasn't exactly what I had in mind. Possibly the user can fiddle with
this, too. However the user usually needs to login first to perform the attack
so it's straight away usable.

What I had in mind is that the user can have the quote destined for his home
directory / partition to be applied on an arbitrary other block device that
supports quota settings. The impact of this varies depending on the actual
system setups. It could be a kind of DoS against itself but it could also mean
increasing the user's quota on some unrelated file system.

In any way through this attack vector the PAM module operates outside of its
intended use case.
Comment 8 Matthias Gerstner 2020-05-22 08:07:39 UTC
The upstream discussion seems to have died down. I have no further
suggestions. When they want to skip user owned directories completely it's
also fine with me. This could break some use cases, where each home directory
is an individual mount, however.

Once there is a fix in the pam devel package we can whitelist all three new
PAM modules in one go.
Comment 9 Thorsten Kukuk 2020-05-25 06:49:54 UTC
(In reply to Matthias Gerstner from comment #8)

> Once there is a fix in the pam devel package we can whitelist all three new
> PAM modules in one go.

Can we please whitelist the two accepted modules now? It doesn't make any sense to block all development only because of an irrelevant, unimportant PAM module. We can better drop that for the time.
Comment 10 Matthias Gerstner 2020-05-25 07:57:56 UTC
(In reply to kukuk@suse.com from comment #9)
> Can we please whitelist the two accepted modules now?

Sure, whatever works for you.
Comment 11 Matthias Gerstner 2020-05-25 10:08:09 UTC
(In reply to matthias.gerstner@suse.com from comment #10)
> (In reply to kukuk@suse.com from comment #9)
> > Can we please whitelist the two accepted modules now?
> 
> Sure, whatever works for you.

The pam_usertype whitelisting is on its way via sr#808696. I heard back from
Malte that pam_faillock is getting more complicated, too, however. Therefore I
leave it up to him when it can be whitelisted.
Comment 12 Josef Möllers 2020-05-26 15:22:10 UTC
I have tried reproducing the issue but can't find pam_setquota, neither in SLE15-SP1 nor in TW!
What package did it come from?
Comment 13 Thorsten Kukuk 2020-05-26 15:45:14 UTC
(In reply to Josef Möllers from comment #12)
> I have tried reproducing the issue but can't find pam_setquota, neither in
> SLE15-SP1 nor in TW!
> What package did it come from?

We cannot submit it to Factory as of the new PAM modules, thus it is still only available in the devel project (look at the rpmlint warnings about new PAM modules or your Factory submission).
Comment 15 Matthias Gerstner 2020-05-27 08:53:43 UTC
(In reply to josef.moellers@suse.com from comment #14)
> Thanks. The "VUL-0 EMBARGOED" triggered my alarms, letting me think it was
> already out in the wild, so I was confused when I coudln't find it.

There's no official release with this code, but the code has at least been
published in the upstream GitHub repository. Since our packagers attempted to
push this code into Factory there was a real chance for this vulnerability
to b released in Tumbleweed. Maybe other distros tried/did that, too.
Therefore I like to keep it private for the moment. Once a fix is available a
posting to oss-sec or even a CVE assignment should also be considered to raise
awareness.
Comment 17 Matthias Gerstner 2020-06-04 09:23:50 UTC
Okay this patch should fix the issue. Is this now the offical upstream patch?
Ah I see that you already pushed this upstream. Then I will whitelist this
module. Thanks for your work.
Comment 18 Matthias Gerstner 2020-06-04 09:27:09 UTC
I'm publishing this bug since it is already public upstream as well.

I'm thinking about discussing this issue on the oss-sec mailing list and maybe
contacting libfuse upstream to see whether their fusermount setuid-root
program can be hardened a bit in this regard.
Comment 19 Josef Möllers 2020-06-04 10:02:18 UTC
(In reply to Matthias Gerstner from comment #17)
> Okay this patch should fix the issue. Is this now the offical upstream patch?
> Ah I see that you already pushed this upstream.

I did publish a patch upstream but upstream had a much simpler solution.
Anyway: the local patch is identical to the upstream one.
Comment 20 OBSbugzilla Bot 2020-06-08 08:40:06 UTC
This is an autogenerated message for OBS integration:
This bug (1171721) was mentioned in
https://build.opensuse.org/request/show/812449 Factory / pam
Comment 21 OBSbugzilla Bot 2020-06-08 14:30:06 UTC
This is an autogenerated message for OBS integration:
This bug (1171721) was mentioned in
https://build.opensuse.org/request/show/812631 Factory / pam
Comment 22 Matthias Gerstner 2020-06-12 11:12:12 UTC
So this finding is fixed and the whitelisting for the pam module is also in
place in Factory. I also published the finding on the oss-sec mailing list but
no discussion resulted from this.

What's left is to contact the libfuse devs upstream if they could harden their
fusermount utility in some way. But I have little hope for a simple solution.

Anyways I'm closing this bug for pam_setquota as fixed.