[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANO=Ty0mQugCFyHqxzSVyc+2NUQcL5f42xXu9w=NQ5XvJHU75w@mail.gmail.com>
Date: Thu, 15 Jun 2017 08:21:29 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security <oss-security@...ts.openwall.com>
Cc: pali.rohar@...il.com
Subject: Re: Re: MySQL - use-after-free after mysql_stmt_close()
This does bring up an old question:
Should we assign CVEs for code examples/documentation? E.g. We assign CVEs
for code shipped to people in digital form. Why not assign CVEs for code in
documentation or commonly used examples? We can go with the rational that
CVEs get assigned to the affected code bases (e.g. when someone implements
that documentation/code), but it might also be good to educate the
community about bad examples/documentation/etc.
My thinking is:
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).
2) Official code examples, as above, actual implementations get CVEs, it
might be useful to raise awareness that the example is bad.
3) Unofficial but commonly used documentation and code examples, I guess
the best example here is stackoverflow and friends?
Thoughts/comments (feel free to reply privately if you don't want to be
public)? I'd like to collect what people think and then present it to the
CVE board later (this has been on my long term todo list).
On Thu, Jun 15, 2017 at 7:50 AM, Adam Maris <amaris@...hat.com> wrote:
> On Mon, 2017-06-12 at 23:47 +0200, Pali Rohár wrote:
> > Hello!
> >
> > Any idea how to handle this particular problem?
> >
> >
>
> Hi!
>
> Given that Oracle (silently) updated the vulnerable example in their
> documentation, this likely indicates the way to handle this -
> applications that copied the vulnerable example needs to be fixed and
> CVEs will be assigned per application.
>
> Best Regards,
>
> --
> Adam Mariš, Red Hat Product Security
> 1CCD 3446 0529 81E3 86AF 2D4C 4869 76E7 BEF0 6BC2
>
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@...hat.com
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.
