T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:22
- Finding
- Forced Arming Bypasses Vehicle Safety Checks Before Immediate Takeoff## Vulnerability Details **File Location**: `SKILL.md`, lines 22-25; repeated at lines 86-89 and 166-169 **Vulnerability Type**: Unsafe forced arming and missing command validation **Risk Level**: High ```python master.mav.command_long_send(1, 1, 400, 0, 1, 21196, 0, 0, 0, 0, 0) # ARM (force=21196) mode_map = master.mode_mapping() master.set_mode(mode_map['GUIDED']) # GUIDED master.mav.command_long_send(1, 1, 22, 0, 0, 0, 0, 0, 0, 0, 5) # TAKEOFF 5m ``` ### Technical Analysis The documented arming command supplies ArduPilot's force-arm value, `21196`. This deliberately bypasses normal pre-arm safety checks. The procedure then immediately switches the vehicle to `GUIDED` mode and requests takeoff without validating a `COMMAND_ACK` response for arming or mode transition. Although another section recommends checking GPS, that check is not enforced in any takeoff example. The workflow also does not validate battery condition, EKF health, geofence state, sensor readiness, operator authorization, target identity, or whether the vehicle is in a safe launch area. Fixed system and component identifiers (`1, 1`) further increase the chance of directing safety-critical commands to an unintended MAVLink target. The same unsafe sequence is presented multiple times, making it the recommended operational pattern rather than an isolated example. ### Attack Path 1. An operator or agent follows the Skill's documented takeoff procedure. 2. The client connects to a MAVLink endpoint and waits only for a standby heartbeat. 3. The client sends `MAV_CMD_COMPONENT_ARM_DISARM` with the force-arm magic value. 4. ArduPilot bypasses applicable pre-arm checks that would ordinarily prevent unsafe arming. 5. Without waiting for or validating command acknowledgements, the client switches to `GUIDED` mode and sends `MAV_CMD_NAV_TAKEOFF`. 6. An unhealthy, incorrectly configured, or unintended vehicle may arm and attempt to take off. ### Impact ...[truncated 476 chars]
- Remediation
- ## Remediation Suggestions - Remove the force-arm value from standard operating instructions and use normal arming procedures. - Reserve forced arming for explicitly documented emergency or controlled test scenarios, protected by a separate operator-confirmation step. - Verify the expected system ID, component ID, vehicle type, autopilot type, and connection endpoint before issuing commands. - Enforce preflight validation of GPS fix, EKF status, sensor health, battery state, geofence configuration, failsafe configuration, home position, and launch-area safety. - Wait for and validate `COMMAND_ACK` after arming, mode changes, takeoff, and landing commands. - Confirm that the vehicle is armed and in the intended mode before requesting takeoff. - Add bounded timeouts and safe abort behavior to all readiness loops. - On any failed or missing acknowledgement, stop the sequence and transition to a documented safe state rather than continuing. - Require explicit human authorization immediately before safety-critical commands are issued.
