GHSA-wjhr-76vg-2hvc

## 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:** `<= 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:

```python 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:

```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.