trousers-tech — Discussion on the design/implementation details of trousers

[TrouSerS-tech] Pending patches

[Oldřich J. <old...@gm...>]

Hi,

I see that there is a new version released of tpm-utils from time to
time. Would it be possible to incorporate some patches from CentOS
[1], please? I see that the patches were sent to this mailing list
too, but without much attention.

I have TPM 1.2 on my 7-years old backup server and I just faced a
problem with tpm_version, which outputs garbage to stderr as reported
in 2018 actually. Getting this then to Debian would be really great
:-)

[1] https://git.centos.org/rpms/tpm-tools/blob/c8s/f/SOURCES

Best regards,
Oldrich.

Re: [TrouSerS-tech] [TrouSerS-users] Request for info: trousers on future distros

[David C. <dav...@gm...>]

I think the need will exist for at least another 5 years.

On Fri, Jul 23, 2021 at 8:51 AM Ken Goldman <kgo...@us...> wrote:

> > On Wed, 14 Jul 2021, Debora Velarde Babb wrote:
> >> We would like to hear from users that have applications that are
> >> dependent on TPM 1.2.  This will be used to help determine whether or
> >> not to include TrouSerS in newer Linux distro releases. If you do have
> >> a continued need for trousers, but downloading it from sourceforge and
> >> building it yourself is sufficient for your needs, that would also be
> >> helpful to know.
>
> My guess is that the end will come for trousers when the distros move
> to a version of openssl that removes the low level APIs.
>
> Even now, when they're deprecated, some functions fail.  So
> some porting will be required for openssl 3.0
>
>
> _______________________________________________
> TrouSerS-users mailing list
> Tro...@li...
> https://lists.sourceforge.net/lists/listinfo/trousers-users
>

Re: [TrouSerS-tech] Request for info: trousers on future distros

[Ken G. <kgo...@us...>]

> On Wed, 14 Jul 2021, Debora Velarde Babb wrote:
>> We would like to hear from users that have applications that are
>> dependent on TPM 1.2.  This will be used to help determine whether or
>> not to include TrouSerS in newer Linux distro releases. If you do have
>> a continued need for trousers, but downloading it from sourceforge and
>> building it yourself is sufficient for your needs, that would also be
>> helpful to know. 

My guess is that the end will come for trousers when the distros move
to a version of openssl that removes the low level APIs.

Even now, when they're deprecated, some functions fail.  So
some porting will be required for openssl 3.0

Re: [TrouSerS-tech] Request for info: trousers on future distros

[Timo L. <tim...@ik...>]

Hi,

On Wed, 14 Jul 2021, Debora Velarde Babb wrote:
> We would like to hear from users that have applications that are
> dependent on TPM 1.2.  This will be used to help determine whether or
> not to include TrouSerS in newer Linux distro releases. If you do have
> a continued need for trousers, but downloading it from sourceforge and
> building it yourself is sufficient for your needs, that would also be
> helpful to know.

I can say that compiling software manually like that is a major problem 
for commercial users. The benefits for having TPM 1.2 support in 
the distributions is quite clear in my opinion as they don't need to 
review the licensing terms on their own, handle updates manually and can 
report packaging bugs. Overall this results in more secure solutions. Now 
that TPM usage is slowly gathering momentum itwould be really shame to
drop the support before we really have TPM 2.0 on most existing systems.

I'm packaging tboot for Debian. I could perhaps also help with Debian 
packaging of trousers if needed.

-Timo

[TrouSerS-tech] Request for info: trousers on future distros

[Debora V. B. <de...@li...>]

Greetings,

We are trying to gauge the continued interest/need for trousers in
newer Linux distro versions.  

TrouSerS only supports TPM 1.2.  Most newer systems now have TPM 2.0.

There are multiple software stack options for the TPM 2.0.  One such
option being the IBM TSS project:
https://sourceforge.net/projects/ibmtpm20tss/

We would like to hear from users that have applications that are
dependent on TPM 1.2.  This will be used to help determine whether or
not to include TrouSerS in newer Linux distro releases. If you do have
a continued need for trousers, but downloading it from sourceforge and
building it yourself is sufficient for your needs, that would also be
helpful to know.

Thank you,
Debora

Debora Velarde Babb
IBM Linux Security Team
de...@li...

Re: [TrouSerS-tech] [Patch 0/1] tcsd: Check return values of setgid and setuid calls

[Debora V. B. <de...@li...>]

On Wed, 2020-11-18 at 15:28 -0700, Jerry Snitselaar wrote:
> Hi Debora,
> 
> This came up in a coverity scan, so I thought I'd send a patch
> for it. One thing that people should note is that with tcsd now
> calling setgid, for systems using selinux there needs to be a
> capability added for tcsd to allow setgid. I'm working to get
> that into the upstream selinux-policy-contrib project.
> 
> Without this change tcsd will run on an selinux enforcing system,
> but the group will still be root. With this change, and without
> an updated selinux policy tcsd will exit when the setgid fails
> to change the group to tss.
> 
> Regards,
> Jerry
> 
> 

Thank you, Jerry.

Are you suggesting that I go ahead and accept the patch to upstream
now?  Or wait until the selinux policy is updated?  

Thanks,
Debbie

[TrouSerS-tech] [Patch 0/1] tcsd: Check return values of setgid and setuid calls

[Jerry S. <jsn...@re...>]

Hi Debora,

This came up in a coverity scan, so I thought I'd send a patch
for it. One thing that people should note is that with tcsd now
calling setgid, for systems using selinux there needs to be a
capability added for tcsd to allow setgid. I'm working to get
that into the upstream selinux-policy-contrib project.

Without this change tcsd will run on an selinux enforcing system,
but the group will still be root. With this change, and without
an updated selinux policy tcsd will exit when the setgid fails
to change the group to tss.

Regards,
Jerry

[TrouSerS-tech] [PATCH 1/1] tcsd: Check return values of setgid and setuid calls.

[Jerry S. <jsn...@re...>]

Fix up coverity scan complaint about setgid return not being checked.

Signed-off-by: Jerry Snitselaar <jsn...@re...>
---
 src/tcsd/svrside.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/tcsd/svrside.c b/src/tcsd/svrside.c
index 1c12ff3afdd0..08d3d225b042 100644
--- a/src/tcsd/svrside.c
+++ b/src/tcsd/svrside.c
@@ -473,8 +473,14 @@ main(int argc, char **argv)
 		}
 		return TCSERR(TSS_E_INTERNAL_ERROR);
 	}
-	setgid(pwd->pw_gid);
-	setuid(pwd->pw_uid);
+	if (setgid(pwd->pw_gid)) {
+		LogError("setgid() failed: %s", strerror(errno));
+		return TCSERR(TSS_E_INTERNAL_ERROR);
+	}
+	if (setuid(pwd->pw_uid)) {
+		LogError("setuid() failed: %s", strerror(errno));
+		return TCSERR(TSS_E_INTERNAL_ERROR);
+	}
 #endif
 #endif
 
-- 
2.27.0

[TrouSerS-tech] trousers-0.3.15 and tpm-tools-1.3.9.2 released

[Debora V. B. <de...@li...>]

A new version of TrouSerS-0.3.15 and tpm-tools-1.3.9.2 is now available
for download.  

Changes to this version include:
* Fixes for security issues that existed if the tcsd is started by root
instead of the tss user
* Fixed multiple potential instances of use after free memory handling
* Replacing the use of _no_optimize with asm memory barrier
* Removed unused global variables which caused build issue on some
distros
* tpm-tools support for PCRs 15-23 for sealing data
* tpm-tools fix for building with OpenSSL 1.1
* Manpage cleanup


Many thanks to everyone who contributed!

Debora Velarde Babb
IBM Linux Security

[TrouSerS-tech] [GIT] Trousers master branch created. TROUSERS_0_3_15

[debora <dve...@us...>]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Trousers".

The annotated tag, TROUSERS_0_3_15 has been created
        at  9a2b868cc4c2a33e4574f2cc512595b539664fd6 (tag)
   tagging  94144b0a1dcef6e31845d6c319e9bd7357208eb9 (commit)
  replaces  TROUSERS_0_3_14
 tagged by  Debora Velarde Babb
        on  Tue Nov 3 04:30:44 2020 -0800

- Log -----------------------------------------------------------------
TROUSERS_0_3_15

Debora Velarde Babb (2):
      Merge branch 'master' of ssh://git.code.sf.net/p/trousers/trousers
      Bumped version to 0.3.15

George McCollister (1):
      dist: install tcsd.conf as root:tss 0640

Jerry Snitselaar (5):
      trousers: resolve build failure
      trousers: clean up use after free in Transport_TerminateHandle
      trousers: clean up use after free in Transport_TerminateHandle
      trousers: fix potential use after free in ima_get_entry
      trousers: don't use __no_optimize

Matthias Gerstner (1):
      Correct multiple security issues that are present if the tcsd

-----------------------------------------------------------------------


hooks/post-receive
-- 
Trousers

Re: [TrouSerS-tech] [PATCH] dist: install tcsd.conf as root:tss 0640

[Debora V. B. <de...@li...>]

On Thu, 2020-10-29 at 15:51 -0500, George McCollister wrote:
> Install tcsd.conf as root:tss 0640 since as of commit
> e74dd1d96753b0538192143adf58d04fcd3b242b that's what tcsd_conf.c
> requires it to be.
> 
> Signed-off-by: George McCollister <geo...@gm...>
> ---
>  dist/Makefile.am | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/dist/Makefile.am b/dist/Makefile.am
> index 372736a..9e8269a 100644
> --- a/dist/Makefile.am
> +++ b/dist/Makefile.am
> @@ -4,8 +4,8 @@ EXTRA_DIST = system.data.auth system.data.noauth \
>  install: install-exec-hook
>  	if test ! -e ${DESTDIR}/@sysconfdir@/tcsd.conf; then mkdir -p 
> ${DESTDIR}/@sysconfdir@ && cp tcsd.conf ${DESTDIR}/@sysconfdir@; fi
>  if !NOUSERCHECK
> -	/bin/chown tss:tss ${DESTDIR}/@sysconfdir@/tcsd.conf || true
> -	/bin/chmod 0600 ${DESTDIR}/@sysconfdir@/tcsd.conf
> +	/bin/chown root:tss ${DESTDIR}/@sysconfdir@/tcsd.conf || true
> +	/bin/chmod 0640 ${DESTDIR}/@sysconfdir@/tcsd.conf
>  endif
>  
>  install-exec-hook:

Thank you for the patch.  Committed.

Thanks,
Debbie

[TrouSerS-tech] [PATCH] dist: install tcsd.conf as root:tss 0640

[George M. <geo...@gm...>]

Install tcsd.conf as root:tss 0640 since as of commit
e74dd1d96753b0538192143adf58d04fcd3b242b that's what tcsd_conf.c
requires it to be.

Signed-off-by: George McCollister <geo...@gm...>
---
 dist/Makefile.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/dist/Makefile.am b/dist/Makefile.am
index 372736a..9e8269a 100644
--- a/dist/Makefile.am
+++ b/dist/Makefile.am
@@ -4,8 +4,8 @@ EXTRA_DIST = system.data.auth system.data.noauth \
 install: install-exec-hook
 	if test ! -e ${DESTDIR}/@sysconfdir@/tcsd.conf; then mkdir -p ${DESTDIR}/@sysconfdir@ && cp tcsd.conf ${DESTDIR}/@sysconfdir@; fi
 if !NOUSERCHECK
-	/bin/chown tss:tss ${DESTDIR}/@sysconfdir@/tcsd.conf || true
-	/bin/chmod 0600 ${DESTDIR}/@sysconfdir@/tcsd.conf
+	/bin/chown root:tss ${DESTDIR}/@sysconfdir@/tcsd.conf || true
+	/bin/chmod 0640 ${DESTDIR}/@sysconfdir@/tcsd.conf
 endif
 
 install-exec-hook:
-- 
2.11.0

[TrouSerS-tech] Call for patches before final release

[Debora V. B. <de...@li...>]

Greetings all,

I am planning to create a new release of TrouSerS and tpm-tools soon. 
Please send me any patches to be included by Oct 27th. If you are
working on a patch and need more time, please let me know.

Barring any security issues discovered, this will be the last planned
release of TrouSerS and tpm-tools.  If possible, please go ahead and
test the current master branch on your platform to ensure the next
release works well for you.

Thank you,
Debbie

[TrouSerS-tech] [PATCH trousers] man3/Tspi_Data_Seal: fix mann[ae]r typo

[наб <nab...@na...>]

Signed-Off-By: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
Please keep me in CC, as I'm not subscribed

 man/man3/Tspi_Data_Seal.3 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/man/man3/Tspi_Data_Seal.3 b/man/man3/Tspi_Data_Seal.3
index 69b6f6d..bfe49f1 100644
--- a/man/man3/Tspi_Data_Seal.3
+++ b/man/man3/Tspi_Data_Seal.3
@@ -21,7 +21,7 @@
 ..
 .TH "Tspi_Data_Seal" 3 "2004-05-26" "TSS 1.1" "TCG Software Stack Developer's Reference"
 .SH NAME
-Tspi_Data_Seal \- encrypt a data blob in a mannar that is only decryptable by Tspi_Data_Unseal on the same system.
+Tspi_Data_Seal \- encrypt a data blob in a manner that is only decryptable by Tspi_Data_Unseal on the same system.
 .SH "SYNOPSIS"
 .ad l
 .hy 0
@@ -44,7 +44,7 @@ Tspi_Data_Seal \- encrypt a data blob in a mannar that is only decryptable by Ts
 
 .SH "DESCRIPTION"
 .PP
-\fBTspi_Data_Seal\fR encrypts a data blob in a mannar that is only decryptable by Tspi_Data_Unseal on the same system. The data blob is encrypted using a public key operation with the nonmigratable key addressed by the given encryption key object.
+\fBTspi_Data_Seal\fR encrypts a data blob in a manner that is only decryptable by Tspi_Data_Unseal on the same system. The data blob is encrypted using a public key operation with the nonmigratable key addressed by the given encryption key object.
 .SH "PARAMETERS"
 .PP
 .SS hEncData
-- 
2.28.0

Re: [TrouSerS-tech] [PATCH] Support using PCRs 15-24 for sealing data

[Debora V. B. <de...@li...>]

On Mon, 2020-10-05 at 21:28 +0300, Timo Lindfors wrote:
> Hi,
> 
> On Thu, 1 Oct 2020, Debora Velarde Babb wrote:
> > This patch has been committed to the master branch.  If you could
> > please try the master branch and check that it works okay for you
> > now.
> 
> Thanks, this seems to work on a Lenovo T430s laptop.
> 
> -Timo
> 

Thank you for testing it.

-Debbie

Re: [TrouSerS-tech] [PATCH] Support using PCRs 15-24 for sealing data

[Timo L. <tim...@ik...>]

Hi,

On Thu, 1 Oct 2020, Debora Velarde Babb wrote:
> This patch has been committed to the master branch.  If you could
> please try the master branch and check that it works okay for you now.

Thanks, this seems to work on a Lenovo T430s laptop.

-Timo

Re: [TrouSerS-tech] [PATCH] Support using PCRs 15-24 for sealing data

[Debora V. B. <de...@li...>]

On Sat, 2020-08-15 at 17:04 +0300, Timo Lindfors wrote:
> Hi,
> 
> On Thu, 25 Jul 2019, Debora Velarde Babb wrote:
> > On Thu, 2019-07-25 at 07:42 +0300, Timo Lindfors wrote:
> > > On Wed, 10 Jul 2019, Ken Goldman wrote:
> > > > On 7/3/2019 7:20 AM, Timo Juhani Lindfors wrote:
> > > > 
> > > > >   -		if (pcr > 15) {
> > > > > -			logError(_("Cannot seal NVRAM area to
> > > > > PCR >
> > > > > 15\n"));
> > > > > +		if (pcr > 24) {
> > > > > +			logError(_("Cannot seal NVRAM area to
> > > > > PCR >
> > > > > 24\n"));
> > > > >   			goto out;
> > > > 
> > > > Assuming that pcr is zero based, should this be "> 23"?
> > 
> > No, the mailing list is working okay.  I just got back from
> > vacation
> > and had this email in the mailing list queue awaiting approval to
> > be
> > posted to the list.   Sorry for the confusion.
> 
> I realize TPM 1.2 support is not getting much attention lately but
> could 
> you please consider merging this patch? Without it is not possible to
> seal 
> data to PCRs 15-24 that are needed with DRTM. I'm happy to change
> this 
> patch and if there is something fundamentally wrong I'm of course
> ready to 
> switch to some other tool as well if that makes sense. It is just
> that 
> there are still quite many TPM 1.2 systems in use that I'd like to 
> support.
> 
> -Timo
> 
> 
> 
> _______________________________________________
> TrouSerS-tech mailing list
> Tro...@li...
> https://lists.sourceforge.net/lists/listinfo/trousers-tech


This patch has been committed to the master branch.  If you could
please try the master branch and check that it works okay for you now.

Thanks,
Debbie

[TrouSerS-tech] [PATCH] trousers: indentation cleanup

[Jerry S. <jsn...@re...>]

Fix up a couple spots where indentation was off.

Signed-off-by: Jerry Snitselaar <jsn...@re...>
---
 src/tspi/obj_policy.c | 2 +-
 src/tspi/tspi_key.c   | 9 +++++----
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/tspi/obj_policy.c b/src/tspi/obj_policy.c
index 19c4b22cbbed..80e9fe23e4af 100644
--- a/src/tspi/obj_policy.c
+++ b/src/tspi/obj_policy.c
@@ -984,7 +984,7 @@ obj_policy_get_xsap_params(TSS_HPOLICY hPolicy,
 					      policy->popupString,
 					      policy->Secret)))
 			goto done;
-			policy->SecretSet = TRUE;
+		policy->SecretSet = TRUE;
 	}	
 	memcpy(secret, policy->Secret, TPM_SHA1_160_HASH_LEN);
 	*mode = policy->SecretMode;
diff --git a/src/tspi/tspi_key.c b/src/tspi/tspi_key.c
index aa4df5067b0c..9352abc8a57b 100644
--- a/src/tspi/tspi_key.c
+++ b/src/tspi/tspi_key.c
@@ -370,10 +370,11 @@ Tspi_Key_WrapKey(TSS_HKEY hKey,			/* in */
 	/* get the key to be wrapped's private key */
 	if ((result = obj_rsakey_get_priv_blob(hKey, &keyPrivBlobLen, &keyPrivBlob)))
 		goto done;
-    /* verify if its under the maximum size, according to the
-     * TPM_STORE_ASYMKEY specification */
-    if (keyPrivBlobLen > TPM_STORE_PRIVKEY_LEN)
-        return TSPERR(TSS_E_ENC_INVALID_LENGTH);
+
+	/* verify if its under the maximum size, according to the
+	 * TPM_STORE_ASYMKEY specification */
+	if (keyPrivBlobLen > TPM_STORE_PRIVKEY_LEN)
+		return TSPERR(TSS_E_ENC_INVALID_LENGTH);
 
 	/* get the key to be wrapped's blob */
 	if ((result = obj_rsakey_get_blob(hKey, &keyBlobLen, &keyBlob)))
-- 
2.27.0

Re: [TrouSerS-tech] [PATCH] Support using PCRs 15-24 for sealing data

[Debora V. B. <de...@li...>]

On Sat, 2020-08-15 at 17:04 +0300, Timo Lindfors wrote:
> Hi,
> 
> On Thu, 25 Jul 2019, Debora Velarde Babb wrote:
> > On Thu, 2019-07-25 at 07:42 +0300, Timo Lindfors wrote:
> > > On Wed, 10 Jul 2019, Ken Goldman wrote:
> > > > On 7/3/2019 7:20 AM, Timo Juhani Lindfors wrote:
> > > > 
> > > > >   -		if (pcr > 15) {
> > > > > -			logError(_("Cannot seal NVRAM area to
> > > > > PCR >
> > > > > 15\n"));
> > > > > +		if (pcr > 24) {
> > > > > +			logError(_("Cannot seal NVRAM area to
> > > > > PCR >
> > > > > 24\n"));
> > > > >   			goto out;
> > > > 
> > > > Assuming that pcr is zero based, should this be "> 23"?
> > 
> > No, the mailing list is working okay.  I just got back from
> > vacation
> > and had this email in the mailing list queue awaiting approval to
> > be
> > posted to the list.   Sorry for the confusion.
> 
> I realize TPM 1.2 support is not getting much attention lately but
> could 
> you please consider merging this patch? Without it is not possible to
> seal 
> data to PCRs 15-24 that are needed with DRTM. I'm happy to change
> this 
> patch and if there is something fundamentally wrong I'm of course
> ready to 
> switch to some other tool as well if that makes sense. It is just
> that 
> there are still quite many TPM 1.2 systems in use that I'd like to 
> support.
> 
> -Timo
> 
> 

Hi Tim,

I am testing this now and should hopefully be committing it shortly.

Thanks,
Debbie

> 
> _______________________________________________
> TrouSerS-tech mailing list
> Tro...@li...
> https://lists.sourceforge.net/lists/listinfo/trousers-tech

Re: [TrouSerS-tech] [PATCH] Support using PCRs 15-24 for sealing data

[Timo L. <tim...@ik...>]

Hi,

On Thu, 25 Jul 2019, Debora Velarde Babb wrote:
> On Thu, 2019-07-25 at 07:42 +0300, Timo Lindfors wrote:
>> On Wed, 10 Jul 2019, Ken Goldman wrote:
>>> On 7/3/2019 7:20 AM, Timo Juhani Lindfors wrote:
>>>
>>>>   -		if (pcr > 15) {
>>>> -			logError(_("Cannot seal NVRAM area to PCR >
>>>> 15\n"));
>>>> +		if (pcr > 24) {
>>>> +			logError(_("Cannot seal NVRAM area to PCR >
>>>> 24\n"));
>>>>   			goto out;
>>>
>>> Assuming that pcr is zero based, should this be "> 23"?
>>
> No, the mailing list is working okay.  I just got back from vacation
> and had this email in the mailing list queue awaiting approval to be
> posted to the list.   Sorry for the confusion.

I realize TPM 1.2 support is not getting much attention lately but could 
you please consider merging this patch? Without it is not possible to seal 
data to PCRs 15-24 that are needed with DRTM. I'm happy to change this 
patch and if there is something fundamentally wrong I'm of course ready to 
switch to some other tool as well if that makes sense. It is just that 
there are still quite many TPM 1.2 systems in use that I'd like to 
support.

-Timo

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

[Debora V. B. <de...@li...>]

On Wed, 2020-05-20 at 14:54 +0200, Matthias Gerstner wrote:
> 
> 
> 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.

CVE-2020-24332 is assigned to issue a)

[Suggested description]
An issue was discovered in TrouSerS through 0.3.14.
If the tcsd daemon is started with root privileges, the creation of
the system.data file is prone to symlink attacks. The tss user can be
used to create or corrupt existing files, which could possibly lead to
a DoS attack.

> 
> 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.

CVE-2020-24330 assigned to security issue b)

[Suggested description]
An issue was discovered in TrouSerS through 0.3.14.
If the tcsd daemon is started with root privileges instead of by the
tss user, it fails to drop the root gid privilege when
no longer needed.

> 
> 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.

CVE-2020-24331 is assigned to security issue c)

[Suggested description]
An issue was discovered in TrouSerS through 0.3.14.
If the tcsd daemon is started with root privileges, the tss user still
has read and write access to the /etc/tcsd.conf file (which contains
various settings related to this daemon).


> 
> 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 
> ho...@li...,
>             the security contact of the project according to the
> README file [2].
> 2020-02-28: I reported findings a), b) and d) to de...@li...
> , the
>             maintainer of the project according to the AUTHORS file
> [3].
> 2020-03-16: I received a reply from de...@li..., stating
> that she
>             will look into the findings.
> 2020-05-06: I reminded de...@li... 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
> Tro...@li...
> https://lists.sourceforge.net/lists/listinfo/trousers-tech

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

[Debora V. B. <de...@li...>]

On Tue, 2020-08-04 at 13:45 +0200, Matthias Gerstner wrote:

<snip>> 
> And one thing you should take care of is to communicate CVEs for at
> least issue a) and c). IBM is a CNA itself so I can't (or at least
> very much shouldn't) do that for you.

I submitted a request for 3 CVE ids.  I will post the CVE ids once they
have been assigned.

Thanks,
Debbie

> 
> Cheers
> 
> Matthias

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

[James B. <je...@li...>]

On Thu, 2020-08-06 at 13:06 +0200, Jonas Witschel wrote:
> On 2020-08-05 14:51, Jerry Snitselaar wrote:
> > > 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 Fedora and RHEL there currently is a udev rule (from upstream)
> > that ships with the tpm2-tss package that is setting ownership of
> > /dev/tpm0 to tss:root. I don't recall what the reasoning was for
> > the group being root. For /dev/tpmrm0 it sets it to tss:tss, so not
> > sure what the reason was for /dev/tpm0. I believe that package is
> > part of a default install, so that will need to be worked out. I
> > don't know if you run into that with SUSE as well.
> 
> The idea behind not giving the tss group access to /dev/tpm0 as well
> is to prevent users from gaining direct access to the TPM and being
> able to DoS it. Users privileged to access the TPM should be added to
> the tss group so that they can access the TPM trough an access
> broker/resource manager (like tpm2-abrmd, the in-kernel resource
> manager /dev/tpmrm0, or tcsd in case of TPM 1.2), but not have "bare
> metal" access, which is limited to the tss user and root. See [1] for
> reference.

That may be a bit of a misconception about how tpmrm operates.  It's
simply the in-kernel resource manager which virtualizes the transient
objects and the session handles (as far as the latter can be
virtualized), so users making contact with the TPM over the tpmrm
device can't interfere with each other (very necessary with TPM 2.0
because it only has room for 3 transient keys).  However, a user with
tpmrm access can still DoS the TPM by making it derive RSA keys, for
instance.  Plus they can still access the full range of TPM privileged
commands if they have the authorizations.  There was talk of adding a
command restriction filter to tpmrm, but it's very hard to do reliably,
which is why it's not been done.

Basically TPM should be treated as a single owner resource, but that
single owner still needs help: I use my TPM for keys for ssh, gpg,
openvpn, secure boot and my general CA infrastructure.  Since those
applications operate independently, they could stack enough transient
objects into the TPM to give me an out of memory error unless I go via
the tpmrm device.

James

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

[Debora V. B. <de...@li...>]

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 
> ho...@li...,
>             the security contact of the project according to the
> README file [2].
> 2020-02-28: I reported findings a), b) and d) to de...@li...
> , the
>             maintainer of the project according to the AUTHORS file
> [3].
> 2020-03-16: I received a reply from de...@li..., stating
> that she
>             will look into the findings.
> 2020-05-06: I reminded de...@li... 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
> Tro...@li...
> https://lists.sourceforge.net/lists/listinfo/trousers-tech

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

[Jonas W. <dia...@ar...>]

On 2020-08-05 14:51, Jerry Snitselaar wrote:
> > 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 Fedora and RHEL there currently is a udev rule (from upstream) that
> ships with the tpm2-tss package that is setting ownership of /dev/tpm0
> to tss:root. I don't recall what the reasoning was for the group being
> root. For /dev/tpmrm0 it sets it to tss:tss, so not sure what the reason
> was for /dev/tpm0. I believe that package is part of a default install,
> so that will need to be worked out. I don't know if you run into that
> with SUSE as well.

The idea behind not giving the tss group access to /dev/tpm0 as well is to prevent users from gaining direct access to the TPM and being able to DoS it. Users privileged to access the TPM should be added to the tss group so that they can access the TPM trough an access broker/resource manager (like tpm2-abrmd, the in-kernel resource manager /dev/tpmrm0, or tcsd in case of TPM 1.2), but not have "bare metal" access, which is limited to the tss user and root. See [1] for reference.

Cheers,
Jonas

[1] https://github.com/tpm2-software/tpm2-tss/pull/963#issuecomment-381142241