Hello, Is there any follow up already for this issue in upstream (CVE assigned or upstream commits)?
Thanks, Marco Benatto Red Hat Product Security [email protected] for urgent response On Wed, May 20, 2020 at 9:55 AM Matthias Gerstner <[email protected]> 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 [email protected], > the security contact of the project according to the README file > [2]. > 2020-02-28: I reported findings a), b) and d) to [email protected], the > maintainer of the project according to the AUTHORS file [3]. > 2020-03-16: I received a reply from [email protected], stating that she > will look into the findings. > 2020-05-06: I reminded [email protected] 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 > > -- > Matthias Gerstner <[email protected]> > Dipl.-Wirtsch.-Inf. (FH), Security Engineer > https://www.suse.com/security > Phone: +49 911 740 53 290 > GPG Key ID: 0x14C405C971923553 > > SUSE Software Solutions Germany GmbH > HRB 36809, AG Nürnberg > Geschäftsführer: Felix Imendörffer > _______________________________________________ TrouSerS-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/trousers-tech
