T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:16
- Finding
- Vault encryption secrets exposed through command-line arguments and environment variables## Vulnerability Details **File Location**: `SKILL.md`, lines 16-17 and 30-33 **Vulnerability Type**: Secret exposure through insecure credential handling **Risk Level**: Medium ### Vulnerable Code ```sh - For headless servers: `export OBSYNC_KEYRING_BACKEND=file` - Optionally set keyring password: `export OBSYNC_KEYRING_PASSWORD=mysecret` ``` ```sh - Pull vault: `obsync pull "My Notes" ~/notes -p "e2e-password"` - Pull and save password: `obsync pull "My Notes" ~/notes -p "e2e-password" -s` - Push local changes: `obsync push "My Notes" ~/notes -p "e2e-password"` - Watch (continuous sync): `obsync watch "My Notes" ~/notes -p "e2e-password"` ``` ### Technical Analysis The documentation encourages users to provide the vault end-to-end encryption password directly through the `-p` command-line option. Secrets placed in commands can be retained in shell history and may be exposed through process inspection, terminal recording, diagnostics, monitoring agents, or verbose operational logs. The keyring password is also assigned to an exported environment variable. Exported variables are inherited by child processes and can consequently become accessible to compromised subprocesses, debugging tools, crash-reporting systems, or other processes operating with sufficient local privileges. The values shown are examples rather than confirmed production credentials. The vulnerability is the documented secret-handling pattern, which users are likely to reproduce with real credentials. ### Attack Path 1. A user follows the documented command and substitutes a real vault encryption password for `e2e-password`. 2. The shell records the complete command in its history, or the password appears in the process argument list while `obsync` is running. 3. A local attacker, compromised monitoring component, or process with access to the user's shell history or process metadata obtains the password. 4. Alternatively, the user exports ...[truncated 813 chars]
- Remediation
- ## Remediation Suggestions - Prefer interactive, non-echoing password input from a terminal rather than command-line password arguments. - Support reading secrets from a protected file descriptor, operating-system credential store, or dedicated secret-management service. - Replace examples containing inline password values with interactive commands and explicit warnings not to place secrets in shell commands. - Avoid exporting long-lived secret variables. If environment-based input is unavoidable, scope it to one process, clear it immediately afterward, and document its exposure risks. - Ensure verbose and JSON output never includes credentials, authentication tokens, encryption keys, or password-derived material. - For file-backed keyring storage, document restrictive file and directory permissions, such as user-only access, and ensure the CLI enforces secure permissions when creating files. - Advise users to remove any previously entered credential-bearing commands from shell history and rotate credentials if exposure is suspected.