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.
2075 vulnerabilities reference this CWE, most recent first.
GHSA-WJ28-HQ3X-WG9P
Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2022-05-13 01:44Inteno iopsys 2.0-3.14 and 4.0 devices allow remote authenticated users to execute arbitrary OS commands by modifying the leasetrigger field in the odhcpd configuration to specify an arbitrary program, as demonstrated by a program located on an SMB share. This issue existed because the /etc/uci-defaults directory was not being used to secure the OpenWrt configuration.
{
"affected": [],
"aliases": [
"CVE-2017-17867"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-01-04T19:29:00Z",
"severity": "HIGH"
},
"details": "Inteno iopsys 2.0-3.14 and 4.0 devices allow remote authenticated users to execute arbitrary OS commands by modifying the leasetrigger field in the odhcpd configuration to specify an arbitrary program, as demonstrated by a program located on an SMB share. This issue existed because the /etc/uci-defaults directory was not being used to secure the OpenWrt configuration.",
"id": "GHSA-wj28-hq3x-wg9p",
"modified": "2022-05-13T01:44:31Z",
"published": "2022-05-13T01:44:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-17867"
},
{
"type": "WEB",
"url": "https://neonsea.uk/blog/2017/12/23/rce-inteno-iopsys.html"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/43428"
},
{
"type": "WEB",
"url": "http://public.inteno.se/?p=feed-inteno-openwrt.git;a=commit;h=efcc985a721107e72a66da4db66891ec54441998"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WJ8W-CMVQ-MFV8
Vulnerability from github – Published: 2022-03-17 00:00 – Updated: 2022-03-23 00:00A Improper Privilege Management vulnerability in the sudoers configuration in cscreen of openSUSE Factory allows any local users to gain the privileges of the tty and dialout groups and access and manipulate any running cscreen seesion. This issue affects: openSUSE Factory cscreen version 1.2-1.3 and prior versions.
{
"affected": [],
"aliases": [
"CVE-2022-21946"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-16T10:15:00Z",
"severity": "HIGH"
},
"details": "A Improper Privilege Management vulnerability in the sudoers configuration in cscreen of openSUSE Factory allows any local users to gain the privileges of the tty and dialout groups and access and manipulate any running cscreen seesion. This issue affects: openSUSE Factory cscreen version 1.2-1.3 and prior versions.",
"id": "GHSA-wj8w-cmvq-mfv8",
"modified": "2022-03-23T00:00:33Z",
"published": "2022-03-17T00:00:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21946"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=1196451"
}
],
"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-WJHR-76VG-2HVC
Vulnerability from github – Published: 2026-07-15 17:33 – Updated: 2026-07-15 17:33Insecure Permission Assignment for Garmin OAuth Token Store
Summary
garminconnect (≤ 0.3.4) wrote its OAuth token store to disk without restricting file-system permissions. Under the default Linux umask (022) the token file garmin_tokens.json was created world-readable (0o644). The file contains the DI refresh token, so any other local user on a shared host could read it and obtain persistent, unauthorized access to the victim's Garmin Connect account.
- Severity: High
- Weakness: CWE-732 (Incorrect Permission Assignment for Critical Resource)
- Affected versions:
<= 0.3.4 - Patched version:
0.3.5
Details
Client.dump() created the token directory and file with no mode argument, leaving permissions entirely to the process umask:
def dump(self, path: str) -> None:
p = Path(path).expanduser()
if p.is_dir() or not p.name.endswith(".json"):
p = p / "garmin_tokens.json"
p.parent.mkdir(parents=True, exist_ok=True) # no mode=
p.write_text(self.dumps()) # no permission restriction
The serialized payload includes di_token, di_refresh_token, and di_client_id. The call is in the core library (Garmin.login(tokenstore=...) persists tokens this way), and all shipped usage examples default the token store to ~/.garminconnect.
Under umask 022 the resulting permissions were:
- token directory →
0o755 garmin_tokens.json→0o644(world-readable)
A separate, unprivileged user on the same machine could read the file with a plain open() — no elevated privileges required — and extract the refresh token.
Impact
Local credential theft / privilege escalation on multi-user Linux or macOS hosts running under a permissive umask. The stolen refresh token can be exchanged for fresh access tokens via Garmin's OAuth endpoint, granting ongoing access to the victim's account (health/fitness data, activity history, device management) until the token is revoked.
Patch
Fixed in 0.3.5 (commit 77a3837). dump() now creates the directory as 0o700 and writes the token file as 0o600 regardless of umask — using os.open(..., O_CREAT|O_WRONLY|O_TRUNC, 0o600) with O_NOFOLLOW where available, plus a defensive chmod that also tightens a pre-existing loose file:
p.parent.mkdir(mode=0o700, parents=True, exist_ok=True)
with contextlib.suppress(OSError):
p.parent.chmod(0o700)
flags = os.O_WRONLY | os.O_CREAT | os.O_TRUNC
if hasattr(os, "O_NOFOLLOW"):
flags |= os.O_NOFOLLOW
fd = os.open(p, flags, 0o600)
with os.fdopen(fd, "w", encoding="utf-8") as f:
f.write(self.dumps())
with contextlib.suppress(OSError):
p.chmod(0o600)
Verified under umask 022: directory 0o700, file 0o600, no group/other access.
Workarounds
If you cannot upgrade immediately, restrict the token store manually and keep it owner-only:
chmod 700 ~/.garminconnect
chmod 600 ~/.garminconnect/garmin_tokens.json
Remediation
- Upgrade to
garminconnect >= 0.3.5:bash pip install --upgrade garminconnect - Fix any token file already on disk — upgrading only tightens permissions
on the next write, so an existing world-readable file stays exposed until
then:
bash chmod 600 ~/.garminconnect/garmin_tokens.json # or remove it and log in again to mint a fresh token store - If the file was exposed on a shared host, treat the refresh token as compromised. Re-authenticate (delete the token store and log in again) so a new token is issued; consider the previously stored token potentially read by others until rotated.
Credit
Reported by EQSTLab via a private security advisory. garminconnect thanks them for the detailed, responsible disclosure.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.3.4"
},
"package": {
"ecosystem": "PyPI",
"name": "garminconnect"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54447"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-15T17:33:00Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Insecure Permission Assignment for Garmin OAuth Token Store\n\n### Summary\n\n`garminconnect` (\u2264 0.3.4) wrote its OAuth token store to disk without restricting file-system permissions. Under the default Linux umask (`022`) the token file `garmin_tokens.json` was created world-readable (`0o644`). The file contains the DI **refresh token**, so any other local user on a shared host could read it and obtain persistent, unauthorized access to the victim\u0027s Garmin Connect account.\n\n- **Severity:** High\n- **Weakness:** CWE-732 (Incorrect Permission Assignment for Critical Resource)\n- **Affected versions:** `\u003c= 0.3.4`\n- **Patched version:** `0.3.5`\n\n### Details\n\n`Client.dump()` created the token directory and file with no `mode` argument, leaving permissions entirely to the process umask:\n\n```python\ndef dump(self, path: str) -\u003e None:\n p = Path(path).expanduser()\n if p.is_dir() or not p.name.endswith(\".json\"):\n p = p / \"garmin_tokens.json\"\n p.parent.mkdir(parents=True, exist_ok=True) # no mode=\n p.write_text(self.dumps()) # no permission restriction\n```\n\nThe serialized payload includes `di_token`, `di_refresh_token`, and `di_client_id`. The call is in the core library (`Garmin.login(tokenstore=...)` persists tokens this way), and all shipped usage examples default the token store to `~/.garminconnect`.\n\nUnder `umask 022` the resulting permissions were:\n\n- token directory \u2192 `0o755`\n- `garmin_tokens.json` \u2192 `0o644` (world-readable)\n\nA separate, unprivileged user on the same machine could read the file with a plain `open()` \u2014 no elevated privileges required \u2014 and extract the refresh token.\n\n### Impact\n\nLocal credential theft / privilege escalation on multi-user Linux or macOS hosts running under a permissive umask. The stolen refresh token can be exchanged for fresh access tokens via Garmin\u0027s OAuth endpoint, granting ongoing access to the victim\u0027s account (health/fitness data, activity history, device management) until the token is revoked.\n\n### Patch\n\nFixed in **0.3.5** (commit `77a3837`). `dump()` now creates the directory as `0o700` and writes the token file as `0o600` regardless of umask \u2014 using `os.open(..., O_CREAT|O_WRONLY|O_TRUNC, 0o600)` with `O_NOFOLLOW` where available, plus a defensive `chmod` that also tightens a pre-existing loose file:\n\n```python\np.parent.mkdir(mode=0o700, parents=True, exist_ok=True)\nwith contextlib.suppress(OSError):\n p.parent.chmod(0o700)\nflags = os.O_WRONLY | os.O_CREAT | os.O_TRUNC\nif hasattr(os, \"O_NOFOLLOW\"):\n flags |= os.O_NOFOLLOW\nfd = os.open(p, flags, 0o600)\nwith os.fdopen(fd, \"w\", encoding=\"utf-8\") as f:\n f.write(self.dumps())\nwith contextlib.suppress(OSError):\n p.chmod(0o600)\n```\n\nVerified under `umask 022`: directory `0o700`, file `0o600`, no group/other access.\n\n### Workarounds\n\nIf you cannot upgrade immediately, restrict the token store manually and keep it owner-only:\n\n```bash\nchmod 700 ~/.garminconnect\nchmod 600 ~/.garminconnect/garmin_tokens.json\n```\n\n### Remediation\n\n1. **Upgrade** to `garminconnect \u003e= 0.3.5`:\n ```bash\n pip install --upgrade garminconnect\n ```\n2. **Fix any token file already on disk** \u2014 upgrading only tightens permissions\n on the *next* write, so an existing world-readable file stays exposed until\n then:\n ```bash\n chmod 600 ~/.garminconnect/garmin_tokens.json\n # or remove it and log in again to mint a fresh token store\n ```\n3. **If the file was exposed on a shared host, treat the refresh token as\n compromised.** Re-authenticate (delete the token store and log in again) so\n a new token is issued; consider the previously stored token potentially\n read by others until rotated.\n\n### Credit\n\nReported by **EQSTLab** via a private security advisory. garminconnect thanks them for the detailed, responsible disclosure.",
"id": "GHSA-wjhr-76vg-2hvc",
"modified": "2026-07-15T17:33:00Z",
"published": "2026-07-15T17:33:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cyberjunky/python-garminconnect/security/advisories/GHSA-wjhr-76vg-2hvc"
},
{
"type": "WEB",
"url": "https://github.com/cyberjunky/python-garminconnect/commit/77a3837f1f79d486663c9646438e70e8319e1a48"
},
{
"type": "WEB",
"url": "https://github.com/cyberjunky/python-garminconnect/commit/f74174a5647e1af78eca1f8f3a0aa5dc5a899947"
},
{
"type": "PACKAGE",
"url": "https://github.com/cyberjunky/python-garminconnect"
},
{
"type": "WEB",
"url": "https://github.com/cyberjunky/python-garminconnect/releases/tag/0.3.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "garminconnect Has Insecure Permission Assignment for Garmin OAuth Token Store"
}
GHSA-WJPJ-J5W8-2M2P
Vulnerability from github – Published: 2022-04-29 03:00 – Updated: 2024-01-26 18:30BlackICE PC Protection and Server Protection installs (1) firewall.ini, (2) blackice.ini, (3) sigs.ini and (4) protect.ini with Everyone Full Control permissions, which allows local users to cause a denial of service (crash) or modify configuration, as demonstrated by modifying firewall.ini to contain a large firewall rule.
{
"affected": [],
"aliases": [
"CVE-2004-1714"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2004-08-11T04:00:00Z",
"severity": "LOW"
},
"details": "BlackICE PC Protection and Server Protection installs (1) firewall.ini, (2) blackice.ini, (3) sigs.ini and (4) protect.ini with Everyone Full Control permissions, which allows local users to cause a denial of service (crash) or modify configuration, as demonstrated by modifying firewall.ini to contain a large firewall rule.",
"id": "GHSA-wjpj-j5w8-2m2p",
"modified": "2024-01-26T18:30:30Z",
"published": "2022-04-29T03:00:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2004-1714"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/16959"
},
{
"type": "WEB",
"url": "http://lists.grok.org.uk/pipermail/full-disclosure/2004-August/025112.html"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=109223751031166\u0026w=2"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/10915"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WJV8-G39F-34GP
Vulnerability from github – Published: 2022-05-24 17:18 – Updated: 2022-05-24 17:18A Denial Of Service vulnerability exists when Connected User Experiences and Telemetry Service fails to validate certain function values.An attacker who successfully exploited this vulnerability could deny dependent security feature functionality.To exploit this vulnerability, an attacker would have to log on to an affected system and run a specially crafted application.The security update addresses the vulnerability by correcting how the Connected User Experiences and Telemetry Service validates certain function values., aka 'Connected User Experiences and Telemetry Service Denial of Service Vulnerability'. This CVE ID is unique from CVE-2020-1123.
{
"affected": [],
"aliases": [
"CVE-2020-1084"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-05-21T23:15:00Z",
"severity": "LOW"
},
"details": "A Denial Of Service vulnerability exists when Connected User Experiences and Telemetry Service fails to validate certain function values.An attacker who successfully exploited this vulnerability could deny dependent security feature functionality.To exploit this vulnerability, an attacker would have to log on to an affected system and run a specially crafted application.The security update addresses the vulnerability by correcting how the Connected User Experiences and Telemetry Service validates certain function values., aka \u0027Connected User Experiences and Telemetry Service Denial of Service Vulnerability\u0027. This CVE ID is unique from CVE-2020-1123.",
"id": "GHSA-wjv8-g39f-34gp",
"modified": "2022-05-24T17:18:26Z",
"published": "2022-05-24T17:18:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1084"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1084"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-WJW2-9CJ6-HCPH
Vulnerability from github – Published: 2022-05-24 17:22 – Updated: 2022-10-12 19:00Some sensitive cookies in SAP Disclosure Management, version 10.1, are missing HttpOnly flag, leading to sensitive cookie without Http Only flag.
{
"affected": [],
"aliases": [
"CVE-2020-6267"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-07-14T13:15:00Z",
"severity": "MODERATE"
},
"details": "Some sensitive cookies in SAP Disclosure Management, version 10.1, are missing HttpOnly flag, leading to sensitive cookie without Http Only flag.",
"id": "GHSA-wjw2-9cj6-hcph",
"modified": "2022-10-12T19:00:38Z",
"published": "2022-05-24T17:22:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6267"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/2758000"
},
{
"type": "WEB",
"url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=552599675"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WMGC-87PC-VRCV
Vulnerability from github – Published: 2023-05-24 15:30 – Updated: 2024-04-04 04:19Insecure permissions in MobileTrans v4.0.11 allows attackers to escalate privileges to local admin via replacing the executable file.
{
"affected": [],
"aliases": [
"CVE-2023-31748"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-24T15:15:09Z",
"severity": "HIGH"
},
"details": "Insecure permissions in MobileTrans v4.0.11 allows attackers to escalate privileges to local admin via replacing the executable file.",
"id": "GHSA-wmgc-87pc-vrcv",
"modified": "2024-04-04T04:19:41Z",
"published": "2023-05-24T15:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31748"
},
{
"type": "WEB",
"url": "https://packetstormsecurity.com/files/172466/MobileTrans-4.0.11-Weak-Service-Permissions.html"
},
{
"type": "WEB",
"url": "http://mobiletrans.com"
}
],
"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-WMHM-QM44-P3J4
Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-10-27 19:00Improper Access Control Tampering Vulnerability using ImportAlert function which can lead to a Remote Code Execution (RCE) from the Alerts Settings page.
{
"affected": [],
"aliases": [
"CVE-2021-35221"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-31T13:15:00Z",
"severity": "HIGH"
},
"details": "Improper Access Control Tampering Vulnerability using ImportAlert function which can lead to a Remote Code Execution (RCE) from the Alerts Settings page.",
"id": "GHSA-wmhm-qm44-p3j4",
"modified": "2022-10-27T19:00:40Z",
"published": "2022-05-24T19:12:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35221"
},
{
"type": "WEB",
"url": "https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-secure-configuration.htm"
},
{
"type": "WEB",
"url": "https://support.solarwinds.com/SuccessCenter/s/article/Mitigate-the-ImportAlert-Improper-Access-Control-Tampering-Vulnerability-CVE-2021-35221?language=en_US"
},
{
"type": "WEB",
"url": "https://support.solarwinds.com/SuccessCenter/s/article/Orion-Platform-2020-2-6-Hotfix-1?language=en_US"
},
{
"type": "WEB",
"url": "https://www.solarwinds.com/trust-center/security-advisories/cve-2021-35221"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-WMJ4-2F9Q-44Q9
Vulnerability from github – Published: 2022-04-21 00:00 – Updated: 2022-04-30 00:00The affected product is vulnerable to misconfigured binaries, allowing users on the target PC with SYSTEM level privileges access to overwrite the binary and modify files to gain privilege escalation.
{
"affected": [],
"aliases": [
"CVE-2021-38483"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-20T16:15:00Z",
"severity": "MODERATE"
},
"details": "The affected product is vulnerable to misconfigured binaries, allowing users on the target PC with SYSTEM level privileges access to overwrite the binary and modify files to gain privilege escalation.",
"id": "GHSA-wmj4-2f9q-44q9",
"modified": "2022-04-30T00:00:47Z",
"published": "2022-04-21T00:00:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38483"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-109-03"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WMQP-549H-P884
Vulnerability from github – Published: 2024-10-17 15:31 – Updated: 2024-10-17 18:31Nokia SR OS routers allow read-write access to the entire file system via SFTP or SCP for users configured with "access console." Consequently, a low privilege authenticated user with "access console" can read or replace the router configuration file as well as other files stored in the Compact Flash or SD card without using CLI commands. This type of attack can lead to a compromise or denial of service of the router after the system is rebooted.
{
"affected": [],
"aliases": [
"CVE-2023-6729"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-17T13:15:12Z",
"severity": "HIGH"
},
"details": "Nokia SR OS routers allow read-write access to the entire file system via SFTP or SCP for users configured with \"access console.\" Consequently, a low privilege authenticated user with \"access console\" can read or replace the router configuration file as well as other files stored in the Compact Flash or SD card without using CLI commands. This type of attack can lead to a compromise or denial of service of the router after the system is rebooted.",
"id": "GHSA-wmqp-549h-p884",
"modified": "2024-10-17T18:31:35Z",
"published": "2024-10-17T15:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6729"
},
{
"type": "WEB",
"url": "https://www.nokia.com/about-us/security-and-privacy/product-security-advisory/cve-2023-6729"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"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.