T09 · Insecure Skill Coding Practices
- Location
SKILL.md:22- Finding
Forced Arming Bypasses Vehicle Safety Checks Before Immediate Takeoff
- Content
View full analysis
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: Highpython 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 5mTechnical 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 toGUIDEDmode and requests takeoff without validating aCOMMAND_ACKresponse 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
- An operator or agent follows the Skill's documented takeoff procedure.
- The client connects to a MAVLink endpoint and waits only for a standby heartbeat.
- The client sends
MAV_CMD_COMPONENT_ARM_DISARMwith the force-arm magic value. - ArduPilot bypasses applicable pre-arm checks that would ordinarily prevent unsafe arming.
- Without waiting for or validating command acknowledgements, the client switches to
GUIDEDmode and sendsMAV_CMD_NAV_TAKEOFF. - An unhealthy, incorrectly configured, or unintended vehicle may arm and attempt to take off.
Impact
...[truncated 476 chars]
- Remediation
View 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_ACKafter 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.
