On 01/09/2013 02:34 PM, Matthew Garrett wrote:
On Wed, Jan 09, 2013 at 01:52:05PM +0100, Florian Weimer wrote:
It just occurred to me that this has zero chance of working because
an attacker can always take the already-signed boot path from the
F18 installer and use that to boot a modified F19 installation
image. We cannot retroactively add these checks to the F18
installation images (or F18 installations). We could theoretically
revoke the signatures on the F18 binaries, but this would not go
well with our users.
I don't understand what you mean by "already-signed boot path", and I
don't see how F18 has anything to do with this.
Let's say I want to replace packages in the official, cryptographically
signed F19 installation media. Let's assume further that we tell our
users to verify the signature just by booting from the media.
I start with the F18 TC3 image, which boots on Secure Boot systems,
replace the boot artwork (which is not cryptographically protected), the
F18 kernel, and use most of the F19 installation environment. The F18
boot loader and kernel know nothing about image verification or
Authenticode-style executable verification, so it will start any init I
supply. This means that I can start a fake anaconda which looks just
like F19, but does not verify RPM signatures (as before). At this
point, I can put whatever RPMs I want on the installation media, and
they will be installed.
(I might even be able to use the F19 kernel if the shim-embedded CA
hasn't changed keys.)
This is related to the lack of universally agreed-upon semantics for
Secure Boot. A Secure Boot signature does not mean that the image
is harmless to boot. I've recently raised this ambiguity on the
oss-security mailing list in the "Plug-and-wipe and Secure Boot
semantics" thread:
If I have physical access to your system then I can just write my own
keys directly into flash with an SPI programmer. That's never been the
threat model.
True. But if we want to use Secure Boot for image verification, we need
to cover the case where the user willingly boots from a tampered-with
image (modified outside the cryptographically protected part,
obviously). These needs additional guarantees from the folks
participating in the Secure Boot PKI, and I really doubt they are there
(and apparently, so do you).
--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
