[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1496145073.1459.1.camel@gmail.com>
Date: Tue, 30 May 2017 07:51:13 -0400
From: Daniel Micay <danielmicay@...il.com>
To: 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 12:41 +0100, 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
It's unreasonable to consider the kernel line untrusted. A CVE being
issued for one of these issues didn't make sense.
If there's verified boot, it needs to cover the kernel command-line. If
it doesn't, that's a vulnerability. Memory corruption bugs aren't needed
for an attacker to make use of the kernel line.
Fixing these bugs makes sense, but treating them as vulnerabilities is
just going to turn off the Linux kernel developers to security people
even more since it's pretty much nonsense.
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.
