[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 3 Jun 2017 12:06:23 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux kernel: stack buffer overflow with
controlled payload in get_options() function
On 05/30/2017 06:50 PM, Solar Designer wrote:
> I guess Daniel might be associating the other side's arguments with Red
> Hat's because Florian was posting from a redhat.com address. I have no
> idea whether Florian actually spoke on behalf of Red Hat or not, but
I'm not a Red Hat spokesperson, and I did not speak for Red Hat. I hope
I don't have to include a silly disclaimer in every message to counter
such assumptions.
> either way I think the focus on Red Hat is excessive - e.g., in the
> distros list thread on the previous issue, another distro vendor
> inquired about the proposed public disclosure date, implying they also
> might care. A better summary would be: understanding & opinions vary.
Right, I think those distributions that strive to boot under the
Microsoft trust root for UEFI Secure Boot may also have concerns about
this issue. Part of the problem with UEFI Secure Boot is that no one
has documented clear security objectives for UEFI Secure Boot. Fedora
sort of evolved into “no unsigned code running in ring 0 without
virtualization”. From what I can tell, Microsoft picked that up and
urged other distributions under their trust root to implement that as well.
If restricted access to ring 0 is the goal (and I think it currently
is), then Linux kernel command line parsing bugs exploitable for code
execution can be used to bypass an intended security policy, and
qualifies as a security vulnerability.
Thanks,
Florian
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.
