Bug 1950046 (CVE-2021-3505)

Created libtpms tracking bugs for this issue:

Affects: fedora-all [bug 1950048]

It is likely a breaking change, as it was not introduced in 0.7 branch (see https://github.com/stefanberger/libtpms/commit/153a9579e84c83c38d404bd12fd5267f82fd07a1). Also, I think a CVE was requested earlier and not accepted.

When a TPM 2 (instance) is upgraded from libtpms 0.7.x to 0.8.x it will continue using the weak key generation algorithm since otherwise nothing would decrypt anymore with keys derived from the TPM 2's current seeds. If the seeds are reset, which is only possible via firmware, then the code will switch to use the new key generation algorithm for seed-derive keys since after resetting the seeds the keys are expected to be different than before and nothing is expected to decrypt anymore with seeed-derived keys. So it shouldn't break anything from the point of view of the user, he just doesn't get the better keys because we cannot just switch over. Newly created TPM 2 instance using libtpms 0.8 would use the fixed key generation algorithm.

Stefan, why is the fix not backported to 0.7 branch then?

(In reply to Marc-Andre Lureau from comment #7)
> Stefan, why is the fix not backported to 0.7 branch then?

Because it changes the state file of the TPM 2 to keep track of the 'age' of the seeds. I don't backport these kind of changes.

(In reply to Stefan Berger from comment #8)
> (In reply to Marc-Andre Lureau from comment #7)
> > Stefan, why is the fix not backported to 0.7 branch then?
> 
> Because it changes the state file of the TPM 2 to keep track of the 'age' of
> the seeds. I don't backport these kind of changes.

Could it keep the current age instead? Only newly state would get a new age. (if that makes sense)

(In reply to Marc-Andre Lureau from comment #9)
> (In reply to Stefan Berger from comment #8)
> > (In reply to Marc-Andre Lureau from comment #7)
> > > Stefan, why is the fix not backported to 0.7 branch then?
> > 
> > Because it changes the state file of the TPM 2 to keep track of the 'age' of
> > the seeds. I don't backport these kind of changes.
> 
> Could it keep the current age instead? Only newly state would get a new age.
> (if that makes sense)

How do you distinguish between an old seed requiring to run the weak key generation algorithm and a new seed then? Sorry, but this doesn't make sense. You need to track that 1 bit of information. Besides that, the patches have already been merged a long time ago and libtpms 0.8.x fixes the issue.

(In reply to Stefan Berger from comment #10)
> How do you distinguish between an old seed requiring to run the weak key
> generation algorithm and a new seed then? Sorry, but this doesn't make

The age doesn't let you make that difference? What's the age for then?

> sense. You need to track that 1 bit of information. Besides that, the
> patches have already been merged a long time ago and libtpms 0.8.x fixes the
> issue.

We don't usually rebase versions in RHEL released products, we backport fixes or just WONTFIX.

Please help us make the best decision

(In reply to Marc-Andre Lureau from comment #11)
> (In reply to Stefan Berger from comment #10)
> > How do you distinguish between an old seed requiring to run the weak key
> > generation algorithm and a new seed then? Sorry, but this doesn't make
> 
> The age doesn't let you make that difference? What's the age for then?

Yes, the age let's you make the difference but the age was introduced as part of the patches to fix the issue. This changes the state format the TPM 2's state is written in and I don't want to backport it since it's too easy to loose the upgrade path.

> 
> > sense. You need to track that 1 bit of information. Besides that, the
> > patches have already been merged a long time ago and libtpms 0.8.x fixes the
> > issue.
> 
> We don't usually rebase versions in RHEL released products, we backport
> fixes or just WONTFIX.
> 
> Please help us make the best decision

In this case I would say that if you start a new version of RHEL you could still go with libtpms-0.8.x, if you cannot upgrade it then mark it as WONTFIX.

(In reply to Stefan Berger from comment #12)
> > The age doesn't let you make that difference? What's the age for then?
> 
> Yes, the age let's you make the difference but the age was introduced as
> part of the patches to fix the issue. This changes the state format the TPM
> 2's state is written in and I don't want to backport it since it's too easy
> to loose the upgrade path.

How did you handle migration from 0.7/non-aged to 0.8 ? In CHANGES, it is said downgrade is not possible, not upgrade. There must be a way to distinguish fixed from non-fixed version then.


> > > sense. You need to track that 1 bit of information. Besides that, the
> > > patches have already been merged a long time ago and libtpms 0.8.x fixes the
> > > issue.
> > 
> > We don't usually rebase versions in RHEL released products, we backport
> > fixes or just WONTFIX.
> > 
> > Please help us make the best decision
> 
> In this case I would say that if you start a new version of RHEL you could
> still go with libtpms-0.8.x, if you cannot upgrade it then mark it as
> WONTFIX.

If it would just be me, I would upgrade to 0.8, but this brings a lot of other changes that might be too risky too.

Mauro, what do you think?

> In CHANGES, it is said downgrade is not possible, not upgrade. There must be a way to distinguish fixed from non-fixed version then.

The new state wouldnt be backward compatible though, but it's not worse that forcefully upgrading to 0.8.

(In reply to Marc-Andre Lureau from comment #13)
> (In reply to Stefan Berger from comment #12)
> > > The age doesn't let you make that difference? What's the age for then?
> > 
> > Yes, the age let's you make the difference but the age was introduced as
> > part of the patches to fix the issue. This changes the state format the TPM
> > 2's state is written in and I don't want to backport it since it's too easy
> > to loose the upgrade path.
> 
> How did you handle migration from 0.7/non-aged to 0.8 ? In CHANGES, it is
> said downgrade is not possible, not upgrade. There must be a way to
> distinguish fixed from non-fixed version then.

When TPM 2 reads the statefile of the TPM 2 and the blob containing a seed is of version <x, where version <x does not track the age of the seed, it assigns it the default value representing the state of an old seed. The state writing side will write the blob in version x which now contains the age of the seed and the next time we read the state from the file we pick up the age from the blob.

In reply to comment #13:
> (In reply to Stefan Berger from comment #12)
> > > We don't usually rebase versions in RHEL released products, we backport
> > > fixes or just WONTFIX.
> > > 
> > > Please help us make the best decision
> > 
> > In this case I would say that if you start a new version of RHEL you could
> > still go with libtpms-0.8.x, if you cannot upgrade it then mark it as
> > WONTFIX.
> 
> If it would just be me, I would upgrade to 0.8, but this brings a lot of
> other changes that might be too risky too.
> 
> Mauro, what do you think?

I was aware that backporting the fix to 0.7.x (the only versions we currently ship) would have been tricky, but decided to allocate a CVE anyway because that was the right thing to do. I would probably lean towards WONTFIX here: this is not an important/critical issue and probably not worth the effort given the above comments.

As for whether or not to rebase, I don't know what implications - mostly from a functional/compatibility point of view - an upgrade to 0.8 would entail. That said, as you know, a number of potentially-security-sensitive fixes didn't get CVEs in the past (e.g., https://github.com/stefanberger/libtpms/blob/stable-0.7.0/CHANGES) and I see the risk of not backporting a security fix just because it didn't get a CVE. With this in mind IMHO rebasing should be a serious option to consider - if possible - alongside a more thorough handling of CVEs going forward (we can help with the latter part).

Statement:

Versions of `libtpms` prior to 0.8.0 generate weaker than expected TPM 2 RSA keys due to the flawed key creation algorithm. Red Hat Enterprise Linux 8 Advanced Virtualization is therefore affected by this flaw, as it ships an older version of the package (0.7.x).

Mitigation:

There is no mitigation for this issue. Upgrading to a fixed release (0.8.0+) is necessary but not sufficient. The only way to fix it is to unseal all data, delete the old TPM state file, generate a new one with the fixed key generation algorithm, then reseal the data.