Re: Re: CVE Request: remote triggerable use-after-free in rpcbind

[Kurt Seifried <kseifried () redhat com>]

On Thu, Sep 17, 2015 at 1:00 PM, Marcus Meissner <meissner () suse de> wrote:

> On Thu, Sep 17, 2015 at 02:58:11PM -0400, Steve Dickson wrote:
> > > Where should I open it? kernel.org?
> > IDK... Aren't CVE suppose to be keep under wrap until
> > they are fixed... I know there are some rules around CVEs...
>
> Security issues can be either predisclosed in a smaller circle (the term
> is "responsible disclosure"), or published directly.
>
> As Olaf mailed the issue to the linux-nfs list a while ago, and SUSE
> evaluated
> and found the security impact only afterwards, the issue is considered
> already
> "public" and so gets no embargo.
>
> If the impact would be more obvious before it might have get a
> predisclosure.
>
> There are no strict rules though, just common understanding.
>
> Ciao, Marcus


To make it more complicated:

1) There are no strict rules
2) There are some strict rules
3) There are some wibbly-wobbly rules as well

There is no central governing body/law that controls security
vulnerabilities and how they are treated (well there is.. sort of, but not
really).

There are however economic and social forces at work, e.g. at Red Hat we do
our best to play nice with other vendors and reporters, why? So they keep
working with us and reporting stuff to us.

SuSE is a great example, there is a piece of software that both SuSE and
Red Hat ship called "SpaceWalk", SuSE handles quite a lot of the dev work
(thanks!), so for example when a security vuln for Spacewalk comes in we
(Red Hat) notify SuSE pretty much immediately, and they also get access to
the Bugzilla entry (so I don't have to play email games, they can just look
at the info directly). So for both SuSE and Red Hat this relationship with
respect to SpaceWalk is hugely beneficial to both of us (in economic terms
a net gain).

Companies that play less nice with reporters/other companies tend to be
excluded from information sharing, while not a strict rule, it is pretty
fundamental to human nature (who wants to play with mean people?). So while
not a strict rule, it is pretty common.

As for the wibbly-wobbly rules, well for example a commit may inadvertently
fix a security issue, one that nobody realizes exists. This happens all the
time. Sometimes post commit reviews/backports/etc cause someone to examine
it and realize it is a security issue. Some people consider this to be
"public" info, others do not, some (like myself) would say "it depends"
(but then I would also say "embargo only the things that matter").

Should we have agreed upon rules and standards? Hahahaha, not going to
happen. Should we have a rough framework/matrix (e.g. more embargo/less
embargo, more coordinated/less coordinated, etc.) so we at least know where
people are coming from and what their expectations are when we want to work
with them? Not a terrible idea I think.



--
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