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] [day] [month] [year] [list]

Date:   Thu, 26 Oct 2017 21:07:28 +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:51:27PM +0000, Alexander.Steffen@...ineon.com wrote:
> > > 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@...ux.intel.com> 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?

I've implemented the TPM 2.0 trusted keys code and some parts have faded
away bit (I still run tests with that code for every kernel release) but
AFAIK you can give a non-primary key as parent.

/Jarkko