Re: fscrypt: Multiple File System Related Security Issues (CVE-2022-25326, CVE-2022-25327, CVE-2022-25328)

[Eric Biggers <ebiggers () kernel org>]

On Thu, Feb 24, 2022 at 12:33:18PM +0100, Matthias Gerstner wrote:
> Hello list,
>
> in the context of a request to include Fscrypt [1] into openSUSE Tumbleweed
> a routine review of the package was required, as it contains a PAM module.
> In the course of the review I discovered a number of file system management
> related security issues.
>
> I have been reviewing Fscrypt version 0.3.1. Shortly later 0.3.2 got
> released, with minor changes in the PAM module but some more changes in
> other areas. All issues and source code locations mentioned in this report
> relate to the upstream version tag v0.3.1. Most of the findings are also
> valid for 0.3.2, however.
>
> All acknowledged issues mentioned in this report have been addressed in the
> new Fscrypt upstream release version v0.3.3.

Thanks for doing a security review and reporting all of these!

To provide some extra context for readers: "fscrypt" here refers to the
userspace tool https://github.com/google/fscrypt, not to the kernel side of
Linux native filesystem encryption which is also sometimes called fscrypt
(https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html).  These
vulnerabilities only affected the userspace tool.  Also, these are not
cryptographic vulnerabilities.

One correction below:

> 5.i) Another User can Cause a Foreign Key to be Applied to its own File System
> ------------------------------------------------------------------------------
>
> Let's consider a malicious local user that has control over the root directory
> of some mounted file system e.g. let's consider its own home directory is a
> separate mount. Then this malicious user can do this:
>
>     $ ln -s /.fscrypt /home/$USER/.fscrypt
>
> Actually a copy of all the files should also suffice. That Fscrypt is
> following symlinks is an extra degree of freedom that is exploited here. The
> `filesystem/CheckSetup()` function does only check the mode bits of the
> involved directories, but not the actual *owners*, therefore a plain copy of
> the directories and files would also be working.
>
> Now when another user unlocks its Protector via the PAM module, the module
> will also look into other file systems and since a matching policy will be
> found for /home/$USER, the following (strace) happens (with $USER = attacker):
>
>     openat(AT_FDCWD, "/home/attacker", O_RDONLY|O_CLOEXEC) = 4
>     ioctl(4, FS_IOC_ADD_ENCRYPTION_KEY, 0x7f2738d29000) = 0
>
> So the encryption key is added to a completely unrelated file system. The
> attacking user does not seem to have the ability to take advantage of this,
> because the key cannot be retrieved back and the ciphertext of the
> originally encrypted data can also not easily be duplicated on the other file
> system to have the kernel decrypt it.
>
> Upstream acknowledges this issue but doesn't see an attack vector in it,
> because the attacker cannot take any advantage of it.

I believe this one did get addressed by
https://github.com/google/fscrypt/commit/85a747493ff368a72f511619ecd391016ecb933c
("Extend ownership validation to entire directory structure").  With that, by
default pam_fscrypt will only consider filesystems whose root directory is owned
by root or by the user logging in.

- Eric