T06 · System Persistence
Warning
- Location
- SKILL.md:151
- Finding
- Recurring Cron Hook Creates Cross-Session Persistence<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 151-157 **Vulnerability Type**: Scheduled execution and persistent session-log processing **Risk Level**: Medium ### Complete Code Snippet ```bash ### Option B — Entrée cron (automatisation passive) ```bash # Toutes les 30 min, ingérer les nouveaux JSONL */30 * * * * /bin/bash ~/.openclaw/hooks/post-session.sh >> ~/.openclaw/hebbian-harvest.log 2>&1 ``` ``` ### Technical Analysis The documented installation procedure directs users to create a cron entry that runs the post-session harvesting hook every 30 minutes. Unlike an explicitly invoked audit or memory operation, this scheduled task survives the original skill run and continues accessing session logs in future sessions. The task executes with the permissions of the user who installed the cron entry. It also relies on the mutable file `~/.openclaw/hooks/post-session.sh`. If that file is subsequently modified or replaced, cron will execute the altered content automatically without obtaining fresh user approval. This creates a durable execution path even though the documented intent is passive memory ingestion. The supplied cron entry does not include integrity verification, restrictive ownership checks, a bounded lifetime, or removal instructions. ### Attack Path 1. A user follows the documentation and installs the supplied cron entry. 2. Cron invokes `~/.openclaw/hooks/post-session.sh` every 30 minutes. 3. The hook repeatedly locates and processes newly created JSONL session logs. 4. The behavior continues across sessions and system restarts for as long as the cron entry remains installed. 5. If an attacker or another process with write access to the hook modifies it, the modified commands execute on the next cron interval under the installing user's account. ### Impact Assessment The scheduled task obtains no privileges beyond those of the user who installed it. Within that user's security context, however, it can continuou ...[truncated 261 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Remove the recurring cron installation option and require explicit, per-session user invocation. - If automation is necessary, use a narrowly scoped, auditable scheduler configuration with a documented expiration or disable mechanism. - Store the hook in a protected location and require that it be owned by the expected user and not writable by groups or other users. - Verify the hook's integrity before every scheduled execution, such as by checking a pinned cryptographic digest. - Run harvesting under a dedicated least-privileged account that can read only the intended session directory and write only to the required database. - Limit processing to newly completed sessions and maintain a secure ingestion ledger to avoid unrestricted recurring scans. - Provide explicit installation, status, disablement, and complete removal instructions. - Require affirmative user consent before enabling access to future session logs. ]]>