Date: Thu, 17 Sep 2015 13:34:48 -0600 From: Kurt Seifried <kseifried@...hat.com> To: oss-security <oss-security@...ts.openwall.com> Cc: Steve Dickson <SteveD@...hat.com>, cve-assign@...re.org, Olaf Kirch <okir@...e.de> Subject: Re: Re: CVE Request: remote triggerable use-after-free in rpcbind On Thu, Sep 17, 2015 at 1:00 PM, Marcus Meissner <meissner@...e.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@...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.