GHSA-jjgp-whrp-gq8m: in-toto PGP Trust Model Not (fully) Vulnerability

MODERATE
CWE-295
Published
Advisory Summary

GHSA-jjgp-whrp-gq8m is a MODERATE pgp trust model not (fully) vulnerability (CWE-295: Improper Certificate Validation) affecting in-toto libraries in the PyPI ecosystem. The issue involves pgp trust model not (fully) considered. Remediation is available in the latest vendor maintenance releases.

GHSA-jjgp-whrp-gq8m at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-jjgp-whrp-gq8m
Severity MODERATE
CVSS v3.1 Base Score N/A
CWE Classification CWE-295: Improper Certificate Validation
Affected Product in-toto
Package Ecosystem PyPI
Published Date
Last Updated

How to Fix GHSA-jjgp-whrp-gq8m

To remediate this vulnerability, upgrade all affected in-toto dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

in-toto fixed: Latest secure release
pip install in-toto>=Latest secure release
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show in-toto

How to Check if You Are Affected

To determine whether your Python environment is affected by GHSA-jjgp-whrp-gq8m, inspect your installed packages using pip:

pip show in-toto

Analyze the terminal output to locate any version of in-toto in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than the patched release), your application is affected.

Note: The pip show in-toto command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-295: Improper Certificate Validation, where the product does not validate, or incorrectly validates, a certificate. In in-toto, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Impact This security advisory lists multiple concerns about how in-toto uses PGP keys. The findings are aggregated here, because they are all eligible to the same mitigation strategy. Note that the findings are rated with different severities (see inline) and the highest score was chosen for this advisory: - **PGP Key Creation Time Not Validated** (severity: low) in-toto does not check, if the validity period of a PGP Key (starting with the key creation time) is in the future, when copying the key from GnuPG to a layout, or when verifying signatures. A validity period in the future is usually a sign of a wrong system clock, meaning it can’t be trusted for verifying the validity period. A MITM attacker who is able to manipulate delivered software products might also be able to control the system time by manipulating NTP. In a scenario where an attacker gained control over two expired subkeys with no overlapping validity period, the attacker could set the system time to a time before the validity period of either key, resulting in both keys being accepted. - **PGP Key Revocation Not Considered** (severity: medium) in-toto does not check PGP revocation signatures, when copying the key from GnuPG to a layout, or when verifying signatures. This means that a key may still be accepted in signatures, even if it has been revoked in GnuPG. - **PGP Key Usage Flags Not Considered** (severity: low) in-toto does not check PGP usage flags, when copying the key from GnuPG to a layout, or when verifying signatures. This means that at a key may still be accepted in signatures, even if it is not permitted to sign data as per its key usage flags. Security auditors recommend to verify these properties at signature verification time. However, this is not planned, as in-toto does not rely on PGP’s trust model, because it should not be required to consult with a separate PKI/web-of-trust at verification time. Instead the project owner establishes ultimate trust by adding a PGP public key to a layout, and thus is responsible for its validity, and also to revoke the layout, if the key is no longer trusted. The same is true for PGP public keys used to verify a layout. The preferred mitigation strategy is to verify these properties when exporting a public key from GnuPG, and to clarify usage documentation that no verification against the PGP trust model is performed afterwards. ### References - "Handle GPG revocation signatures" -- https://github.com/secure-systems-lab/securesystemslib/issues/190 - "inconsistent use of GnuPG" -- https://github.com/in-toto/in-toto/issues/569

GHSA-jjgp-whrp-gq8m Affected in-toto Versions

1 component(s)
Product / Package Ecosystem Affected Versions Fixed Version
in-toto
PyPI
≤ 1.4.0

References

Frequently Asked Questions

What is GHSA-jjgp-whrp-gq8m?
GHSA-jjgp-whrp-gq8m is a security vulnerability in in-toto involving PGP trust model not (fully) considered under CWE-295: Improper Certificate Validation.
Which in-toto versions are affected?
Affected versions include releases prior to current release patches across affected packages: in-toto.
What version fixes GHSA-jjgp-whrp-gq8m?
Upgrading to current release patches (or the latest patched release for your respective branch) resolves the vulnerability.
Is in-toto affected?
Yes, in-toto is affected in releases prior to Latest secure release. Upgrade your dependency to Latest secure release or later.
What CWE is associated with GHSA-jjgp-whrp-gq8m?
GHSA-jjgp-whrp-gq8m is classified under CWE-295: Improper Certificate Validation (The product does not validate, or incorrectly validates, a certificate.).
How can I check PyPI dependencies for GHSA-jjgp-whrp-gq8m?
Run the dependency tree command: 'pip show in-toto'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-jjgp-whrp-gq8m",
  "modified" : "2023-05-11T20:48:15Z",
  "published" : "2023-05-11T20:48:15Z",
  "aliases" : [ ],
  "summary" : "in-toto: PGP trust model not (fully) considered",
  "details" : "### Impact\n\nThis security advisory lists multiple concerns about how in-toto uses PGP keys. The findings are aggregated here, because they are all eligible to the same mitigation strategy. Note that the findings are rated with different severities (see inline) and the highest score was chosen for this advisory:\n\n- **PGP Key Creation Time Not Validated** (severity: low)\n  in-toto does not check, if the validity period of a PGP Key (starting with the key creation time) is in the future, when copying the key from GnuPG to a layout, or when verifying signatures. A validity period in the future is usually a sign of a wrong system clock, meaning it can’t be trusted for verifying the validity period. A MITM attacker who is able to manipulate delivered software products might also be able to control the system time by manipulating NTP. In a scenario where an attacker gained control over two expired subkeys with no overlapping validity period, the attacker could set the system time to a time before the validity period of either key, resulting in both keys being accepted.\n\n- **PGP Key Revocation Not Considered** (severity: medium)\n in-toto does not check PGP revocation signatures, when copying the key from GnuPG to a layout, or when verifying signatures. This means that a key may still be accepted in signatures, even if it has been revoked in GnuPG.\n\n- **PGP Key Usage Flags Not Considered** (severity: low)\n  in-toto does not check PGP usage flags, when copying the key from GnuPG to a layout, or when verifying signatures. This means that at a key may still be accepted in signatures, even if it is not permitted to sign data as per its key usage flags.\n\n\nSecurity auditors recommend to verify these properties at signature verification time.\n\nHowever, this is not planned, as in-toto does not rely on PGP’s trust model, because it should not be required to consult with a separate PKI/web-of-trust at verification time. Instead the project owner establishes ultimate trust by adding a PGP public key to a layout, and thus is responsible for its validity, and also to revoke the layout, if the key is no longer trusted. The same is true for PGP public keys used to verify a layout.\n\nThe preferred mitigation strategy is to verify these properties when exporting a public key from GnuPG, and to clarify usage documentation that no verification against the PGP trust model is performed afterwards.\n\n### References\n- \"Handle GPG revocation signatures\" -- https://github.com/secure-systems-lab/securesystemslib/issues/190\n- \"inconsistent use of GnuPG\" -- https://github.com/in-toto/in-toto/issues/569\n\n",
  "severity" : [ ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "in-toto"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "last_affected" : "1.4.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/in-toto/in-toto/security/advisories/GHSA-jjgp-whrp-gq8m"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/in-toto/in-toto/issues/569"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/secure-systems-lab/securesystemslib/issues/190"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/in-toto/in-toto"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-295" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2023-05-11T20:48:15Z",
    "nvd_published_at" : null
  }
}