T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/rcon.js:158
- Finding
- Destructive RCON Commands Execute Without Enforced Confirmation or Authorization<![CDATA[ ## Vulnerability Details **File Location**: `scripts/rcon.js:158-176` **Vulnerability Type**: Missing authorization and safety enforcement for privileged commands **Risk Level**: High ### Vulnerable Code ```javascript if (require.main === module) { const args = process.argv.slice(2); if (args.length === 0) { console.log('Usage: node rcon.js "<command>"'); console.log('Examples:'); console.log(' node rcon.js "list"'); console.log(' node rcon.js "ban PlayerX griefing"'); console.log(' node rcon.js "give Steve minecraft:diamond 64"'); console.log('\nEnvironment variables:'); console.log(' MC_RCON_HOST (default: localhost)'); console.log(' MC_RCON_PORT (default: 25575)'); console.log(' MC_RCON_PASSWORD (required)'); console.log('\nTesting current RCON connection...'); testConnection().then(r => { if (r.ok) { console.log(`OK connection healthy (latency ${r.latency}ms)`); console.log(` ${r.listOutput}`); } else { console.error(`Connection failed: ${r.error}`); process.exit(1); } }); return; } const command = args.join(' '); rconExec(command) .then(result => { console.log(result); process.exit(0); }) .catch(err => { console.error(err.message); process.exit(1); }); } ``` ### Technical Analysis The command-line interface concatenates all supplied arguments and passes the result directly to `rconExec`. There is no command allowlist, argument validation, caller authorization, destructive-command detection, or confirmation-token verification. This behavior contradicts the mandatory confirmation protocol documented in `SKILL.md:132-151`. The documentation requires confirmation for operations such as `ban`, `ban-ip`, `op`, `fill`, `kill @e`, `stop`, and `save-off`, but the executable implementation does not enforce that policy. The exported `rconExec` and `rconMulti` functions also expose un ...[truncated 1498 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Implement a deny-by-default command policy in executable code rather than relying on Agent instructions. 2. Separate read-only operations, routine administrative operations, and destructive operations into distinct APIs. 3. Require a short-lived, single-use confirmation token for dangerous commands such as: - `ban` and `ban-ip` - `op` - `fill` - mass-targeted `kill` - `stop` - `save-off` - whitelist-disabling operations 4. Validate the command name and every argument against strict schemas. Do not accept arbitrary command strings where structured parameters can be used. 5. Reject command chaining, control characters, unexpected newlines, and commands not explicitly supported by the Skill. 6. Bind confirmation tokens to the exact normalized command, target server, requesting identity, and expiration time. 7. Enforce caller authorization separately from confirmation so confirmation alone cannot grant access to an unauthorized user. 8. Record immutable audit events containing the authenticated caller, normalized command, target server, confirmation identifier, timestamp, and result. 9. Use a lower-privileged server-side account or command gateway where possible instead of exposing unrestricted console authority. ]]>