UEFI Secure Boot and Ubuntu - implementation

[Matthew Garrett]

On Mon, Jun 25, 2012 at 03:01:50PM -0500, Jamie Strandboge wrote:

> At this point, because all the OS' stage 1 bootloaders (FLOSS and
> non-FLOSS) are signed by the same authority, we are all are affected by
> the others. It is clear that if there is a problem with DistroX's boot
> loader, malware authors will just use DistroX's vulnerable boot loader
> to attack DistroY and any other systems that don't yet have an update to
> dbx (including DistroX itself). Obviously this is the purpose of dbx,
> but dbx is only useful if the individual or OS vendor has a key in KEK
> such that dbx can be updated.

Microsoft have volunteered to maintain dbx, so the absence of a KEK 
isn't a problem - the Microsoft KEK will always be present. In the event 
that hardware is shipped with a vendor KEK but no Microsoft KEK then the 
vendor would have to take responsibility, but it seems likely that 
that'll be a very small corner case.

> Optimistically speaking, since there isn't a ton of early boot code, in
> time I expect the bootloader vulnerabilities/bypasses should diminish
> and people will be looking at the other parts of the system to attack.
> For example, if there is a problem in DistroY's kernel that affects
> secure boot (eg, module verification), then a malware author could use
> DistroY's kernel and bootloader to attack DistroZ and any systems that
> don't yet have an update to dbx for DistroY's stage 1 bootloader
> (including DistroY itself). The attack places the old stage 1, old stage
> 2 and vulnerable kernel and/or modules in place and on reboot, it all
> verifies. So we need to update the stage 1 bootloader to embed a CSR for
> every kernel upgrade, get the updated bootloader signed, install the new
> bootloader and kernel, and update dbx to revoke the old bootloader. The
> new bootloader can then use the embedded CSR to see if the stage 2 was
> revoked, and the stage 2 can use an embedded CSR to see if the kernel
> was revoked (having two stages when you control dbx is not strictly
> required). This is all doable when the individual/OS vendor controls the
> key in KEK, but really painful when going through a 3rd party signing
> authority. It would be a shame if Free Software users had to wait on a
> 3rd party to sign security updates for their distribution's kernel
> (indeed, imagine a public critical kernel security update that has to
> wait days/weeks to be signed before rolling out to users).

Again, this isn't a problem. It's trivial to just do this via dbx, as 
above. My understanding is that you're planning on using the shim loader 
I've been working on - it supports this functionality. There's no need 
for a third party to be involved in any part of the process other than 
providing the revocation update.

> For these reasons, it seems clear to me that extending Secure Boot to
> include a partially or fully attested boot by signing the kernel and
> modules just doesn't seem to work well enough to justify the significant
> inconvenience to the individual/OS vendor when the individual/OS vendor
> doesn't have a key in KEK to control dbx.

I think you've based this on some misapprehensions. There's no need for 
any additional significant inconenience for the vendor - they just need 
to be able to provide exploitable binaries to Microsoft and ship dbx 
updates via their update mechanism.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org