Adventures with the UEFI shim

[James Bottomley]

On Mon, 2020-11-16 at 14:10 -0500, Paul Moore wrote:
> 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.

Well they do now (or at least, the TPM measurement patches went into
grub 2.04 which all the distros are adopting), but in the early days we
released signed versions of shim/grub that didn't do anything with
measurements.

But even if we managed to revoke all the older versions of grub there's
still the windows boot problem.  They actually use PCRS 11-14 for their
boot measurements, so again they leave PCR 8 and 9 at zero.  I posted a
windows boot log to the efi list if you want to look through it:

https://lore.kernel.org/linux-efi/72a99913bb57893325e9457daf3f1af471eda498.camel@HansenPartnership.com/

There's, unfortunately, no overlap between the PCRs grub currently uses
(8,9) and the ones windows uses (11-14) so it pretty much makes it
impossible to design a secure seal on a non UEFI (0-7) PCR.

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

I think the industry has really given up on the idea of long term
sealing to any PCRs rooted in the SRTM so you really need a DRTM to
make it work.  Unfortunately to the best of my knowledge all DRTM
implementations are proprietary.

Alternatively, we can try to construct a scheme which makes it easy to
update object policies when the PCRs change.  This is actually possible
to do because we can have separate admin and user policies for any TPM
object and only the admin can change the policy, so we'd use a signed
update based on a known public key for the policy change (and we'd lock
to executable command to being a policy digest update via cpHashA) or
the policy would be your PCR lock to read the index.

Although I can come up with a scheme like the above it still has some
limitations: it requires knowing ahead of time what the locked PCR
values will change to (which is often quite difficult).

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

In theory, the fact that the distro built and signed the grub and you
can't boot anything other than what the distro signed should ensure
this window doesn't exist.  In practice the fact that grub has a shell
does add a lot of scope for script based attacks.

James