oss-sec mailing list archives

Re: Linux kernel: stack buffer overflow with controlled payload in get_options() function


From: Daniel Micay <danielmicay () gmail com>
Date: Tue, 30 May 2017 10:03:55 -0400

On Tue, 2017-05-30 at 15:47 +0200, Florian Weimer wrote:
On 05/30/2017 03:25 PM, Daniel Micay wrote:
Secure boot means verifying boot chain from a root of trust in
hardware.

My comments were specifically about UEFI Secure Boot, which apparently
behaves quite differently from what you expect.

UEFI Secure Boot can be used for a useful verified boot implementation.

It doesn't behave differently than I expect.

Only covering the kernel without covering any of the userspace or even
the kernel line is an incomplete implementation. It doesn't need to
cover the whole userspace OS to be useful but if it doesn't even cover
init and enough of the userspace OS to include some useful isolated code
then it's not accomplishing anything.

Secure / verified boot is useful primarily for preventing an attacker
from persisting privileged code. A good implementation tries to fully
prevent persistence, even of unprivileged code. The secondary value is
making tampering a lot more difficult, but it can't ever fully prevent
that. If there's no kernel line / userspace coverage, then it's not
doing either of those... so the lack of an enforced boundary between
root and the kernel at least without SELinux, etc. is an orthogonal
issue to this.

What security property does verified boot provide without including the
kernel line and at the very least enough of the core userspace OS to do
*something* useful?


Current thread: