T05 · Unauthorized Access and Privilege Escalation
Error
- Location
- SKILL.md:8
- Finding
- Excessive Global Exposure of Multi-Cloud Credentials<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:8-29` **Vulnerability Type**: Excessive credential access and violation of least privilege **Risk Level**: High ```yaml openclaw: requires: env: - TERRADEV_RUNPOD_KEY - TERRADEV_VASTAI_KEY - TERRADEV_AWS_ACCESS_KEY_ID - TERRADEV_AWS_SECRET_ACCESS_KEY - TERRADEV_AWS_DEFAULT_REGION - TERRADEV_GCP_PROJECT_ID - TERRADEV_GCP_CREDENTIALS_PATH - TERRADEV_AZURE_SUBSCRIPTION_ID - TERRADEV_AZURE_CLIENT_ID - TERRADEV_AZURE_CLIENT_SECRET - TERRADEV_AZURE_TENANT_ID - TERRADEV_ORACLE_USER_OCID - TERRADEV_ORACLE_FINGERPRINT - TERRADEV_ORACLE_PRIVATE_KEY_PATH - TERRADEV_ORACLE_TENANCY_OCID - TERRADEV_ORACLE_REGION - TERRADEV_LAMBDA_API_KEY - TERRADEV_COREWEAVE_API_KEY - TERRADEV_CRUSOE_API_KEY - TERRADEV_TENSORDOCK_API_KEY - HF_TOKEN ``` ### Technical Analysis The Skill declares credentials for numerous unrelated cloud providers as global environment requirements. This conflicts with the document's own minimum setup, which states that a single RunPod key is sufficient for basic operation. Environment variables and referenced credential files are potentially accessible to the installed `terradev` process and its dependencies. Consequently, an operation involving only one provider could expose AWS, GCP, Azure, Oracle, Hugging Face, and other provider credentials to the same process. This breaks the principle of least privilege and unnecessarily increases the credential blast radius. The project contains only `SKILL.md`; it does not include the source of `terradev-cli`. Therefore, the claim that credentials remain local cannot be verified from the audited artifact. ### Attack Path 1. A user configures several credentials listed in the global Skill requirements. 2. The Skill invokes the externally installed `terradev` executable for a ...[truncated 1081 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove optional provider credentials from the global `requires.env` declaration. 2. Request credentials only when the user selects the corresponding provider and operation. 3. Run each provider integration with an environment containing only that provider's required variables. 4. Use short-lived, narrowly scoped credentials instead of persistent account-level keys. 5. Assign separate identities and policies for quoting, provisioning, cluster administration, and resource termination. 6. Avoid exposing private-key paths unless an Oracle operation explicitly requires them. 7. Add preflight checks that identify required credentials without printing secret values. 8. Document minimum IAM permissions for every supported operation and provider. 9. Ensure child processes do not inherit unrelated environment variables. 10. Add tests verifying that a single-provider command cannot access credentials belonging to other providers. ]]>