Thanks Debora, please let me know if you need any help in the CVE assignment process and I'll be glad to help!
Marco Benatto Red Hat Product Security [email protected] for urgent response On Tue, Aug 4, 2020 at 4:43 PM Debora Velarde Babb <[email protected]> wrote: > > On Mon, 2020-08-03 at 12:32 -0300, Marco Benatto wrote: > > 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 > > > > Not yet but I am working on creating a CVE and committing the patches. > This is my first time creating a CVE so trying to understand the > process. > > Thanks, > Debbie > > > 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 > > _______________________________________________ TrouSerS-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/trousers-tech
