T09 · Insecure Skill Coding Practices
- Location
SKILL.md:281- Finding
Disruptive OSPF Reset Contradicts the Declared Read-Only Safety Boundary
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:281
Vulnerability Type: Read-only safety-boundary violation through a state-changing network command
Risk Level: MediumComplete Code Snippet:
text ├── State: 2-Way (expected on broadcast for DROther↔DROther) │ ├── Both routers DROther? → Normal — Full only with DR/BDR │ ├── DR/BDR election stuck? → Check priority values, verify DR is up │ └── Unexpected? → Force DR election: clear ospf process (disruptive)The conflicting read-only declaration appears in
SKILL.md:13:yaml openclaw: '{"emoji":"🔍","safetyTier":"read-only","requires":{"bins":["ssh"],"env":[]},"tags":["ospf","routing","protocol"],"mcpDependencies":[],"egressEndpoints":[]}'Technical Analysis
The Skill is declared as
read-onlyand states that read-only router privileges are sufficient. However, its troubleshooting decision tree recommendsclear ospf process, explicitly acknowledging that the operation is disruptive.Clearing an OSPF process is an administrative, state-changing operation rather than a diagnostic query. It can tear down neighbor adjacencies, discard or rebuild protocol state, and trigger LSDB synchronization and SPF recalculation. Consequently, this instruction crosses the Skill's declared safety boundary.
This is not evidence of malicious behavior, privilege escalation, or command injection. It is an insecure operational instruction because an agent or operator may trust the read-only classification and execute the recommendation without applying controls appropriate to a network-changing command.
Attack Path
- An agent loads the Skill under the assumption that all recommended operations are read-only.
- During adjacency diagnosis, the agent observes an unexpected OSPF neighbor in the
2-Waystate. - The agent follows the decision tree at
SKILL.md:281. - It executes the vendor-equivalent
clear ospf processcommand throu ...[truncated 1270 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove
clear ospf processfrom the read-only diagnostic workflow and replace it with passive checks, including:- Neighbor and interface detail inspection.
- DR/BDR role and priority verification.
- OSPF event-log review.
- Timer, area, authentication, subnet, and network-type comparison.
- If process reset guidance is operationally necessary, move it into a separate write-enabled remediation Skill that is not labeled read-only.
- Require explicit operator confirmation immediately before any state-changing command.
- Clearly state the target device, OSPF instance, expected adjacency impact, routing-domain role, and estimated blast radius.
- Require a maintenance window or emergency change authorization, along with out-of-band access and a rollback or recovery plan.
- Add a prominent warning that resetting the process can interrupt production traffic and should not be used merely to force a DR election without first validating the underlying configuration.
- Add automated policy validation that rejects configuration-changing or operational-clear commands in Skills carrying the
read-onlysafety tier.
- Remove
