T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:25
- Finding
- Unsafe Force-Formatting Guidance Based on an Unreliable Data-Absence Assumption<![CDATA[ ## Vulnerability Details **File Location**: - `SKILL.md:25` - `SKILL.md:57` - `references/disk-health-resilience-case-20260904.md:10` - `references/disk-health-resilience-case-20260904.md:30-35` **Vulnerability Type**: Destructive operation based on insufficient device validation **Risk Level**: High ### Vulnerable Code Snippets `SKILL.md:25` states that the absence of a filesystem type proves the absence of data and makes formatting safe: ```text 3. **分区归属判定以 blkid 的 FSTYPE 为准,PARTLABEL 不可信**(本机实测:sda9/sda10 是 xfs 却标 PARTLABEL="NTFS";sda11 标 "Linux /home partition" 却是无文件系统裸分区)——blkid 无 TYPE 字段 = 无文件系统 = 无数据,可安全格式化 ``` `SKILL.md:57` directs the agent to give the user an exact formatting workflow after relying on `blkid` validation: ```text 1. **mkfs/格式化在 Hermes 无条件 blocklist**——agent 即使 sudo 也执行不了(BLOCKED hardline),必须把精确命令(mkfs+mount+fstab+chown 一条龙)交给用户终端执行。给命令前先自己完成 blkid 验证消除用户疑虑 ``` `references/disk-health-resilience-case-20260904.md:10` repeats the unsafe conclusion: ```text - **sda11 2.4T 裸分区**:PARTLABEL="Linux /home partition" 误导(sda9/sda10 反而标 "NTFS"!)→ blkid 无 TYPE 字段 = 无文件系统 = 零数据 → 判定可安全格式化 ``` `references/disk-health-resilience-case-20260904.md:30-35` provides the destructive command sequence: ```bash sudo mkfs.xfs -f -L backup /dev/sda11 sudo mkdir -p /backup && sudo mount /dev/sda11 /backup echo "UUID=$(sudo blkid -s UUID -o value /dev/sda11) /backup xfs defaults,noatime 0 2" | sudo tee -a /etc/fstab sudo chown <user>:<user> /backup df -hT /backup | tail -1 ``` ### Technical Analysis The guidance incorrectly treats the absence of a `TYPE` value in `blkid` output as proof that a partition contains no data. `blkid` primarily detects recognized filesystem, RAID, swap, and other signatures. A missing result does not establish that the underlying blocks are empty or disposable. Potential explanations for a missing filesystem type include: - A damaged or partially overwritten filesystem signature. - A filesystem or storage format n ...[truncated 2520 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove every assertion that a missing `blkid TYPE` value means “no data” or “safe to format.” 2. Replace the conclusion with an explicit warning: an unidentified partition must be treated as potentially containing valuable data until independently verified. 3. Before suggesting formatting, require all of the following: - Confirm the device using stable identifiers such as `/dev/disk/by-id/`, model, serial number, capacity, and partition UUID rather than relying only on `/dev/sdX`. - Verify that the device and all descendants are unmounted. - Inspect the topology with `lsblk -f`, `lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,FSVER,LABEL,UUID,MOUNTPOINTS,MODEL,SERIAL`. - Perform non-destructive signature inspection with `wipefs -n`, `blkid -p`, and `file -s`. - Check for LVM, RAID, encryption, swap, and active holders using appropriate read-only inspection tools. - Review the partition table and confirm the exact start sector and size. - If unexplained data may exist, create a sector-level image or use recovery tooling before writing to the device. - Confirm that a separate, tested backup exists. 4. Require explicit informed user confirmation that includes the stable device identifier, model, serial number, size, partition number, and a clear warning that formatting destroys data. 5. Do not use `mkfs.xfs -f` by default. Preserve signature-detection safeguards unless an independently verified and documented reason requires force mode. 6. Separate discovery from execution. After validation, generate a proposed command but require the user to re-check the target immediately before execution. 7. Revalidate the target after any reboot, hot-plug event, storage configuration change, or elapsed time because `/dev/sdX` enumeration can change. 8. Do not append to `/etc/fstab` until formatting and mounting have succeeded and the resulting UUID has been independently verified. Also check for an existing duplicate entry befor ...[truncated 19 chars]
