RE: Fixing CVE-2017-15361

[Alexander.Steffen]

> > On Wed, Oct 25, 2017 at 07:17:17AM -0700, Matthew Garrett wrote:
> > > On Wed, Oct 25, 2017 at 6:44 AM, Jarkko Sakkinen
> > > <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote:
> > > > I'm implementing a fix for CVE-2017-15361 that simply blacklists
> > > > vulnerable FW versions. I think this is the only responsible action from
> > > > my side that I can do.
> > >
> > > I'm not sure this is ideal - do Infineon have any Linux tooling for
> > > performing firmware updates, and if so will that continue working if
> > > the device is blacklisted? It's also a poor user experience to have
> > > systems using TPM-backed disk encryption keys suddenly rendered
> > > unbootable, and making it as easy as possible for people to do an
> > > upgrade and then re-seal secrets with new keys feels like the correct
> > > approach.
> >
> > I talked today with Alexander Steffen in the KS unconference and we
> > concluded that this would be a terrible idea.
> 
> Right. Thinking more about this issue, I'd say the ideal way to handle it would
> be in the applications using the TPM. Not all functionalities of the TPM are
> affected, so only the applications can know whether their use cases are still
> safe and it are the applications that need to migrate to a safe solution should
> this be necessary. (Of course, this puts the burden on each individual
> application instead of having one central place to decide what is safe and
> what isn't, but I do not see any way around that.)
> 
> As far as I know, the kernel itself is not using any of the affected
> functionalities, so there is no need for an immediate mitigation within the
> kernel.

This does not seem to be entirely true. The code in security/keys/trusted.c might be affected under some circumstances, but I am not familiar enough with that code to say for sure. As far as I can tell, it does not create any RSA keys directly, but it might reference them as parent keys, so that vulnerable keys are used to protect the secrets. 

If that is the case, can we detect that issue and migrate the secrets to a safe configuration? Do we (as the kernel) want to do that? How much do we want/have to involve the user in the process?

> But I'd like to hear about how similar issues were handled in the past.
> I can think of multiple severe security issues, for example in BIOS
> implementations, but I cannot recall ever hearing about the kernel refusing
> to boot on such machines or even do so much as print a warning about that
> vulnerability.
> 
> > Alexander stated the following things about FW updates (Alexander,
> > please correct me if I state something incorrectly or if you have
> > something to add):
> >
> > * FW update can be constructed either in a way that the keys in the
> >   NVRAM are not cleared or in a way that they are cleared.
> 
> Correct. But as far as I know, the updates that were already published for this
> issue do not delete any of the keys. And I do not think that this would be a
> good idea. After all, the applications still might need access to their key to
> decrypt their data and reencrypt it with a safe key after applying the update.
> 
> > * FW update cannot be directly applied to the TPM but must come as
> >   part of the firmware update from the vendor.
> 
> Yes, starting the upgrade process is guarded by platformAuth/platformPolicy
> (in the case of TPM2), so the platform vendor needs to be involved. And you
> want them to be involved, since they need to make sure that their system
> still works with the updated TPM. I'm not sure whether platform vendors do
> that for TPMs, but for wireless cards whitelisting in the BIOS is common, and
> you do not want your machine refusing to boot just because the BIOS does
> not recognize your TPM's firmware version anymore (as a simple example).
> 
> > I proposed the following as an alternative:
> >
> > * Print a message to the klog (which log level would be appropriate?).
> > * Possibly sleep for few seconds. Is this a good idea?
> 
> I'd be okay with that, but ideally we'd have some kind of agreement/history
> of how to handle similar security issues in hardware components in general.
> Implementing a special case just for this TPM vulnerability does not seem like
> the right thing to do, especially when the kernel itself is not affected (and
> thus the whole machine might not be affected for the way that it is used).
> We do not want to confuse users or make them expect similar warnings in
> the future, when we might have no intention of providing them.
> 
> > While writing this email yet another alternative popped into my mind:
> > what if we allow only in-kernel use but disallow the use of /dev/tpm0?
> > You could still use trusted keys.
> >
> > Here are all the ideas that I have and I am open for better
> > alternatives.
> >
> > /Jarkko
> 
> Alexander