T06 · System Persistence
Error
- Location
- SKILL.md:47
- Finding
- Recurring Scheduled Task Creates Cross-Session Persistence<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 47-55 **Vulnerability Type**: Persistent scheduled-task registration **Risk Level**: High ### Vulnerable Code Snippet ```markdown ### 4. 自动同步部署（面向未来新账号） 1. 部署同步脚本到 `%USERPROFILE%\.workbuddy\scripts\sync-my-experts.ps1`（本技能包内 `scripts/sync-my-experts.ps1` 为同一脚本副本）。脚本每次运行时实时枚举 marketplace 文件夹内容，把所有账号注册表**镜像**为该清单（内容有变化时先自动备份原文件再覆盖），写日志 `sync-my-experts.log`；脚本顶部 `$marketplaceName` 变量可切换其他本地专家仓库。 2. 注册计划任务 `WorkBuddy_SyncMyExperts`：触发器 = 用户登录时 + 每 30 分钟重复。 - 必须用 PowerShell `Register-ScheduledTask` 创建；**沙箱环境可能拦截 `schtasks.exe`，不要使用**。 - PowerShell 工具的 stdout 常被吞：验证时用 `Set-Content` 把 `Get-ScheduledTask`/`Get-ScheduledTaskInfo` 结果写入状态文件，再用 Read 工具读取确认。 ### 5. 验证与移除 ``` The associated invocation documented at `SKILL.md:60-62` is: ```powershell powershell.exe -NoProfile -ExecutionPolicy Bypass -File scripts/sync-my-experts.ps1 ``` ### Technical Analysis The Skill directs the Agent to copy a PowerShell script into the user's profile and register `WorkBuddy_SyncMyExperts` as a scheduled task. The task executes at every user login and repeats every 30 minutes, surviving both the original Skill invocation and subsequent sessions. This behavior meets the definition of system persistence. Although recurring synchronization supports the declared future-account auto-sync feature, it is not necessary for the core operation of synchronizing currently existing account registries. A manual, user-initiated synchronization would accomplish that core function without installing a durable execution mechanism. The instruction to use `Register-ScheduledTask` because a sandbox may block `schtasks.exe` is particularly concerning. A sandbox restriction is a security boundary or policy signal; selecting an alternative registration interface to achieve the same persistent effect may circumvent that restriction. The documented use of `-ExecutionPolicy Bypass` also removes a PowerShell execution-policy safe ...[truncated 1907 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Make synchronization manual and user-initiated by default. 2. Treat scheduled automation as a separate optional feature requiring explicit, informed consent. 3. Before registration, disclose: - The exact task name. - The executable and script path. - Trigger frequency. - User identity and privilege level. - Files that will be modified. - Exact removal commands. 4. Do not attempt to work around sandbox or policy restrictions. If task registration is blocked, stop and report the failure. 5. Remove `-ExecutionPolicy Bypass`. Use a signed script and a policy-compatible invocation where possible. 6. Register the task only for the current user and never request elevation unless independently justified and explicitly approved. 7. Reduce trigger frequency and prefer an application-specific event over an unconditional 30-minute schedule. 8. Restrict modification permissions on the deployed script and verify its cryptographic hash before each execution. 9. Offer a dry-run mode and require confirmation before changing multiple account registries. 10. Provide and test an uninstall operation that deletes both the task and deployed script. ]]>