Bug 1193997 - (CVE-2022-23948) VUL-0: CVE-2022-23948: keylime: check_mounted secure mount logic can be fooled by unprivileged mounts
VUL-0: CVE-2022-23948: keylime: check_mounted secure mount logic can be foole...
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Audits
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Security Team bot
Security Team bot
Depends on:
Blocks: 1191739
  Show dependency treegraph
Reported: 2021-12-22 10:54 UTC by Matthias Gerstner
Modified: 2022-02-18 09:52 UTC (History)
2 users (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Gerstner 2021-12-22 10:54:32 UTC
This is to keep track of the keylime review issue 2 a):

 ### a) `check_mounted()` Function Logic can be Fooled by Unprivileged

 The `check_mounted()` function in `secure_mount.py` attempts to make sure
 that a "secure" tmpfs is mounted at `/var/lib/keylime/secure` to store
 data on that never gets written to disk. To do so the function parses the
 output of the `mount` utility to determine whether this file system is
 mounted at the desired location.

 There can exist the possibility of unprivileged users performing certain
 operations, one of the most prominent examples being the `fusermount`
 setuid-root binary for mounting FUSE file systems. In view of this parsing
 mount table output needs prudence. I described the basic issue previously
 already in another report [1].

 The following is a reproducer using `fusermount` that shows the basic local
 attack vector:

     user$ export _FUSE_COMMFD=0
     user$ fusermount some/path/ -ononempty,fsname="tmpfs on

 This will fool the parsing logic in `check_mounted()` and thus the function
 assumes that the "secure" tmpfs is already mounted, while it actually
 Thus this will allow a local attacker on the system to prevent this
 feature to be effective, *if* the local attacker manages to create such a
 entry before the `keylime_agent` runs.

 The attack vector can also be used to perform a local DoS against
 `keylime_agent` by claiming a different `fsname` than tmpfs.
 will throw an Exception in this case and the agent won't start.

 On a side note there are calls to `secure_mount.mount()` spread throughout
 Keylime codebase (for example three times in `keylime_agent.py`, two times

 `tpm_main.py` and two times in `ca_impl_cfssl.py`. There is no code to
 up* this mount again, however. So it potentially leaves behind a stale
 after services are shutdown. Furthermore if multiple Keylime processes
 operate in parallel this could result in a race condition where the
 tmpfs is mounted twice, in the worst case mounting a fresh tmpfs over
 previously stored content there.

 My recommendation is to parse the `/proc/self/mountinfo` pseudo file for
 table information instead. Whitespace is specially encoded in this file.
 Furthermore the responsibility of mounting and unmounting this file system
 should be more clearly defined during startup/shutdown of processes and
 a reference counting / locking scheme to prevent race conditions should be

 [1]: https://www.openwall.com/lists/oss-security/2020/06/04/5
Comment 1 Matthias Gerstner 2022-01-26 09:20:48 UTC
The issue has been confirmed by upstream and CVE-2022-23948 has been assigned.
Comment 3 Matthias Gerstner 2022-01-28 09:29:43 UTC
the issue is public now via the following security advisory:

Comment 4 Gianluca Gabrielli 2022-02-18 09:52:33 UTC
Fixed in version 6.3.0 and both SLE-15-SP4 and Factory are updated.