Adventures with the UEFI shim

[Paul Moore]

On Mon, Nov 16, 2020 at 6:27 PM James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> 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:

...

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

Regardless of other, non-GRUB bootloaders, I still don't want to rely
on being 100% sure all of the "bad" GRUB builds are included in the
dbx.  My luck just isn't good enough to rest easy with a denylist
approach here.

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

Our original approach was DRTM/TXT based, modified to work on
Authenticode signed PECOFF binaries and measure the signer into a PCR
(similar to PCR7), but as we expanded to other non-Intel x86 CPUs as
well as other non-x86 platforms this was no longer an option ... or
rather it was no longer an option without a *lot* of additional work
on our end.

While DRTM is really appealing in principle, the lack of signature
support and the vendor specific implementations have doomed it thus
far.  I haven't looked too closely at Trenchboot in a while, perhaps
it might provide a usable DRTM implementation at some point in the
future.

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

Relying on the signed distro build highlights the idea that the
ExitBootServices check isn't critical to the UEFI SB security model;
the important authorization is the signature on the bootloader itself,
not whether or not the bootloader calls into the shim verification
protocol.

Regardless, as you said, this isn't our code, it would be nice to hear
a verdict from the shim maintainers on the ExitBootServices check.

-- 
paul moore
www.paul-moore.com