Adventures with the UEFI shim

[James Bottomley]

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.  I could boot through this grub and fake your PCR 8 from the kernel
to obtain the secret.  Windows doesn't update PCR 8 either, so even if
we solve the grub problem I can boot windows to steal your secret.

> > What are you trying to seal that would be significantly disrupted
> > by periodic updates to dbx (I really don't think db updates often
> > enough to be a significant problem)?
> 
> I think I covered all of that above.
> 
> > Plus you seem to have a broken security chain: your PCR8 chain
> > doesn't measure the key that signed shim although this might be
> > explained if I understood what you were trying to seal ... but
> > it does look odd that your variable chain is SecureBoot, PK, KEK,
> > shim signing key.
> 
> As the KEK secures the db/dbx variables, and their updates, my
> understanding is that measuring the SecureBoot, PK, and KEK variables
> is sufficient to ensure that the system is running with secure boot
> enabled and that the db/dbx variables have not been modified outside
> of authorized updates.  Measuring the certificate which verifies the
> kernel's signature allows us to determine if the kernel is authorized
> to access the TPM based secrets.

OK, so KEK is actually not required.  You would need to add
AuditMode/DeployedMode.  Additionally, you have a bootstrap problem,
because if SecureBoot is off, nothing you're sealing to guarantees to
measure that; that's why PCR 7 is the designated index for what you're
trying to do: because the platform will always measure the required
variables into it.  I really think you'd be better off resealing than
trying to construct a more stable PCR.  If you control the platform
update, it should be fairly easy to manage.

> Things such as BootGuard are outside the scope of shim, but are part
> of the overall solution.
> 
> > > 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.

James

>   If shim's ExitBootServices check turns out to be on a
> critical security enforcement path then there are likely serious
> issues that need to be addressed independent of the discussion here.