Adventures with the UEFI shim

[Paul Moore]

On Mon, Nov 16, 2020 at 11:21 AM James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> On Mon, 2020-11-16 at 09:21 -0500, Paul Moore wrote:
> > On Sun, Nov 15, 2020 at 9:53 PM James Bottomley
> > <James.Bottomley at hansenpartnership.com> wrote:
> > > On Sun, 2020-11-15 at 18:21 -0500, Paul Moore wrote:
> > > [...]
> > > > Do you see any reason why the PCR extensions I'm proposing as
> > > > build time options are a bad idea and not something that should
> > > > be merged into shim?
> > >
> > > Well I don't understand what you're actually trying to do.
> >
> > My goal is to seal a TPM nvindex containing a secret (let's say a
> > storage encryption key for the sake of argument) such that it is only
> > accessible to authorized kernels.  In the case of UEFI Secure Boot,
> > the plan is that authorization would be determined by the key/cert
> > used to sign the kernel.  Updates to the firmware, including changes
> > to the db/dbx variables should be expected during the lifetime of the
> > system.  There is no safe and/or practical way to track the TPM
> > ownership credentials of the system outside the TPM itself, and in
> > some cases trusted physical access to the system will be difficult,
> > costly, or even impossible.
>
> But the security of this relies on the fact that there's no way to fake
> your PCR 8 update, so you don't have any security at all from this:
> signed versions of grub already exist that won't update either PCR 8 or
> 9 ...

Okay, I was operating under the assumption that all of the bootloaders
were measuring into PCR8, since that isn't the case this obviously
won't work.  Thanks.

> .. I really think you'd be better off resealing than
> trying to construct a more stable PCR.

Due to a few things, this carries a non-trivial risk for us (hence the
PCR8 work), but it is something we may have to use.

> > > > Do you see any reason why we need to keep the existing
> > > > ExitBootServices check as discussed above?  If yes, are you okay
> > > > with allowing the ExitBootServices check to be disabled via a
> > > > build time option?
> > >
> > > Well, it's not my code, but it does seem to provide additional belt
> > > and braces security against someone tricking grub into booting an
> > > unsigned kernel.  I suppose the real question is did we ever sell
> > > this to Microsoft as a security feature?  Because if so they're
> > > unlikely to sign a version of shim that has it turned off.
> >
> > As has already been pointed out above, the ExitBootServices check is
> > trivially bypassed by a second (or third, or fourth, ...) stage
> > loader.
>
> I don't think I've seen that.  However, it is hard for someone who
> isn't physically present and doesn't have access to the signing
> certificates to defeat this chain.  The only way I can think of is to
> cause the kernel to be chain loaded, which the check defeats, so it
> does seem to add useful security.

The approach suffers from a sort of TOCTOU problem; the second stage
loader could send one buffer to the shim's verification handler while
executing another.

-- 
paul moore
www.paul-moore.com