linux-kernel - Re: Fixing CVE-2017-15361

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 26 Oct 2017 19:00:37 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Alexander.Steffen@...ineon.com
Cc:     mjg59@...gle.com, linux-integrity@...r.kernel.org,
        kari@...aani.com, linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org
Subject: Re: Fixing CVE-2017-15361

On Thu, Oct 26, 2017 at 03:42:27PM +0000, Alexander.Steffen@...ineon.com wrote:
> 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. 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.

Hmm.. trusted key with parent other than a primary key?

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

Right, obviously :-)

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

Thank you for elaborating this further!

/Jarkko