additionalProperties is needed in other places to prevent stray field names

[ElectricNroff]

CNAs are submitting data with unofficial field names that were not intended when the JSON 5 schema is designed. For example:

field names that were only intended for use in JSON 4

"references": [{"refsource": "MyCompanyName", "url": "https://example.com/advisory123.html"}]

typo of collectionURL

"affected": [
	{
		"collectionUrl": "https://registry.npmjs.org",
		"packageName": "left-pad",
		"versions": [ ... ]
	}
]

To prevent these anomalies,

"patternProperties": {
                "^x_[^.]*$": {}
            },
"additionalProperties": false

should be added in several additional places.

[david-waltermire]

Discussed this on the 2/16/2023 call. There are a few places identified in this issue that implicitly allow extension.

Moving forward we need to:

1. Identify where additionalProperties are allowed implicitly.
2. Identify CVE list content that uses extensions in these locations.
3. Based on use (from 2 above) decide if extension should be allowed or restricted. The intent is to use x_ fields as the only allowed extension mechanism. When extension is allowed, use of x_ should be permitted. Where extension in not allowed, additionalProperties: false should be added.

Is anyone willing to help with a part of this analysis?

[ElectricNroff]

Another example is an extra field name of None in an element of the versions array, e.g.,

{"None":"Firmware version 3.3-006 and prior with BACnetstac version 4.2.1 and prior",
"lessThanOrEqual":"3.3-006","status":"affected","version":"Firmware all versions",
"versionType":"custom"}

See also #219

[mprpic]

@ElectricNroff Any ideas when this might be addressed in the schema?

[chandanbn]

It's in the 5.0.1 branch. Please try it. Feedback welcome.

[mprpic]

It's in the 5.0.1 branch. Please try it. Feedback welcome.

@chandanbn The product object still seems to be missing additionalProperties/patternProperties. And none of the objects that had an additionalProperties:false added have a patternProperties defined; is that intentional? This may cause issues in existing records if anyone already added an x_ attribute under the assumption that it was allowed but it was merely allowed because it was not restricted by the additionalProperties:false value.

Also, only slightly related to the change here, the schema for the English description object:

    "englishLanguageDescription": {
      "additionalProperties": false,
      "description": "A description with lang set to an English language (en, en_US, en_UK, and so on).",
      "properties": {
        "lang": {
          "$ref": "#/definitions/englishLanguage"
        }
      },
      "required": [
        "lang"
      ],
      "type": "object"
    },

is missing the rest of the attributes of the regular #/definitions/description object, so now that it has additionalProperties:false, it only accepts an object with lang:en, and no actual value.

[chandanbn]

Thanks Martin, re-opening the ticket. I see this needs more work :-)

[ElectricNroff]

cve-schema/schema/v5.0/CVE_JSON_5.0_schema.json

Lines 736 to 741 in 76a8bb2

	"englishLanguageDescription": {
	"type": "object",
	"description": "A description with lang set to an English language (en, en_US, en_UK, and so on).",
	"properties": {"lang": {"$ref": "#/definitions/englishLanguage"}},
	"required": ["lang"],
	"additionalProperties": false

I think the "additionalProperties": false can be deleted from the above. There is already a constraint here to prohibit properties other than lang and value in any element of a descriptions array:

cve-schema/schema/v5.0/CVE_JSON_5.0_schema.json

Lines 730 to 734 in 76a8bb2

	"required": [
	"lang",
	"value"
	],
	"additionalProperties": false

With that change, the current CVE List has only a few types of anomalous data that the proposed 5.0.1 schema would not allow:

• baseSeverity within CVSS 2.0 data, e.g., CVE-2023-3165
• refsource for a reference, e.g., CVE-2023-22812
• cweID with an incorrect uppercase 'D' character and also an empty value, e.g., CVE-2023-22931
• cweid with an incorrect lowercase 'i' character, e.g., CVE-2021-45111
• CWE-ID (wrong case/punctuation), e.g., CVE-2022-20969

In other words, steps to make 5.0.1 viable might be only the one change mentioned here, along with outreach to a small number of CNAs who submitted anomalous data in the past. The 5.0.1 changes would not interfere with any current x_ usage.

(The current CVE List also has CVE Records with the "eng" language within rejectedReasons. These are not allowed by the JSON 5.0 schema - and also would not be allowed by 5.0.1 - but were inadvertently accepted because of CVEProject/cve-services#980 - for example, CVE-2022-43830.)