Vulnerability 'summary' field is neither consistent nor complete

[johnmhoran]

I noticed recently when working with a range of PURLs and vulnerabilities that:

• the content of the VCIO UI summary field (afaict this applies equally to the API responses) does not always come from the same source,
• the source is sometimes impossible to identify (for me at least), and
• the summary field value is limited to just one source (even if it varies and might be unknown) and thus omits descriptions from other vulnerability advisories (e.g., nvd.nist.gov but not ghsa or vice-versa).

In the best of all possible worlds, a consumer of vulnerability information might prefer to have access to the vulnerability description from all major advisory providers (however defined). Among the challenges of doing so is the fact that some advisories, for example many ghsa advisories, contain Description fields that have multiple headings and sometimes sub-headings and reference lists, adding to the complexity of identifying and securing the sought-after content.

I'll provide a few examples below.

[johnmhoran]

From the public UI. Summary values might not reflect carriage returns in the DB.

Example:

VCID-121u-fy4e-aaah

Summary:

Polymorphic typing issue

Source: unknown

nist.nvd.gov 'Description' field (https://nvd.nist.gov/vuln/detail/CVE-2019-17531):

A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 through 2.9.10. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint and the service has the apache-log4j-extra (version 1.2.x) jar in the classpath, and an attacker can provide a JNDI service to access, it is possible to make the service execute a malicious payload.

ghsa 'Description' field (https://github.com/advisories/GHSA-gjmw-vf9h-g25v):

A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 prior to 2.9.10.1, 2.8.11.5, and 2.6.7.3. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint and the service has the apache-log4j-extra (version 1.2.x) jar in the classpath, and an attacker can provide a JNDI service to access, it is possible to make the service execute a malicious payload.

[johnmhoran]

Example:

VCID-pu9y-1t3k-aaag

Summary:

Use of Java's default temporary directory for file creation in FileBackedOutputStream in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.

Source: looks like nvd.nist.gov (see below)

nist.nvd.gov 'Description' field (https://nvd.nist.gov/vuln/detail/CVE-2023-2976):

Use of Java's default temporary directory for file creation in FileBackedOutputStream in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.

ghsa 'Description' field (https://github.com/advisories/GHSA-7g45-4rm6-3mm3):

Use of Java's default temporary directory for file creation in FileBackedOutputStream in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class.

Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.

[johnmhoran]

Example:

VCID-arnu-neah-aaas

Summary:

OS Command Injection Growl does not properly sanitize input before passing it to exec, allowing for arbitrary command execution.

Source: unclear

nist.nvd.gov 'Description' field (https://nvd.nist.gov/vuln/detail/CVE-2017-16042):

Growl adds growl notification support to nodejs. Growl before 1.10.2 does not properly sanitize input before passing it to exec, allowing for arbitrary command execution.

ghsa 'Description' field (https://github.com/advisories/GHSA-qh2h-chj9-jffq):

Affected versions of growl do not properly sanitize input prior to passing it into a shell command, allowing for arbitrary command execution.

[johnmhoran]

Example:

VCID-uwmq-1z6g-aaap

Summary:

NATS nats-server before 2.9.23 and 2.10.x before 2.10.2 has an authentication bypass. An implicit $G user in an authorization block can sometimes be used for unauthenticated access, even when the intention of the configuration was for each user to have an account. The earliest affected version is 2.2.0.

Source: nvd.nist (see below)

nist.nvd.gov 'Description' field (https://nvd.nist.gov/vuln/detail/CVE-2023-47090):

NATS nats-server before 2.9.23 and 2.10.x before 2.10.2 has an authentication bypass. An implicit $G user in an authorization block can sometimes be used for unauthenticated access, even when the intention of the configuration was for each user to have an account. The earliest affected version is 2.2.0.

ghsa 'Description' field (https://github.com/advisories/GHSA-fr2g-9hjm-wr23):

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

NATS users exist within accounts, and once using accounts, the old authorization block is not applicable.

Problem Description

Without any authorization rules in the nats-server, users can connect without authentication.

Before nats-server 2.2.0, all authentication and authorization rules for a nats-server lived in an "authorization" block, defining users. With nats-server 2.2.0 all users live inside accounts. When using the authorization block, whose syntax predates this, those users will be placed into the implicit global account, "$G". Users inside accounts go into the newer "accounts" block.

If an "accounts" block is defined, in simple deployment scenarios this is often used only to enable client access to the system account. When the only account added is the system account "$SYS", the nats-server would create an implicit user in "$G" and set it as the no_auth_user account, enabling the same "without authentication" logic as without any rules.

This preserved the ability to connect simply, and then add one authenticated login for system access.

But with an "authorization" block, this is wrong. Users exist in the global account, with login rules. And in simple testing, they might still connect fine without administrators seeing that authentication has been disabled.

The blind-spot on our part came from encouraging and documenting a switch to using only "accounts", instead of "authorization".

In the fixed versions, using an "authorization" block will inhibit the implicit creation of a "$G" user and setting it as the no_auth_user target. In unfixed versions, just creating a second account, with no users, will also inhibit this behavior.

[mjherzog]

At a minimum VulnerableCode needs to record the origin of the Summary text and the date the Summary text was posted. Longer-term we may need to consider rules for picking the best text for the Summary based on the source. Even longer-term this might be an area to experiment with machine learning to construct a Summary from multiple texts - this might need to be a recurring Improver process to incorporate new data after the initial posting of a VCID.

[johnmhoran]

👍

[DennisClark]

Clarification of action to be taken:
At a minimum VulnerableCode needs to record an accurate source and the date the Summary text was posted.

[DennisClark]

Note: given correct severities, CVEs, etc. the summary is nice but not necessarily essential/urgent.

From another perspective: consider the real purpose and value of the summary in the first place.

Maybe ask a GPT/LLM to summarize a group of summary texts (specifying a maximum size)?