[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 May 2017 09:25:38 -0400
From: Daniel Micay <danielmicay@...il.com>
To: Florian Weimer <fweimer@...hat.com>, oss-security@...ts.openwall.com
Cc: Roee Hay <roeehay@...il.com>
Subject: Re: Linux kernel: stack buffer overflow with
controlled payload in get_options() function
On Tue, 2017-05-30 at 15:05 +0200, Florian Weimer wrote:
> On 05/30/2017 03:02 PM, Daniel Micay wrote:
> > On Tue, 2017-05-30 at 14:52 +0200, Florian Weimer wrote:
> > > On 05/30/2017 01:51 PM, Daniel Micay wrote:
> > > > It's unreasonable to consider the kernel line untrusted. A CVE
> > > > being
> > > > issued for one of these issues didn't make sense.
> > >
> > > It's a potential Secure Boot bypass, so it matters in some
> > > theoretical
> > > sense to some downstreams which carry those Secure Boot patches.
> > >
> > > (Although I have yet to see anyone to revoke a signature on a
> > > kernel
> > > with known root-to-ring-0 escalations, so the practical impact
> > > isn't
> > > large because an attack could still downgrade to a kernel with an
> > > exploitable vulnerability.)
> > >
> > > Florian
> >
> > How is it a secure boot bypass? If the secure boot implementation
> > doesn't cover the kernel line it's already broken.
>
> That's not how the Secure Boot patches work.
Secure boot means verifying boot chain from a root of trust in hardware.
It's you who doesn't seem to understand how it works, and yet you're
telling that to me...
The late stage bootloader needs to verify the kernel / initrd and then
the kernel verifies the userspace OS if it's a full implementation. It
doesn't make sense for the kernel line to be left unverified as part of
that, and it isn't how ChromeOS / Android implement it. They verify the
kernel line as part of the initrd and don't allow setting a custom one
unless the bootloader is unlocked, which disables verified boot anyway.
> They restrict some
> features so that they cannot be selected from the kernel command line
> (or later from userland), and they do not rely on a bootloader which
> does not provide any means for editing the kernel command line.
I think you're referring to something different: restricting module
configuration parameters.
> > The provided example was treated as a verified boot vulnerability by
> > Google and fixed. It isn't supposed to be possible to set the kernel
> > line with a locked bootloader on Nexus/Pixel devices. It was a bug.
>
> I don't know how Google's user lockout works, so I can't comment on
> that.
It's not "user lockout", it's verified boot. It isn't really part of the
security model within the OS. A user on Android / ChromeOS doesn't have
root access so while Android uses SELinux heavily (far more than RHEL /
Fedora) it isn't really related to this at all.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
