Multipel CNAs for software and coordination for issues under embargo

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Multipel CNAs for software and coordination for issues under embargo

Kurt Seifried
So we now have a failure case, an embargoed set of issues were posted to the distros list, I was not explicitly asked to assign CVE's, but did, and it turns out CERT also assigned CVEs. CERT published first, so I reject'ed mine (https://github.com/CVEProject/cvelist/pull/314). 

This brings up the issue of what do we do when a reporter has an issue(s) and doesn't explicitly ask a CNA for CVEs, but more than one CNA see it, and want to assign a CVE to it because the issues would significantly benefit from CVEs? Most scopes do not overlap, with one glaring exception, "Open Source". 

So thoughts/comments? Should we only assign a CVE if asked, and then if not asked default to some sort of notification protocol? Should we simply go with the "first to publish" rule like for public issues? Other options?


--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Multipel CNAs for software and coordination for issues under embargo

Pascal Meunier
Another approach might be pre-agreements or other criteria between CNAs that, in this
type of situation, resolve the overlapping scopes ahead of time.  For example, CNAs
could agree to monitor non-overlapping lists, or stake a unique claim to the
responsibility for monitoring a certain source or type of source.  

Pascal

On Thu, 2018-02-15 at 16:36 -0700, Kurt Seifried wrote:

> So we now have a failure case, an embargoed set of issues were posted to
> the distros list, I was not explicitly asked to assign CVE's, but did, and
> it turns out CERT also assigned CVEs. CERT published first, so I reject'ed
> mine (https://github.com/CVEProject/cvelist/pull/314).
>
> This brings up the issue of what do we do when a reporter has an issue(s)
> and doesn't explicitly ask a CNA for CVEs, but more than one CNA see it,
> and want to assign a CVE to it because the issues would significantly
> benefit from CVEs? Most scopes do not overlap, with one glaring exception,
> "Open Source".
>
> So thoughts/comments? Should we only assign a CVE if asked, and then if not
> asked default to some sort of notification protocol? Should we simply go
> with the "first to publish" rule like for public issues? Other options?
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Multipel CNAs for software and coordination for issues under embargo

jericho
Lot of ideas on this, but perhaps today's interesting assignments around
Jenkins may help the discussion? How exactly did one Jenkins disclosure
get three CVEs from two CNAs? I assume there had to be coordination in
advance of this?

CVE-2018-1000067          Jenkins LTS SECURITY-506
CVE-2018-1000068          Jenkins LTS SECURITY-717
CVE-2018-6356             Jenkins LTS SECURITY-705

The Jenkins advisory, as of this email, only includes 2018-6356 and two
instances of "CVE pending".

.b

On Thu, 15 Feb 2018, Pascal Meunier wrote:

: Another approach might be pre-agreements or other criteria between CNAs that, in this
: type of situation, resolve the overlapping scopes ahead of time.  For example, CNAs
: could agree to monitor non-overlapping lists, or stake a unique claim to the
: responsibility for monitoring a certain source or type of source.  
:
: Pascal
:
: On Thu, 2018-02-15 at 16:36 -0700, Kurt Seifried wrote:
: > So we now have a failure case, an embargoed set of issues were posted to
: > the distros list, I was not explicitly asked to assign CVE's, but did, and
: > it turns out CERT also assigned CVEs. CERT published first, so I reject'ed
: > mine (https://github.com/CVEProject/cvelist/pull/314).
: >
: > This brings up the issue of what do we do when a reporter has an issue(s)
: > and doesn't explicitly ask a CNA for CVEs, but more than one CNA see it,
: > and want to assign a CVE to it because the issues would significantly
: > benefit from CVEs? Most scopes do not overlap, with one glaring exception,
: > "Open Source".
: >
: > So thoughts/comments? Should we only assign a CVE if asked, and then if not
: > asked default to some sort of notification protocol? Should we simply go
: > with the "first to publish" rule like for public issues? Other options?
: >
: >
:
Reply | Threaded
Open this post in threaded view
|

Re: Multipel CNAs for software and coordination for issues under embargo

Kurt Seifried
probably because he emailed me a CSV file and I replied...

On Thu, Feb 15, 2018 at 8:28 PM, jericho <[hidden email]> wrote:
Lot of ideas on this, but perhaps today's interesting assignments around
Jenkins may help the discussion? How exactly did one Jenkins disclosure
get three CVEs from two CNAs? I assume there had to be coordination in
advance of this?

CVE-2018-1000067          Jenkins LTS   SECURITY-506
CVE-2018-1000068          Jenkins LTS   SECURITY-717
CVE-2018-6356             Jenkins LTS   SECURITY-705

The Jenkins advisory, as of this email, only includes 2018-6356 and two
instances of "CVE pending".

.b

On Thu, 15 Feb 2018, Pascal Meunier wrote:

: Another approach might be pre-agreements or other criteria between CNAs that, in this
: type of situation, resolve the overlapping scopes ahead of time.  For example, CNAs
: could agree to monitor non-overlapping lists, or stake a unique claim to the
: responsibility for monitoring a certain source or type of source.
:
: Pascal
:
: On Thu, 2018-02-15 at 16:36 -0700, Kurt Seifried wrote:
: > So we now have a failure case, an embargoed set of issues were posted to
: > the distros list, I was not explicitly asked to assign CVE's, but did, and
: > it turns out CERT also assigned CVEs. CERT published first, so I reject'ed
: > mine (https://github.com/CVEProject/cvelist/pull/314).
: >
: > This brings up the issue of what do we do when a reporter has an issue(s)
: > and doesn't explicitly ask a CNA for CVEs, but more than one CNA see it,
: > and want to assign a CVE to it because the issues would significantly
: > benefit from CVEs? Most scopes do not overlap, with one glaring exception,
: > "Open Source".
: >
: > So thoughts/comments? Should we only assign a CVE if asked, and then if not
: > asked default to some sort of notification protocol? Should we simply go
: > with the "first to publish" rule like for public issues? Other options?
: >
: >
:



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Multipel CNAs for software and coordination for issues under embargo

jericho
On Thu, 15 Feb 2018, Kurt Seifried wrote:

: probably because he emailed me a CSV file and I replied...

I don't understand...

2018-6356 is from MITRE I believe? Yet "he emailed you a CSV file" with
two (?) vulns that needed assignments, and you/DWF did those two
assignments?

Your reply doesn't explain why there is mixed CNA assignments here, and
what level of coordination, if any, was involved. Why would Jenkins
request one ID from MITRE, then two from the DWF CNA? That seems like a
breakdown in the CNA process to me.

Apologies, I just thought this series of assignments suggested there was a
level of coordination between two CNAs, when there may not have been.

Brian



: On Thu, Feb 15, 2018 at 8:28 PM, jericho <[hidden email]> wrote:
:
: > Lot of ideas on this, but perhaps today's interesting assignments around
: > Jenkins may help the discussion? How exactly did one Jenkins disclosure
: > get three CVEs from two CNAs? I assume there had to be coordination in
: > advance of this?
: >
: > CVE-2018-1000067          Jenkins LTS   SECURITY-506
: > CVE-2018-1000068          Jenkins LTS   SECURITY-717
: > CVE-2018-6356             Jenkins LTS   SECURITY-705
: >
: > The Jenkins advisory, as of this email, only includes 2018-6356 and two
: > instances of "CVE pending".
: >
: > .b
: >
: > On Thu, 15 Feb 2018, Pascal Meunier wrote:
: >
: > : Another approach might be pre-agreements or other criteria between CNAs
: > that, in this
: > : type of situation, resolve the overlapping scopes ahead of time.  For
: > example, CNAs
: > : could agree to monitor non-overlapping lists, or stake a unique claim to
: > the
: > : responsibility for monitoring a certain source or type of source.
: > :
: > : Pascal
: > :
: > : On Thu, 2018-02-15 at 16:36 -0700, Kurt Seifried wrote:
: > : > So we now have a failure case, an embargoed set of issues were posted
: > to
: > : > the distros list, I was not explicitly asked to assign CVE's, but did,
: > and
: > : > it turns out CERT also assigned CVEs. CERT published first, so I
: > reject'ed
: > : > mine (https://github.com/CVEProject/cvelist/pull/314).
: > : >
: > : > This brings up the issue of what do we do when a reporter has an
: > issue(s)
: > : > and doesn't explicitly ask a CNA for CVEs, but more than one CNA see
: > it,
: > : > and want to assign a CVE to it because the issues would significantly
: > : > benefit from CVEs? Most scopes do not overlap, with one glaring
: > exception,
: > : > "Open Source".
: > : >
: > : > So thoughts/comments? Should we only assign a CVE if asked, and then
: > if not
: > : > asked default to some sort of notification protocol? Should we simply
: > go
: > : > with the "first to publish" rule like for public issues? Other options?
: > : >
: > : >
: > :
: >
:
:
:
: --
:
: Kurt Seifried -- Red Hat -- Product Security -- Cloud
: PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
: Red Hat Product Security contact: [hidden email]
:
Reply | Threaded
Open this post in threaded view
|

Re: Multipel CNAs for software and coordination for issues under embargo

Kurt Seifried
No, he emailed a set of txt files to distros, for quagga, not for jenkins. Jenkins posts to oss-security@ and so on, and also send me a csv file. 

On Thu, Feb 15, 2018 at 10:19 PM, jericho <[hidden email]> wrote:

On Thu, 15 Feb 2018, Kurt Seifried wrote:

: probably because he emailed me a CSV file and I replied...

I don't understand...

2018-6356 is from MITRE I believe? Yet "he emailed you a CSV file" with
two (?) vulns that needed assignments, and you/DWF did those two
assignments?

Your reply doesn't explain why there is mixed CNA assignments here, and
what level of coordination, if any, was involved. Why would Jenkins
request one ID from MITRE, then two from the DWF CNA? That seems like a
breakdown in the CNA process to me.

Apologies, I just thought this series of assignments suggested there was a
level of coordination between two CNAs, when there may not have been.

Brian



: On Thu, Feb 15, 2018 at 8:28 PM, jericho <[hidden email]> wrote:
:
: > Lot of ideas on this, but perhaps today's interesting assignments around
: > Jenkins may help the discussion? How exactly did one Jenkins disclosure
: > get three CVEs from two CNAs? I assume there had to be coordination in
: > advance of this?
: >
: > CVE-2018-1000067          Jenkins LTS   SECURITY-506
: > CVE-2018-1000068          Jenkins LTS   SECURITY-717
: > CVE-2018-6356             Jenkins LTS   SECURITY-705
: >
: > The Jenkins advisory, as of this email, only includes 2018-6356 and two
: > instances of "CVE pending".
: >
: > .b
: >
: > On Thu, 15 Feb 2018, Pascal Meunier wrote:
: >
: > : Another approach might be pre-agreements or other criteria between CNAs
: > that, in this
: > : type of situation, resolve the overlapping scopes ahead of time.  For
: > example, CNAs
: > : could agree to monitor non-overlapping lists, or stake a unique claim to
: > the
: > : responsibility for monitoring a certain source or type of source.
: > :
: > : Pascal
: > :
: > : On Thu, 2018-02-15 at 16:36 -0700, Kurt Seifried wrote:
: > : > So we now have a failure case, an embargoed set of issues were posted
: > to
: > : > the distros list, I was not explicitly asked to assign CVE's, but did,
: > and
: > : > it turns out CERT also assigned CVEs. CERT published first, so I
: > reject'ed
: > : > mine (https://github.com/CVEProject/cvelist/pull/314).
: > : >
: > : > This brings up the issue of what do we do when a reporter has an
: > issue(s)
: > : > and doesn't explicitly ask a CNA for CVEs, but more than one CNA see
: > it,
: > : > and want to assign a CVE to it because the issues would significantly
: > : > benefit from CVEs? Most scopes do not overlap, with one glaring
: > exception,
: > : > "Open Source".
: > : >
: > : > So thoughts/comments? Should we only assign a CVE if asked, and then
: > if not
: > : > asked default to some sort of notification protocol? Should we simply
: > go
: > : > with the "first to publish" rule like for public issues? Other options?
: > : >
: > : >
: > :
: >
:
:
:
: --
:
: Kurt Seifried -- Red Hat -- Product Security -- Cloud
: PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
: Red Hat Product Security contact: [hidden email]
:



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Multipel CNAs for software and coordination for issues under embargo

Art Manion
In reply to this post by Kurt Seifried
On 2/15/18 6:36 PM, Kurt Seifried wrote:
> So we now have a failure case, an embargoed set of issues were posted to the distros list, I was not explicitly asked to assign CVE's, but did, and it turns out CERT also assigned CVEs. CERT published first, so I reject'ed mine (https://github.com/CVEProject/cvelist/pull/314).

CERT/CC will be submitting entries this evening, sorry for the timing.

https://www.debian.org/security/2018/dsa-4115
http://savannah.nongnu.org/forum/forum.php?forum_id=9095

  - Art
Reply | Threaded
Open this post in threaded view
|

Re: Multipel CNAs for software and coordination for issues under embargo

Kurt Seifried
In reply to this post by Pascal Meunier
one challenge is when an embargoed item is sent to multiple parties through multiple channels, potentially with more than one CNA per channel....

On Thu, Feb 15, 2018 at 8:16 PM, Pascal Meunier <[hidden email]> wrote:
Another approach might be pre-agreements or other criteria between CNAs that, in this
type of situation, resolve the overlapping scopes ahead of time.  For example, CNAs
could agree to monitor non-overlapping lists, or stake a unique claim to the
responsibility for monitoring a certain source or type of source.

Pascal

On Thu, 2018-02-15 at 16:36 -0700, Kurt Seifried wrote:
> So we now have a failure case, an embargoed set of issues were posted to
> the distros list, I was not explicitly asked to assign CVE's, but did, and
> it turns out CERT also assigned CVEs. CERT published first, so I reject'ed
> mine (https://github.com/CVEProject/cvelist/pull/314).
>
> This brings up the issue of what do we do when a reporter has an issue(s)
> and doesn't explicitly ask a CNA for CVEs, but more than one CNA see it,
> and want to assign a CVE to it because the issues would significantly
> benefit from CVEs? Most scopes do not overlap, with one glaring exception,
> "Open Source".
>
> So thoughts/comments? Should we only assign a CVE if asked, and then if not
> asked default to some sort of notification protocol? Should we simply go
> with the "first to publish" rule like for public issues? Other options?
>
>



--

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