T05 · Unauthorized Access and Privilege Escalation
Warning
- Location
- HOOK.md:9
- Finding
- Unused Cron Permission Violates Least Privilege<![CDATA[ ## Vulnerability Details **File Location**: `HOOK.md:9-11` **Vulnerability Type**: Excessive system permission **Risk Level**: Medium ### Vulnerable Code ```yaml permissions: - node:exec - system:cron ``` ### Technical Analysis The Skill requests the `system:cron` permission even though `scripts/audit.js` does not use a cron API or register a scheduled task. The documented weekly audit is instead created through a command that users manually run. The `node:exec` capability is consistent with the declared host-auditing functionality, but direct cron access is unnecessary for the current implementation. It introduces a cross-session persistence capability beyond the minimum privileges required to run an on-demand security scan. No evidence was found that the current code automatically abuses this permission or creates a hidden scheduled task. The issue is the unnecessary availability of a persistence primitive if the Skill or its execution path is subsequently modified or compromised. ### Attack Path 1. A user installs the Skill and grants all permissions declared in `HOOK.md`. 2. The Skill receives `system:cron` access despite not requiring it for the implemented scanner. 3. An attacker compromises or replaces the Skill entry point, or a future update introduces malicious behavior. 4. The altered code uses the already granted cron capability to register a recurring command. 5. The command continues to execute after the original Skill run completes. ### Impact Assessment A compromised Skill could potentially establish recurring execution under the privilege level provided by the OpenClaw cron subsystem. The resulting scope depends on the runtime identity and cron API restrictions, but it may include persistent access to managed-node operations. There is no evidence that the current version actually performs this attack. ]]>
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove `system:cron` from the manifest: ```yaml permissions: - node:exec ``` 2. Continue documenting scheduling as a separate, explicit user action if direct scheduling is not required. 3. If in-Skill scheduling is implemented later, request the permission only when the user enables that feature. 4. Before registration, display the exact schedule, command, execution identity, output destination, and removal procedure. 5. Require explicit confirmation and provide a command or interface for listing and deleting the resulting scheduled task. ]]>