ghsa-hj57-j5cw-2mwp
Vulnerability from github
Published
2022-05-25 19:37
Modified
2022-06-08 21:57
Severity ?
6.5 (Medium) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Summary
Ignition config accessible to unprivileged software on VMware
Details

Impact

Unprivileged software in VMware VMs, including software running in unprivileged containers, can retrieve an Ignition config stored in a hypervisor guestinfo variable or OVF environment. If the Ignition config contains secrets, this can result in the compromise of sensitive information.

Patches

Ignition 2.14.0 and later adds a new systemd service, ignition-delete-config.service, that deletes the Ignition config from supported hypervisors (currently VMware and VirtualBox) during the first boot. This ensures that unprivileged software cannot retrieve the Ignition config from the hypervisor.

If you have external tooling that requires the Ignition config to remain accessible in VM metadata after provisioning, and your Ignition config does not include sensitive information, you can prevent Ignition 2.14.0 and later from deleting the config by masking ignition-delete-config.service. For example:

json { "ignition": { "version": "3.0.0" }, "systemd": { "units": [ { "name": "ignition-delete-config.service", "mask": true } ] } }

Workarounds

Avoid storing secrets in Ignition configs. In addition to VMware, many cloud platforms allow unprivileged software in a VM to retrieve the Ignition config from a networked cloud metadata service. While platform-specific mitigation is possible, such as firewall rules that prevent access to the metadata service, it's best to store secrets in a dedicated platform such as Hashicorp Vault.

Advice to Linux distributions

Linux distributions that ship Ignition should ensure the new ignition-delete-config.service is installed and enabled by default.

In addition, we recommend shipping a service similar to ignition-delete-config.service that runs when existing machines are upgraded, similar to the one in https://github.com/coreos/fedora-coreos-config/pull/1738. Consider giving your users advance notice of this change, and providing instructions for masking ignition-delete-config.service on existing nodes if users have tooling that requires the Ignition config to remain accessible in VM metadata.

References

For more information, see #1300 and #1350.

For more information

If you have any questions or comments about this advisory, open an issue in Ignition or email the CoreOS development mailing list.

Show details on source website

To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coreos/ignition/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.35.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coreos/ignition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-1706"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-863",
      "CWE-921"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-05-25T19:37:37Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nUnprivileged software in VMware VMs, including software running in unprivileged containers, can retrieve an Ignition config stored in a hypervisor guestinfo variable or OVF environment.  If the Ignition config contains secrets, this can result in the compromise of sensitive information.\n\n### Patches\nIgnition 2.14.0 and later [adds](https://github.com/coreos/ignition/pull/1350) a new systemd service, `ignition-delete-config.service`, that deletes the Ignition config from supported hypervisors (currently VMware and VirtualBox) during the first boot.  This ensures that unprivileged software cannot retrieve the Ignition config from the hypervisor.\n\nIf you have external tooling that requires the Ignition config to remain accessible in VM metadata after provisioning, and your Ignition config does not include sensitive information, you can prevent Ignition 2.14.0 and later from deleting the config by masking `ignition-delete-config.service`.  For example:\n\n```json\n{\n  \"ignition\": {\n    \"version\": \"3.0.0\"\n  },\n  \"systemd\": {\n    \"units\": [\n      {\n        \"name\": \"ignition-delete-config.service\",\n        \"mask\": true\n      }\n    ]\n  }\n}\n```\n\n### Workarounds\n[Avoid storing secrets](https://coreos.github.io/ignition/operator-notes/#secrets) in Ignition configs. In addition to VMware, many cloud platforms allow unprivileged software in a VM to retrieve the Ignition config from a networked cloud metadata service. While platform-specific mitigation is possible, such as firewall rules that prevent access to the metadata service, it\u0027s best to store secrets in a dedicated platform such as [Hashicorp Vault](https://www.vaultproject.io/).\n\n### Advice to Linux distributions\nLinux distributions that ship Ignition should ensure the new `ignition-delete-config.service` is installed and enabled by default.\n\nIn addition, we recommend shipping a service similar to `ignition-delete-config.service` that runs when existing machines are upgraded, similar to the one in https://github.com/coreos/fedora-coreos-config/pull/1738. Consider giving your users advance notice of this change, and providing instructions for masking `ignition-delete-config.service` on existing nodes if users have tooling that requires the Ignition config to remain accessible in VM metadata.\n\n### References\nFor more information, see #1300 and #1350.\n\n### For more information\nIf you have any questions or comments about this advisory, [open an issue in Ignition](https://github.com/coreos/ignition/issues/new/choose) or email the CoreOS [development mailing list](https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org/).",
  "id": "GHSA-hj57-j5cw-2mwp",
  "modified": "2022-06-08T21:57:40Z",
  "published": "2022-05-25T19:37:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coreos/ignition/security/advisories/GHSA-hj57-j5cw-2mwp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coreos/ignition/issues/1300"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coreos/ignition/pull/1350"
    },
    {
      "type": "PACKAGE",
      "url": "github.com/coreos/ignition"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Ignition config accessible to unprivileged software on VMware"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.