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

["kseifried () redhat com" <kseifried () redhat com>]

On 05/30/2017 05:41 AM, Simon McVittie wrote:
> On Tue, 30 May 2017 at 08:17:54 +0400, Ilya Matveychikov wrote:
> > When using get_options() it's possible to specify a range of numbers,
> > like 1-100500. The problem is that it doesn't track array size while
> > calling internally to get_range() which iterates over the range and
> > fills the memory with numbers.
>
> Is there a realistic way in which an attacker can provide Linux kernel
> command-line arguments, without being able to achieve arbitrary code
> execution via those command-line arguments?
>
> In other words, is this a security vulnerability, or just a bug?
>
> (If the attacker can already achieve arbitrary code execution then
> this bug does not give them any capability they do not already have.)
>
>     S

Here's my response from the initial assignment:

For the purposes of CVE this is a vulnerability (secureboot says you
won't be monkeying with the kernel in general). In general: the promise
of secureboot is not a fully secure system, the promise of secureboot is
a secured bootchain, so for example the kernel itself is trusted and
secure, once it goes to user space, then things go to "it depends" (e.g.
if you have signed binaries that are secure, you would in theory have a
secure userland, if you boot to unsigned binaries, then good luck and
have fun). But code execution within the kernel is generally a definite
no-no.

Please use CVE-2017-1000363 for this issue.


-- 

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert () redhat com