Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 May 2017 12:09:20 -0400
From: Daniel Micay <danielmicay@...il.com>
To: oss-security@...ts.openwall.com
Cc: "Designer, Solar" <solar@...nwall.com>
Subject: Re: Linux kernel: stack buffer overflow with
 controlled payload in get_options() function

On Tue, 2017-05-30 at 09:36 -0600, Kurt Seifried wrote:
> On Tue, May 30, 2017 at 9:20 AM, Daniel Micay <danielmicay@...il.com>
> wrote:
> 
> > That's not what secure/verified boot means to everyone else, and
> > there's nothing in mainline with those properties. To everyone else,
> > it's not an arbitrary bureaucratic/marketing feature. It's
> > verification of the whole base OS... i.e. Android, Android Things
> > (Brillo), ChromeOS, iOS and sane embedded Linux systems. Likely
> > Windows on mobile devices too, and I really doubt that Microsoft
> > doesn't plan on verifying the userspace OS if they don't already.
> > 
> 
> Red Hat is only associated with this in so far as I happen to work for
> Red
> Hat and I typically do the CVE assignments on the distros@ list (where
> this
> issue was initially reported).

Linux isn't impacted in a security-relevant way by these bugs. You're
claiming that some downstream code is implemented in a way that impacts
security, but you can't explain how it compromises a meaningful security
boundary.

> > Anyway, good luck with meaningless Red Hat security theatre. These
> > "vulnerabilities" are just reinforcing the view that security people
> > are foolish. There isn't disagreement that it's a meaningless
> > feature
> > with this level of incompleteness and yet a CVE is assigned for it?
> > Okay then...
> > 
> 
> I suggest you take this issue up with MITRE/CVE Board (disclaimer: I'm
> also
> on the CVE Board), they control CVE and the definitions of what is CVE
> worthy, and in this case it largely falls under the
> "advertised/implied
> security feature doesn't work as such". This is unlikely to change as
> it's
> well established and has been used for over a decade.

Nothing in Linux claims to work the way you're talking about. You've
only brought up an incomplete implementation of verified boot based on a
fork of the Linux kernel. It should be filed against that fork, but it
really doesn't make any sense to have a CVE for a non-security feature
being broken.

> > Sorry for thinking that this should be about something more than
> > padding CVs and marketing materials.
> > 
> 
> I suggest then you take this up with the original researcher if you're
> worried about people padding their CVs. This discussion isn't
> productive/helpful and I suggest you take it off list.

I'm not just concerned about people padding their CVs, I'm concerned
about vendors marketing incomplete snake oil as an implementation of
security features that actually have a meaning and then turning it into
nonsense like this.

I suggest taking discussions about non-security bugs off list. It's not
on topic here.

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.