GHSA-wjhr-76vg-2hvc garminconnect Has Insecure Permission Assignment for Garmin OAuth Token Store

• PyPI garminconnect: < 0.3.5 → fixed in 0.3.5

Insecure 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: ` 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: ```python 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: ```bash chmod 700 ~/.garminconnect chmod 600 ~/.garminconnect/garmin_tokens.json ``` Remediation 1. Upgrade to `garminconnect >= 0.3.5`: ```bash pip install --upgrade garminconnect ``` 2. 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 ``` 3. 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.