Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 15 Jun 2017 11:29:26 -0600
From: "" <>
Subject: Re: Re: MySQL - use-after-free after

On 06/15/2017 11:28 AM, Kurt H Maier wrote:
> On Thu, Jun 15, 2017 at 08:21:29AM -0600, Kurt Seifried wrote:
>> 1) Official documentation that says "do this [insecure thing]" should
>> probably get a CVE (e.g. "turn off all the encryption to make it work more
>> easily"). This should probably get a CVE, especially as it results in
>> operational changes which won't get a CVE (since it's not in code that
>> "ships", it's just on the end of whoever is using it).
> I really like this idea.  What would be the approach to software whose
> documentation starts out with "turn off selinux," out of curiosity?

Good question. I would rephrase it was "turn off the firewall" or "turn
off the Anti virus" and I think we're definitely into the "yes, that
needs a CVE" territory (even if it can't be fixed, at least people will
be more aware and maybe make more informed decisions when picking).

> Obviously this lessens the security stance of the system, but presumably
> the system is designed to be operable without selinux.  Would CVEs get
> assigned for all bad ideas, or just those that expose actual attack
> vectors?

I would say that being told/forced (e.g. most systems that say turn off
SELinux say that because they couldn't make it work with SELinux on) do
definitely expose the system and people need to be aware of this.

>> 3) Unofficial but commonly used documentation and code examples, I guess
>> the best example here is stackoverflow and friends?
> This is going to cause you to hit INT_MAX relatively quickly.

Well part of it would be the current test case of "does anyone care",
e.g. do people actually use this/care enough to do the work to assign a
CVE, if someone wants to spend their time being the CNA for
stackoverflow and put out good CVEs I'm fine with that.

> khm


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

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.