Re: [TrouSerS-tech] Multiple Security Issues in the TrouSerS tpm1.2 tscd Daemon

[Debora Velarde Babb <debora () linux ibm com>]

For anyone wanting to try the patches..
After applying the patches, rebuilding and installing the swtpm,
trousers, and tpm-tools, I had to manually do the following (which the
patched code is looking for):
# chown root /usr/local/etc/tcsd.conf
# chmod 0640 /usr/local/etc/tcsd.conf

On my end, so far things seem to be functioning as expected now.

Thanks,
Debbie

On Wed, 2020-05-20 at 14:54 +0200, Matthias Gerstner wrote:
> Hello,
>
> I have discovered multiple security issues in the tcsd daemon of the
> TrouSerS
> [1] tpm 1.2 stack.
>
> Introduction
> ============
>
> The tcsd daemon manages access to the tpm 1.2 compliant /dev/tpm0
> device on
> Linux systems. The daemon utilizes an unprivileged user and group
> account to
> run as. These are called tss:tss by default.
>
> The tcsd can be started directly as the tss user and group e.g. via
> systemd or
> via start-stop-daemon. In this case the /dev/tpm0 device needs to be
> owned by
> the tss user. This mode of operation is safe and is not affected by
> the
> following findings.
>
> If the tcsd is started with root privileges then it opens /dev/tpm0
> as root
> and drops privileges to the unprivileged user afterwards. In this
> case the tss
> user can achieve privilege escalations. The following logic is
> performed by
> the tcsd:
>
> 1) the daemon reads in the configuration in /etc/tcsd.conf after
> making sure
>   that the config file is owned by tss:tss mode 0600 (function
>   `conf_file_init()`). From this configuration file the path
> `system_ps_file`
>   (by default /var/lib/tpm/system.data) is parsed and used for
> further
>   operations.
>
> 2) the daemon makes sure that the directory where the
> `system_ps_file` is
>   contained in exists (function `ps_dirs_init()`, /var/lib/tpm by
> default).
>   The directory is created, if necessary, using `mkdir()` and mode
> 0700.
>   Afterwards an explicit `chown()` to mode 0700 is made in case the
> mode of
>   the directory doesn't match this mode yet.
>
> 3) in the function `ps_init_disk_cache()` the function `get_file()`
> is called
>   which opens the `system_ps_file` using `O_RDWR|O_CREAT` and mode
> 0600:
>
>   `openat(AT_FDCWD, "/var/lib/tpm/system.data", O_RDWR|O_CREAT, 0600)
> = 4`
>
> 4) only after these steps a privilege drop to the tss uid is
> performed in
>    the `main()` function.
>
> Security Issues
> ===============
>
> The security issues resulting from this are as follows:
>
> a) Since /var/lib/tpm is owned by the tss user (as per
> dist/Makefile.am), the
>    creation of the `system.data` file in step 3) is prone to symlink
> attacks. The
>    tss user can thereby cause the creation of new files or the
> corruption of
>    existing files. These new files end up with mode 0600 and no
> `chown()` to the
>    tss user is performed by the tcsd. Thus it looks like no full
> local root
>    privilege escalation can be achieved but only DoS attacks.
>
> b) The tcsd only drops the root uid, not the root gid in step 4). A
> call to
>    `setgid()` is missing. Therefore the tcsd continues to run with
> root group
>    privileges it doesn't actually require. This could allow further
> privilege
>    escalations when combined with other, yet unknown attack vectors.
>
> c) The configuration file /etc/tcsd.conf is _required_ by the tcsd to
> be
>    owned by tss:tss mode 0600. Therefore the unprivileged user can
> change all
>    daemon related settings, including the `system_ps_file` path. This
> means
>    the `mkdir()` and `chmod()` performed in step 2) can be directed
> to an
>    arbitrary path. This also includes the symlink attack described in
> a)
>    for arbitrary paths.
>
>    Further security issues could stem from this by manipulating other
> config
>    file options. I did not look deeper into this.
>
> d) Not directly related to the logic above. The example RPM spec file
> [5] in
>    the TrouSerS repository is using unsafe file and directory modes
> for
>    /var/lib/tpm and /usr/sbin/tcsd:
>
>    ```
>    # create the default location for the persistent store files
>    if test -e %{_localstatedir}/tpm; then
>         mkdir -p %{_localstatedir}/tpm
>         /bin/chown tss:tss %{_localstatedir}/tpm
>         /bin/chmod 1777 %{_localstatedir}/tpm
>    fi
>
>    # chown the daemon
>    /bin/chown tss:tss %{_sbindir}/tcsd
>    ```
>
>    So here a public sticky-bit directory is setup in /var/lib/tpm.
> This could
>    allow arbitrary users to setup the symlink attack mentioned in a).
> It could
>    also lead to an information leak. Once the tcsd is started as root
> the mode
>    of /var/lib/tpm will be corrected in step 1), however.
>
>    Passing ownership of /usr/sbin/tcsd to the tss user would allow
> the tss
>    user to replace the tcsd binary by malicious code that will
> potentially be
>    executed by the root user, leading to arbitrary code execution.
>
>    I'm not aware of any distribution actually using this spec file or
> parts of
>    it. Still it is a very bad example.
>
> Mitigation and Bugfixes
> =======================
>
> It seems best to me to run the tcsd as the tss:tss user and group
> right away
> and to not rely on the privilege drop logic implemented in the daemon
> itself.
> All of a), b) and c) should no longer be problematic in this case. I
> found
> that on Debian and Gentoo Linux this is already the case. To make
> this work a
> udev rule needs to be packaged that passes ownership of /dev/tpm0
> device to
> the tss user. To prevent regressions when switching from the
> privilege drop
> approach to this new approach, a possibly already existing
> /var/lib/tpm/system.auth file needs to be safely chown()'ed to the
> tss user
> during package updates.
>
> On SUSE and Fedora Linux the tcsd is started as root via systemd,
> thus they
> are affected by the security issues. A preliminary suggested source
> code fix
> is attached to this mail. It makes sure that `O_NOFOLLOW` is added to
> step 3)
> to prevent a symlink attack. It also adds a drop of the root gid to
> the tss
> gid. And it modifies the check of /etc/tcsd.conf such that ownership
> root:tss
> and mode 0640 are necessary. The packaging needs to be adjusted
> accordingly.
>
> The correct long term fix should probably be to *only* open /dev/tpm0
> as root,
> immediately drop to tss:tss and only then perform the further
> initialization
> steps. The initialization sequence in `tcsd_startup()` is currently
> running
> completely in the root user context and seems rather complex. Maybe
> there are
> more details to this that I don't know of yet. For this reason I
> didn't try a
> patch in this direction yet.
>
> Upstream Reporting
> ==================
>
> I reported issues a), b) and d) privately to the documented upstream
> contacts
> without much success (see Timeline below). The SUSE Security Team 90
> days
> maximum disclosure time has been reached, therefore I'm publishing
> this now in
> an uncoordinated way. While working on a fix I additionally
> discovered issue
> c). SUSE is tracking the issues in bsc#1164472 [6] currently.
>
> Issues a), b) and c) deserve CVE assignments in my opinion. I can't
> request
> CVEs myself though, because IBM upstream is a CNA themselves.
> Therefore
> upstream is required to assign their own CVEs.
>
> Timeline
> ========
>
> 2020-02-19: I reported findings a), b) and d) to 
> honclo () linux vnet ibm com,
>             the security contact of the project according to the
> README file [2].
> 2020-02-28: I reported findings a), b) and d) to debora () linux ibm com
> , the
>             maintainer of the project according to the AUTHORS file
> [3].
> 2020-03-16: I received a reply from debora () linux ibm com, stating
> that she
>             will look into the findings.
> 2020-05-06: I reminded debora () linux ibm com that the latest
> disclosure time
>             [4] for the findings is approaching and asked for any
> updates.
> 2020-05-20: I started working on a bugfix and mitigations, discovered
> the
>             additional finding c) and started publishing the
> findings.
>
> [1]: https://sourceforge.net/projects/trousers
> [2]: 
> https://sourceforge.net/p/trousers/trousers/ci/master/tree/README
> [3]: 
> https://sourceforge.net/p/trousers/trousers/ci/master/tree/AUTHORS
> [4]: https://en.opensuse.org/openSUSE:Security_disclosure_policy
> [5]: 
> https://sourceforge.net/p/trousers/trousers/ci/master/tree/dist/trousers.spec.in
> [6]: https://bugzilla.suse.com/show_bug.cgi?id=1164472
>
> Best Regards
>
> Matthias
>
> _______________________________________________
> TrouSerS-tech mailing list
> TrouSerS-tech () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/trousers-tech