Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ