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.
2189 vulnerabilities reference this CWE, most recent first.
GHSA-9337-8C6C-C2XG
Vulnerability from github – Published: 2023-04-12 06:30 – Updated: 2023-04-20 14:15CubeFS through 3.2.1 allows Kubernetes cluster-level privilege escalation. This occurs because DaemonSet has cfs-csi-cluster-role and can thus list all secrets, including the admin secret.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cubefs/cubefs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-30512"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2023-04-12T20:40:15Z",
"nvd_published_at": "2023-04-12T06:15:00Z",
"severity": "MODERATE"
},
"details": "CubeFS through 3.2.1 allows Kubernetes cluster-level privilege escalation. This occurs because DaemonSet has cfs-csi-cluster-role and can thus list all secrets, including the admin secret.",
"id": "GHSA-9337-8c6c-c2xg",
"modified": "2023-04-20T14:15:51Z",
"published": "2023-04-12T06:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30512"
},
{
"type": "WEB",
"url": "https://github.com/cubefs/cubefs/issues/1882"
},
{
"type": "PACKAGE",
"url": "https://github.com/cubefs/cubefs"
}
],
"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": "CubeFS allows Kubernetes cluster-level privilege escalation"
}
GHSA-93JV-WCHF-CFHW
Vulnerability from github – Published: 2022-05-13 01:49 – Updated: 2022-05-13 01:49Privilege escalation in file permissions in Intel Computing Improvement Program before version 2.2.0.03942 may allow an authenticated user to potentially execute code as administrator via local access.
{
"affected": [],
"aliases": [
"CVE-2018-12168"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-12T19:29:00Z",
"severity": "HIGH"
},
"details": "Privilege escalation in file permissions in Intel Computing Improvement Program before version 2.2.0.03942 may allow an authenticated user to potentially execute code as administrator via local access.",
"id": "GHSA-93jv-wchf-cfhw",
"modified": "2022-05-13T01:49:28Z",
"published": "2022-05-13T01:49:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-12168"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00165.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-93VF-4X6G-Q64V
Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2022-10-07 18:15A flaw was found in the Linux Kernel before 5.8-rc6 in the ZRAM kernel module, where a user with a local account and the ability to read the /sys/class/zram-control/hot_add file can create ZRAM device nodes in the /dev/ directory. This read allocates kernel memory and is not accounted for a user that triggers the creation of that ZRAM device. With this vulnerability, continually reading the device may consume a large amount of system memory and cause the Out-of-Memory (OOM) killer to activate and terminate random userspace processes, possibly making the system inoperable.
{
"affected": [],
"aliases": [
"CVE-2020-10781"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-09-16T13:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in the Linux Kernel before 5.8-rc6 in the ZRAM kernel module, where a user with a local account and the ability to read the /sys/class/zram-control/hot_add file can create ZRAM device nodes in the /dev/ directory. This read allocates kernel memory and is not accounted for a user that triggers the creation of that ZRAM device. With this vulnerability, continually reading the device may consume a large amount of system memory and cause the Out-of-Memory (OOM) killer to activate and terminate random userspace processes, possibly making the system inoperable.",
"id": "GHSA-93vf-4x6g-q64v",
"modified": "2022-10-07T18:15:55Z",
"published": "2022-05-24T17:28:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10781"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-10781"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=853eab68afc80f59f36bbdeb715e5c88c501e680"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/09/msg00025.html"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2020/06/18/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-93WW-47XF-JRMC
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02In JetBrains TeamCity before 2020.2.2, permission checks for changing TeamCity plugins were implemented improperly.
{
"affected": [],
"aliases": [
"CVE-2021-31907"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-11T12:15:00Z",
"severity": "MODERATE"
},
"details": "In JetBrains TeamCity before 2020.2.2, permission checks for changing TeamCity plugins were implemented improperly.",
"id": "GHSA-93ww-47xf-jrmc",
"modified": "2022-05-24T19:02:08Z",
"published": "2022-05-24T19:02:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31907"
},
{
"type": "WEB",
"url": "https://blog.jetbrains.com"
},
{
"type": "WEB",
"url": "https://blog.jetbrains.com/blog/2021/05/07/jetbrains-security-bulletin-q1-2021"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-943G-CPQH-7WMV
Vulnerability from github – Published: 2022-05-13 01:33 – Updated: 2022-05-13 01:33This vulnerability allows remote attackers to cause a denial-of-service condition on vulnerable installations of ZyXEL P-870H-51 DSL Router 1.00(AWG.3)D5. Authentication is not required to exploit this vulnerability. The specific flaw exists within numerous exposed CGI endpoints. The vulnerability is caused by improper access controls that allow access to critical functions without authentication. An attacker can use this vulnerability to reboot affected devices, along with other actions. Was ZDI-CAN-4540.
{
"affected": [],
"aliases": [
"CVE-2018-1164"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-02-21T14:29:00Z",
"severity": "CRITICAL"
},
"details": "This vulnerability allows remote attackers to cause a denial-of-service condition on vulnerable installations of ZyXEL P-870H-51 DSL Router 1.00(AWG.3)D5. Authentication is not required to exploit this vulnerability. The specific flaw exists within numerous exposed CGI endpoints. The vulnerability is caused by improper access controls that allow access to critical functions without authentication. An attacker can use this vulnerability to reboot affected devices, along with other actions. Was ZDI-CAN-4540.",
"id": "GHSA-943g-cpqh-7wmv",
"modified": "2022-05-13T01:33:27Z",
"published": "2022-05-13T01:33:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1164"
},
{
"type": "WEB",
"url": "https://zerodayinitiative.com/advisories/ZDI-18-135"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-943V-R8PV-7467
Vulnerability from github – Published: 2024-01-16 09:30 – Updated: 2024-08-29 21:31Vulnerability of permissions being not strictly verified in the WMS module. Successful exploitation of this vulnerability may affect service confidentiality.
{
"affected": [],
"aliases": [
"CVE-2023-52107"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-16T09:15:07Z",
"severity": "HIGH"
},
"details": "Vulnerability of permissions being not strictly verified in the WMS module. Successful exploitation of this vulnerability may affect service confidentiality.",
"id": "GHSA-943v-r8pv-7467",
"modified": "2024-08-29T21:31:00Z",
"published": "2024-01-16T09:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52107"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2024/1"
},
{
"type": "WEB",
"url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202401-0000001799925977"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-945V-V9P3-V5XW
Vulnerability from github – Published: 2026-08-05 20:03 – Updated: 2026-08-05 20:03Summary
When writing an object with metadata, the local backend applies the source-supplied mode, uid, and gid verbatim: it parses mode as an octal integer and passes it straight into os.Chmod(o.path, os.FileMode(umode)), and passes uid/gid straight into os.Chown. The value is never masked to permission bits, so any value with Go's ModeSetuid (1<<23) or ModeSetgid (1<<22) bit set causes the setuid/setgid bit to be applied. Because both the file content and its metadata come from the (attacker-controlled) source remote, an attacker stores a binary of their choosing with mode = 40000755 (and uid = 0); when the victim runs rclone copy -M <remote>: /dest, rclone writes the attacker's binary and makes it setuid. If the victim runs rclone as root (typical for system backup/restore), the uid=0 chown plus setuid produces a root-owned setuid binary with attacker content — any local user then escalates to root. When rclone runs as a non-root service user, the planted setuid binary is owned by that user, giving any local user that user's privileges (lateral escalation / persistent backdoor).
Details
backend/local/metadata.go, writeMetadataToFile():
uid, hasUID := o.parseMetadataInt(m, "uid", 10)
gid, hasGID := o.parseMetadataInt(m, "gid", 10)
if hasUID {
...
err = os.Chown(o.path, uid, gid) // source-controlled owner, no same-uid guard
}
mode, hasMode := o.parseMetadataInt(m, "mode", 8)
if hasMode && mode >= 0 {
umode := uint(mode)
if umode <= math.MaxUint32 {
err = os.Chmod(o.path, os.FileMode(umode)) // <-- raw value; ModeSetuid/ModeSetgid NOT masked off
}
}
os.Chmod/os.FileMode honor ModeSetuid/ModeSetgid/ModeSticky. There is no &^ (os.ModeSetuid|os.ModeSetgid) mask and no check that the source is trusted, so an attacker-chosen mode string sets those bits on the freshly written, attacker-controlled file. (Note: a legitimate local source reports mode in unix st_mode layout e.g. 0106755, whose bit 1<<23 is unset, so honest copies happen to drop setuid — but the attacker supplies the Go-FileMode layout 40000755 directly, which sets it.)
PoC
1) Get the official stable binary:
curl -fsSLO https://downloads.rclone.org/v1.74.3/rclone-v1.74.3-linux-amd64.zip
unzip -j rclone-v1.74.3-linux-amd64.zip '*/rclone' -d . # ./rclone -> v1.74.3
2) Create a payload (the attacker-controlled binary content) and copy it with the malicious mode metadata:
mkdir -p msrc mdst && cp /bin/true msrc/payload
./rclone copy -M --metadata-set mode=40000755 msrc mdst # 40000755 = Go FileMode setuid|0755
3) Observe — the destination file is now setuid:
stat -c '%A %a' mdst/payload
-rwsr-xr-x 4755 # 's' = setuid bit SET on attacker binary
Variants: mode=20000755 → setgid (-rwxr-sr-x); mode=60000755 → both (-rwsr-sr-x). With rclone run as root and the source object also carrying uid=0/gid=0, the file is chown'd root:root, yielding a root-owned setuid binary executable by any local user.
Impact
A victim performing a metadata-preserving copy/restore (-M) from an untrusted or compromised remote installs an attacker-chosen executable with the setuid/setgid bit set. Run as root (system backup/restore, the common case for --metadata), this is a root-owned setuid root backdoor executable by any local user → local privilege escalation to root. Run as a non-root user, it is a setuid backdoor for that service account. The companion uid/gid application lets a root-run transfer also reassign ownership of written files arbitrarily.
Remediation
Mask special bits before applying mode from metadata — os.Chmod(o.path, os.FileMode(umode).Perm()) (or umode & 0o777) — and do not honor setuid/setgid/sticky from source metadata; gate uid/gid/setuid application behind an explicit opt-in (e.g. --local-metadata-set-ownership) that is off by default, and document that -M from untrusted remotes must not restore privileged bits. Regression test: copying an object with mode=40000755/uid=0 must produce a non-setuid, caller-owned file unless the opt-in is set.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.74.3"
},
"package": {
"ecosystem": "Go",
"name": "github.com/rclone/rclone"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.74.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-05T20:03:14Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\nWhen writing an object with metadata, the local backend applies the source-supplied `mode`, `uid`, and `gid` verbatim: it parses `mode` as an octal integer and passes it straight into `os.Chmod(o.path, os.FileMode(umode))`, and passes `uid`/`gid` straight into `os.Chown`. The value is never masked to permission bits, so any value with Go\u0027s `ModeSetuid` (1\u003c\u003c23) or `ModeSetgid` (1\u003c\u003c22) bit set causes the setuid/setgid bit to be applied. Because both the file content and its metadata come from the (attacker-controlled) source remote, an attacker stores a binary of their choosing with `mode = 40000755` (and `uid = 0`); when the victim runs `rclone copy -M \u003cremote\u003e: /dest`, rclone writes the attacker\u0027s binary and makes it setuid. If the victim runs rclone as root (typical for system backup/restore), the `uid=0` chown plus setuid produces a root-owned setuid binary with attacker content \u2014 any local user then escalates to root. When rclone runs as a non-root service user, the planted setuid binary is owned by that user, giving any local user that user\u0027s privileges (lateral escalation / persistent backdoor).\n\n### Details\n`backend/local/metadata.go`, `writeMetadataToFile()`:\n```go\nuid, hasUID := o.parseMetadataInt(m, \"uid\", 10)\ngid, hasGID := o.parseMetadataInt(m, \"gid\", 10)\nif hasUID {\n ...\n err = os.Chown(o.path, uid, gid) // source-controlled owner, no same-uid guard\n}\nmode, hasMode := o.parseMetadataInt(m, \"mode\", 8)\nif hasMode \u0026\u0026 mode \u003e= 0 {\n umode := uint(mode)\n if umode \u003c= math.MaxUint32 {\n err = os.Chmod(o.path, os.FileMode(umode)) // \u003c-- raw value; ModeSetuid/ModeSetgid NOT masked off\n }\n}\n```\n`os.Chmod`/`os.FileMode` honor `ModeSetuid`/`ModeSetgid`/`ModeSticky`. There is no `\u0026^ (os.ModeSetuid|os.ModeSetgid)` mask and no check that the source is trusted, so an attacker-chosen `mode` string sets those bits on the freshly written, attacker-controlled file. (Note: a legitimate local source reports `mode` in unix `st_mode` layout e.g. `0106755`, whose bit 1\u003c\u003c23 is unset, so honest copies happen to drop setuid \u2014 but the attacker supplies the Go-`FileMode` layout `40000755` directly, which sets it.)\n\n### PoC\n1) Get the official stable binary:\n```\ncurl -fsSLO https://downloads.rclone.org/v1.74.3/rclone-v1.74.3-linux-amd64.zip\nunzip -j rclone-v1.74.3-linux-amd64.zip \u0027*/rclone\u0027 -d . # ./rclone -\u003e v1.74.3\n```\n2) Create a payload (the attacker-controlled binary content) and copy it with the malicious `mode` metadata:\n```\nmkdir -p msrc mdst \u0026\u0026 cp /bin/true msrc/payload\n./rclone copy -M --metadata-set mode=40000755 msrc mdst # 40000755 = Go FileMode setuid|0755\n```\n3) Observe \u2014 the destination file is now setuid:\n```\nstat -c \u0027%A %a\u0027 mdst/payload\n-rwsr-xr-x 4755 # \u0027s\u0027 = setuid bit SET on attacker binary\n```\nVariants: `mode=20000755` \u2192 setgid (`-rwxr-sr-x`); `mode=60000755` \u2192 both (`-rwsr-sr-x`). With rclone run as root and the source object also carrying `uid=0`/`gid=0`, the file is chown\u0027d root:root, yielding a root-owned setuid binary executable by any local user.\n\n\n### Impact\nA victim performing a metadata-preserving copy/restore (`-M`) from an untrusted or compromised remote installs an attacker-chosen executable with the setuid/setgid bit set. Run as root (system backup/restore, the common case for `--metadata`), this is a root-owned setuid root backdoor executable by any local user \u2192 local privilege escalation to root. Run as a non-root user, it is a setuid backdoor for that service account. The companion `uid`/`gid` application lets a root-run transfer also reassign ownership of written files arbitrarily.\n\n### Remediation\nMask special bits before applying mode from metadata \u2014 `os.Chmod(o.path, os.FileMode(umode).Perm())` (or `umode \u0026 0o777`) \u2014 and do not honor setuid/setgid/sticky from source metadata; gate `uid`/`gid`/setuid application behind an explicit opt-in (e.g. `--local-metadata-set-ownership`) that is off by default, and document that `-M` from untrusted remotes must not restore privileged bits. Regression test: copying an object with `mode=40000755`/`uid=0` must produce a non-setuid, caller-owned file unless the opt-in is set.",
"id": "GHSA-945v-v9p3-v5xw",
"modified": "2026-08-05T20:03:14Z",
"published": "2026-08-05T20:03:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/security/advisories/GHSA-945v-v9p3-v5xw"
},
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/commit/e58f09739a35774ca82b5211d2377ac0f2051500"
},
{
"type": "PACKAGE",
"url": "https://github.com/rclone/rclone"
},
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/releases/tag/v1.74.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "rclone local `--metadata` applies attacker-controlled mode/uid - setuid binary planted from an untrusted remote"
}
GHSA-948C-8JVF-P44X
Vulnerability from github – Published: 2025-01-07 18:30 – Updated: 2025-01-08 21:32An issue in the snxpcamd.sys component of SUNIX Multi I/O Card v10.1.0.0 allows attackers to perform arbitrary read and write actions via supplying crafted IOCTL requests.
{
"affected": [],
"aliases": [
"CVE-2024-55411"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-07T18:15:20Z",
"severity": "HIGH"
},
"details": "An issue in the snxpcamd.sys component of SUNIX Multi I/O Card v10.1.0.0 allows attackers to perform arbitrary read and write actions via supplying crafted IOCTL requests.",
"id": "GHSA-948c-8jvf-p44x",
"modified": "2025-01-08T21:32:25Z",
"published": "2025-01-07T18:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55411"
},
{
"type": "WEB",
"url": "https://github.com/heyheysky/vulnerable-driver/blob/master/CVE-2024-55411/CVE-2024-55411_snxpcamd.sys_README.md"
},
{
"type": "WEB",
"url": "https://www.sunix.com/tw"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-94H3-QPXM-R2MP
Vulnerability from github – Published: 2024-03-12 18:31 – Updated: 2024-03-12 18:31Hypervisor-Protected Code Integrity (HVCI) Security Feature Bypass Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-21431"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-12T17:15:51Z",
"severity": "HIGH"
},
"details": "Hypervisor-Protected Code Integrity (HVCI) Security Feature Bypass Vulnerability",
"id": "GHSA-94h3-qpxm-r2mp",
"modified": "2024-03-12T18:31:13Z",
"published": "2024-03-12T18:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21431"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21431"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-94XH-PRXV-W7R3
Vulnerability from github – Published: 2025-07-12 06:30 – Updated: 2025-07-12 06:30Enables an authenticated user (enrolled device) to access a service protected by Sentry even if they are not authorized according to the sentry policy to access that service. It does not enable the user to authenticate to or use the service, it just provides the tunnel access.
{
"affected": [],
"aliases": [
"CVE-2023-39338"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-12T04:15:45Z",
"severity": "MODERATE"
},
"details": "Enables an authenticated user (enrolled device) to access a service protected by Sentry even if they are not authorized according to the sentry policy to access that service. It does not enable the user to authenticate to or use the service, it just provides the tunnel access.",
"id": "GHSA-94xh-prxv-w7r3",
"modified": "2025-07-12T06:30:22Z",
"published": "2025-07-12T06:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39338"
},
{
"type": "WEB",
"url": "https://forums.ivanti.com/s/article/CVE-2023-39338"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/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.