[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rough Drafts of CVE Counting Documents

Thank you Chris. It sounds reasonably prudent to gain experience and provide the most needed hardware-related identifiers while leaving enough flexibility to formally increase the scope and commit to it later if desired. 

Pascal

On 08/30/2016 02:07 PM, Coffin, Chris wrote:

Pascal,

These are great observations and I do agree with your point of view. I have spent 
a good part of yesterday and today thinking about the best way to address this. 
One way to handle it might be to leave the door open in regards to hardware, in 
other words, just state that "some" hardware is included. This allows 
us to reserve the right to refuse assignments for hardware specific issues like 
the ones you mentioned. I have crafted a new version of the description below 
that may or may not satisfy your current concerns in this regard.

Like Kurt had added, requesters will still have to ask CNAs for CVEs 
and the CNAs don't have to provide them in cases where it isn't 
applicable or doesn't make sense. Additionally, we could add an 
inclusion decision that could specifically exclude certain situations 
(e.g., environmental impacts to hardware, etc.).

#3
"A vulnerability in the context of the CVE program, is defined as a 
weakness in the computational logic (e.g., code) found in software and some 
hardware components (e.g., firmware),  and when exploited results in a 
negative impact to confidentiality, integrity, OR availability. Mitigation 
of the vulnerabilities in this context typically involve coding changes, but 
could also include specification changes or even specification deprecations 
(e.g., removal of affected protocols or functionality in their entirety).

Chris

-----Original Message-----
From: Pascal Meunier [mailto:pmeunier@cerias.purdue.edu]
Sent: Monday, August 29, 2016 2:10 PM
To: Coffin, Chris <ccoffin@mitre.org>; Kurt Seifried <kseifried@redhat.com>; 
Booth, Harold (Fed) <harold.booth@nist.gov>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: Rough Drafts of CVE Counting Documents


The change to #1 and #2, and even more with the other change suggested by Kurt 
("weakness in the system"), would greatly increase the scope for the CVE.  CNAs 
will issue CVEs for any and all hardware vulnerable to the "row hammer effect", 
for example, and not just for the software that is particularly vulnerable (e.g., 
CVE-2015-0565).  This could create an explosion of IDs requests, as some hardware 
combinations may make things worse or better -- will we keep track of all combinations?  
Next we'll get ID requests for overclocked hardware (if overclocking is allowed), or 
hardware under borderline or unusual temperatures, dirty hardware, under brownouts and for 
every device that hangs, crashes or reboots because it could indicate a vulnerability.  
Will boards that have common chips be grouped under the same CVE ID?  How different is 
different enough so you'll issue 2 or 2000 different IDs?  The counting document doesn't 
address hardware, I think.  It seems we just almost stumbled and now we want to tackle a 
parcours du combattant.

Changing too much too quickly can be a recipe for disaster, or at least 
great confusion and inadequacy.  I suggest pacing ourselves a bit (pun
intended) and waiting until the recent changes prove themselves viable 
and stable before making such a change of scope.  At least, the change 
in scope for the project should be something planned and directly 
decided upon instead of being incidental to revising a definition.

As a very minor wording comment, of little importance compared to the above, I 
think that the inclusion of "by a threat source," doesn't help and 
could be removed.

Pascal



On 08/29/2016 02:01 PM, Coffin, Chris wrote:

All,

Harold Booth and I had a couple of private exchanges regarding the vulnerability 
definition for the CNA Counting document. The following is the current definition as 
proposed by Pascal, as well as two of the most current iterations from Harold and I. 
The difference is obviously in the second sentence which covers both Kurt’s 
and Pascal’s original comments. I think we are leaning more towards the second 
version since it stays focused on the weakness aspect of the definition. Any thoughts 
on this would be hugely appreciated.

#0.1 (current definition from Pascal)
“A vulnerability in the context of the CVE program, is indicated by code that 
can be exploited, resulting in a negative impact to confidentiality, integrity, OR 
availability, and that requires a coding change, specification change or 
specification deprecation to mitigate or address.”

#1
“A vulnerability in the context of the CVE program, is defined as any weakness 
in the computational logic (e.g., code) found in software or hardware devices, that 
could be exploited by a threat source, and result in a negative impact to the 
security of a system. Mitigation of the vulnerabilities in this context typically 
involve coding changes, but could also include specification changes or even 
specification deprecations (e.g., removal of affected protocols or functionality in 
their entirety).”

#2
“A vulnerability in the context of the CVE program, is defined as any weakness 
in the computational logic (e.g., code) found in software or hardware devices, that 
could be exploited by a threat source, and result in a negative impact to the 
security of a system. A non-exhaustive list of examples where a weakness in logic 
could be found is in the specification of a protocol, description of an algorithm, 
design or architecture of a product, implementation, circuit layout, or fabrication 
of the product.”

Thanks Harold!

Chris

From: Kurt Seifried [mailto:kseifried@redhat.com]
Sent: Thursday, August 25, 2016 1:15 PM
To: Coffin, Chris <ccoffin@mitre.org>
Cc: cve-editorial-board-list
<cve-editorial-board-list@lists.mitre.org>
Subject: Re: Rough Drafts of CVE Counting Documents



On Thu, Aug 25, 2016 at 10:21 AM, Coffin, Chris 
<ccoffin@mitre.org<mailto:ccoffin@mitre.org>> wrote:
Kurt,

Thanks a ton for the feedback... I very much appreciate it.

FYI... I hadn't taken into account Pascal's feedback in the comments 
below, but I added Pascal's definition of vulnerability as I think it 
works very well. Thanks Pascal!



Could we add "typically requires" instead?


I added some text to the definition. Take a look and let me know if 
this works for you.


Can INC2 (Vendor acknowledgement) be expanded to include actual 
verification through a proof of concept/reproducer for example, or via 
source code examination?


I would be concerned with putting strict verification requirements at 
the inclusion stage. For vendor CNAs, I think they will most likely do 
some or all of this, and maybe we can insert this language here that 
mentions it. However, there may also be other CNAs reading this 
decision who are not the vendor or maintainer of the product/code and 
assembling this data or getting it from the vendor could take time if 
it happens at all. My feeling is that the inclusion steps should 
emphasize speed in assigning CVE IDs as opposed to getting things 
perfect up front. If a mistake is made, it can be cleaned up after the 
fact. Thoughts?

Sorry I meant that as OR, not AND, e.g. someone publishes a script that 
crashes a Linux machine and we have no idea why yet, I would say that 
should get a CVE asap.



INC3.1 "demonstrated" does this mean we need a reproducer?


Similar to the above, for a vendor CNA following this it is probably not much of 
an issue. For a CNA who is not the vendor or maintainer, such as yourself, this 
becomes more important obviously. I think you have said yourself that you get 
lots of garbage already. In my mind, "demonstrated" means can the 
requester properly describe the vulnerability and explain what it's impact is. I 
think if we force the requester to provide a PoC we may be asking for too much at 
this stage. As the bolded text states, this one is about trusting the researcher 
in their claim to a certain extent.

Ok, just wanted to make asure we were using the same value of
"Demonstrated" =)



INC4: can we better define public/private? E.g. what if a medical 
device maker plans to use a CVE for an issue that they will then inform 
ever user of directly? Ditto for aerospace/SCADA/etc.


Are you saying that we should soften language now to start including 
room for CVEs issues that will only be released to a limited group of 
users? I know we have had these discussions in the recent past, but my 
understanding was that we would wait to make this kind of change until 
CVE actually brought on some of these domains where this issue will 
come up.

I think we need to start looking at this and be ready to have in answer 
probably within the year or early next year, especially if we want to 
expand CVE to these industry types as I suspect they will have 
questions at a minimum.



INC5: "CVE IDs are assigned to products that are customer-controlled or 
customer-installable." what about on premises solutions that are locked down? I know 
many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the 
company tech services it. Ditto for other regulated items like elevators (contractually 
most elevator maintenance involves a "if anyone but us touches it, your warranty is 
totally void").


This is a really great point! This is another area that I haven't really put much 
thought into and I don't think anyone else on the board has brought up in the 
recent past. Outside of the "sort of" similar idea of SaaS (and 
possibly other xaaS), I imagine there could be IT products (e.g., appliances and 
such) produced now or in the future that could fall into this category. Similar 
to the above comments though, should we account for this in the current rules, or 
should we wait until presented with this problem such as when we bring on the 
medical devices domain?

Again above, I think we should look into this and have an answer sooner 
rather then later.


 > CNT4: I'd like to better define the embedded code situation, e.g. 
libxml/gzip situations (bits of those are everywhere!).

One thing that I noticed is that the decision language did not direct 
the CNA to defer the report to the appropriate CNA in the case of a 
shared codebase that doesn't apply to the receiving CNA (i.e., the CNA 
following the decisions based on the report). Are you looking for more 
process explanation in this case or maybe more examples? If you have 
anything specific please feel free to pass along.

So for example where does code move from "Same codebase" to "different code 
base", e.g. mysql/various forks, embedded copies of X (gzip for example), I think one good sniff 
test is "does the patch work with no or minimal changes"?



Chris


From: Kurt Seifried
[mailto:kseifried@redhat.com<mailto:kseifried@redhat.com>]
Sent: Wednesday, August 24, 2016 3:55 PM
To: Coffin, Chris <ccoffin@mitre.org<mailto:ccoffin@mitre.org>>
Cc: cve-editorial-board-list
<cve-editorial-board-list@lists.mitre.org<mailto:cve-editorial-board-l
ist@lists.mitre.org>>
Subject: Re: Rough Drafts of CVE Counting Documents

Some feedback:
A vulnerability in the context of the CVE program, is code that can be 
exploited, resulting in a negative impact to confidentiality, 
integrity, and availability, and that requires a code change to 
mitigate or address.
Some vulns are internal to the protocol and the only code change that "fixes" it 
is to remove the code/functionality altogether. Could we add "typically requires" 
instead? I'm worried about the intersection of software/API vulns that will become 
increasingly common (more instances of this, and people will start looking for them).
Can INC2 (Vendor acknowledgement) be expanded to include actual 
verification through a proof of concept/reproducer for example, or via 
source code examination?
INC3.1 "demonstrated" does this mean we need a reproducer?
INC4: can we better define public/private? E.g. what if a medical 
device maker plans to use a CVE for an issue that they will then inform 
ever user of directly? Ditto for aerospace/SCADA/etc.
INC5: "CVE IDs are assigned to products that are customer-controlled or 
customer-installable." what about on premises solutions that are locked down? I know 
many medical devices, high end manufacturing, etc you buy it, but you don't touch it, the 
company tech services it. Ditto for other regulated items like elevators (contractually 
most elevator maintenance involves a "if anyone but us touches it, your warranty is 
totally void").
CNT4: I'd like to better define the embedded code situation, e.g. 
libxml/gzip situations (bits of those are everywhere!).










On Wed, Aug 24, 2016 at 2:19 PM, Coffin, Chris 
<mailto:ccoffin@mitre.org<mailto:ccoffin@mitre.org>> wrote:
All,

Attached is a new version of the CVE Counting for CNAs document. I  
have made some changes to the counting decisions as well as provided 
some clarifications in certain decisions based on feedback from the CVE 
Team.

Chris

From:
mailto:owner-cve-editorial-board-list@lists.mitre.org<mailto:owner-cve
-editorial-board-list@lists.mitre.org>
[mailto:mailto<mailto:mailto>:owner-cve-editorial-board-list@lists.mit
re.org<mailto:owner-cve-editorial-board-list@lists.mitre.org>] On
Behalf Of Coffin, Chris
Sent: Monday, July 25, 2016 5:03 PM
To: cve-editorial-board-list
<mailto:cve-editorial-board-list@lists.mitre.org<mailto:cve-editorial-
board-list@lists.mitre.org>>
Subject: Rough Drafts of CVE Counting Documents

All,

Sorry for the delay, these were supposed to go out last week.

Attached is the latest marked up version of the Simplified Counting 
Rules, as well as the promised very rough version of a new CVE 
Vulnerability Counting for CNAs document. There is still plenty of work 
to be done on this new document, but the main focus so far has been to 
develop the decision trees. The included decision trees are meant to 
replace the older decision trees found at 
https://github.com/CVEProject/docs/blob/gh-pages/cna/application-guidance.md.

Current thinking is that the introduction of the “independently fixable” 
concept obsoletes many of the older counting decisions, but we’d be interested to 
hear others opinions on this. Also, the inclusion rules actually grew a bit, but these all 
seem to be fairly straightforward.

The Report Type decision is something that came up during internal discussions 
and is probably new to everyone. An earlier version of the doc didn’t 
have good coverage for how to count when independently fixable resulted in No 
or Not Sure. The Report Type allows for common reporting cases to be handled 
in a somewhat uniform way. The idea is to handle the most common reports and 
the recommended counting action for each. We are definitely interested in 
hearing others thoughts on this entire counting decision, as well as the 
common reports and actions that are defined.

Like I said before, this is a very early version so I am open to any 
and all feedback. Thanks in advance!

Chris Coffin
The CVE Team




--

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995
7350 148F 66BF 7554 160D 4553 5E26 7993 Red Hat Product Security
contact: mailto:secalert@redhat.com<mailto:secalert@redhat.com>



--

--
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<mailto:secalert@redhat.com>
Page Last Updated or Reviewed: September 01, 2016