Bugzilla – Bug 1171721
VUL-0: pam: pam_setquota.so can be tricked to operate on arbitrary block devices by using fusermount
Last modified: 2023-04-06 09:47:21 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.
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
(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.
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.
(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.
(In reply to kukuk@suse.com from comment #9) > Can we please whitelist the two accepted modules now? Sure, whatever works for you.
(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.
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?
(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).
(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.
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.
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.
(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.
This is an autogenerated message for OBS integration: This bug (1171721) was mentioned in https://build.opensuse.org/request/show/812449 Factory / pam
This is an autogenerated message for OBS integration: This bug (1171721) was mentioned in https://build.opensuse.org/request/show/812631 Factory / pam
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.