version_affected attribute dropped? about automation-working-group HOT 3 CLOSED

version_value and version_affected are inadequate for representing affected versions. We need at least four parameters! See Mathematics. A complete statement should allow indication of a range. Otherwise the only way to be truthful, would be to completely enumerate all the affected versions (in which case version_affected will always be "=". If an enumeration is not possible for various reasons, we have to resort to describing it in text.

For eg., assume a product had a vuln introduced in 3.4.3 that was fixed in 3.4.5.
This is incomplete and allows misinterpretations: (what about 2.x or 3.3.x?)

version_value = 3.4.5
version affected = "<"

The truthful way to say it would be something like:

version = "3.4.*"
range_start = "3.4.3"
range_end = "3.4.5"
start = "[" or ">="
end = ")" or "<"

The current version section is inadequate and needs more work. IIRC this was postponed in favor of free text in version_value.

Translating the above to English: "3.4 versions from 3.4.3 prior to 3.4.5 are affected" which is more closer to truth than "Version prior to 3.4.5 are affected".

I would suggest not to include version_affected until this whole version representation works from some common situations.

from automation-working-group.

Comment from the meeting:

Comparing versions is a hard problem.

Yes. How two version strings are compared can change from vendor to vendor. These may not be numbers at all, could be just code words. Assume Ubuntu only used "Zesty Zapus", "Xenial Xerus", "Trusty Tahr" instead of numbers:

version = null
range_start = "Trusty Tahr"
range_end = "Xenial Xerus"
start = ">"
end = "<="

In words this translates to "versions from Trusty Tahr to Xenial Xerus are affected."

version = null
range_start = null
range_end = "Zesty Zapus"
start = null
end = "<"

In words this translates to "versions prior to Zesty Zapus are affected".

From CVE description perspective our statements are truthful.

From automated comparison perspective, I agree this representation does not help. That would needs extra information that could be specific to vendor - a problem to solve later or at CSAF (may be vendor can provide a linear list of versions). For now, I am more concerned about representing information in a complete and truthful manner. Current JSON with no ability to cater to products with two or more active branches or ranges is not helping.

from automation-working-group.

I think I have a simple solution that should work any arbitrarily complicated versioning schemes.

Product versions can be abstracted as a directed acyclic graph.
A given code change (either a problem or fix) is assumed to flow through this graph.
A version is simply a node or snapshot point on this graph which is given a label or name, mostly a string of numbers and dots. Trying to compare two versions to decide which came before or which came after, requires the knowledge of this graph. A simple string/numeric comparison may not work in all cases.

1. For most simple products this graph is linear.
2. Most commercial or widely used products can have one or more branches. The graph becomes a tree.
3. In the most complicated case some branches collapse or merge together, but the graph is still acyclic.

I feel encoding this graph in a JSON is out of scope, or can be done in future.

Assuming this graph is available somewhere else, the problem at hand is:

1. to identify a set of nodes that are known to have the problem,
2. identify a set of nodes that do not have the problem.
3. Anything else should be considered unknown.

Specifying a node and saying version_affected = "<" does not make sense for graphs or type 2 and 3. Hence this issue #42.

A simple approach would be to first identify segments/subgraphs in the graph that are linear - no branches going out or merges coming in.

Call that version_name.
Combinations of version_value and version_affected now make sense when evaluated for all nodes identified by version_name.

The proposal is to simply add a new optional version_name field to the schema.
Since this is a addition, it would not require changes to any existing tools that consume JSON.

See this for example:
https://github.com/CVEProject/cvelist/blob/master/2018/0xxx/CVE-2018-0001.json

from automation-working-group.