Vulnerabilities without CVE and informational

[h3xstream]

Some vulnerabilities do not have CVE .. It can sometimes be a pain to request CVE for low severity bugs if the project/library doesn't handle it. For example, common-io 2.5 has some minor improvements with path that contains NULL bytes.

It would be nice to have informational "vulnerabilities" (more like simple notifications) attached to libraries that can be risky in certain context.
One example is unsafe deserialization libraries could be alert to the user. https://github.com/mbechler/marshalsec

[ashcrow]

Interesting idea. Do you have a proposal how this would look in terms of the data?

[h3xstream]

2015/
2016/
2017/
 - 001.yaml
others/
 - vdb-001.yaml
 - vdb-002.yaml

Maybe something like this. The prefix vdb- (Victims Database) would signify that it does not refer to a cve.

[ashcrow]

@h3xstream Makes sense. I assume that the internal structure of those files would be the same as the cve versions, but missing the cve info (for obvious reasons 😄).

Few more questions to round out the idea:

• Would these be issues that we don't expect to ever get a CVE?
• If a CVE was given for one of these informational entries what should we do?

[h3xstream]

@ashcrow I would migrate those to cve folder if there is a definite fix.

[ashcrow]

I 👍 the idea.

@abn @jasinner thoughts?

[jasinner]

I like the idea. There will be quite a few changes required in the API and client libraries to support these warnings. I guess we can leave it out of the API and client in the short term.

[abn]

In theory I like having the ability to extend this to cover weaknesses (CWEs) and or unclassified bugs with a security impact as well. There are a few concerns here however;

1. Who approves or validates that the issue is in fact accurate or legit? If us, this requires some form of structure around it and further tightening of merge reviews etc. While not perfect, having MITRE and other CNAs does ensure some processing before allocating CVEs.
2. If migrated, how does the revocation propagate?
3. Considering numbers are not (should not be) re-used, the others directory might end up growing indefinitely. Might be better to add sub-directories in existing year directories. (eg: java/2008/.{weakness,unclassified})
4. What are mandatory fields when populating such a definition?

I think propagation of these to the hosted service and other victims client is out of scope for this issue. If this is required to be consumed by a client or service we should probably raise respective issues as the need arises. The main changes required, would be in the validation scripts.

To summarise I think the being able to do this will be definitely a good thing. However, this would be something that would require a bit more formalisation.

[h3xstream]

Who approves or validates that the issue is in fact accurate or legit?

With references and a proper description it should be easy to manage. Good references would include : commit log, release note, paper and conference material.

What are mandatory fields when populating such a definition?

Same as the CVE except for the field cve which would be cve: vdb-001 and maybe cvss_v2: 0 for the score.

[adedov]

Hi!

JFYI, there is OVE initiative: http://www.openwall.com/ove/

IMHO, CVSS is important metric but it is hard to estimate it if you are not in context of a specific issue...