Skip to content

Latest commit

 

History

History
156 lines (119 loc) · 11.8 KB

mitigations.md

File metadata and controls

156 lines (119 loc) · 11.8 KB

Mitigation Strategies Analysis for commaai/openpilot

Mitigation Strategy: Rigorous Input Validation and Sanitization

  • Description:

    1. CAN Message Whitelist (in messaging and can modules): Implement a strict, comprehensive whitelist of allowed CAN message IDs and data fields within the openpilot code. Reject any message not on this list. This is the first line of defense against malicious CAN injection.
    2. Data Range Checks (per message/field): For each allowed CAN message and data field, define and enforce minimum and maximum acceptable values within the message processing logic. Reject any data outside these bounds.
    3. Rate Limiting (for dynamic values): Implement rate limiting for rapidly changing values (steering, acceleration). Track previous values and timestamps, and reject changes exceeding defined limits.
    4. Redundancy and Cross-Validation (using multiple sensors): Where multiple sensors provide the same data (e.g., speed), compare values within openpilot and flag/reject discrepancies exceeding a threshold.
    5. Checksum/Integrity Checks (on CAN and sensor data): Verify checksums or other integrity checks provided by the CAN protocol or sensor data streams before processing the data within openpilot.
    6. Temporal Consistency Checks (beyond rate limiting): Implement logic to detect physically impossible changes in sensor data (e.g., instantaneous acceleration changes).

  • Threats Mitigated:

    • CAN Bus Injection Attacks (Severity: Critical): Directly prevents malicious CAN messages from affecting openpilot's behavior.
    • Sensor Spoofing (Severity: Critical): Reduces the impact of manipulated sensor data.
    • Faulty Sensor Data (Severity: High): Helps detect and reject erroneous data from malfunctioning sensors.

  • Impact:

    • CAN Bus Injection Attacks: Risk significantly reduced (critical to low/negligible).
    • Sensor Spoofing: Risk significantly reduced (critical to moderate/low).
    • Faulty Sensor Data: Risk significantly reduced (high to moderate/low).

  • Currently Implemented:

    • Partial implementation exists in messaging and can related modules. Basic message ID checks and some data range checks are present. Some redundancy checking exists.

  • Missing Implementation:

    • Comprehensive Whitelist: The whitelist needs to be more rigorous and cover all potential attack vectors.
    • Consistent Rate Limiting: Rate limiting needs to be applied more consistently to all relevant data fields.
    • Advanced Temporal Consistency: More sophisticated temporal consistency checks are needed.
    • Formal Verification: Formal methods could be used to verify the correctness of the input handling code.

Mitigation Strategy: Secure Boot and Code Signing Verification

  • Description:

    1. Signature Verification (at boot): Before executing the openpilot software, the bootloader (or a dedicated verification module) must verify the digital signature of the openpilot code against a trusted public key. This is typically handled by the underlying operating system and bootloader, but openpilot should rely on this verification.
    2. Integrity Checks (during runtime): Implement periodic (or event-triggered) integrity checks within the running openpilot process. This could involve calculating a hash of the loaded code and comparing it to a known-good hash. This detects runtime modifications.

  • Threats Mitigated:

    • Malicious Software Replacement (Severity: Critical): Ensures that only authorized, signed openpilot code is executed.
    • Unauthorized Code Modification (Severity: High): Detects modifications to the openpilot code after it has been loaded.

  • Impact:

    • Malicious Software Replacement: Risk significantly reduced (critical to low/negligible).
    • Unauthorized Code Modification: Risk reduced (high to moderate/low).

  • Currently Implemented:

    • Initial signature verification at boot is generally implemented (relies on the underlying OS and bootloader).

  • Missing Implementation:

    • Runtime Integrity Checks: Continuous or periodic integrity checks within the running openpilot process are likely not fully implemented. This is a key area for improvement.

Mitigation Strategy: Network Segmentation and Isolation

  • Description:

    1. Firewall Rules (on panda): Configure strict firewall rules on the panda interface (or any gateway device) to allow only necessary communication between openpilot and the vehicle's CAN bus. This is a "deny all, allow only specific" policy.
    2. Limited Network Services (within openpilot): Disable any unnecessary network services (e.g., SSH, Telnet) running within the openpilot software or on the EON device. Minimize the network attack surface.
    3. VLAN Configuration (if supported): If the vehicle and network infrastructure support VLANs, configure VLANs to logically separate openpilot-related CAN traffic from other network traffic. This is often configured on the panda or a network switch.

  • Threats Mitigated:

    • Lateral Movement (Severity: High): Makes it harder for attackers to reach openpilot from other compromised systems.
    • Network-Based Attacks (Severity: Moderate): Reduces the attack surface by limiting exposed services.

  • Impact:

    • Lateral Movement: Risk significantly reduced (high to moderate/low).
    • Network-Based Attacks: Risk reduced (moderate to low).

  • Currently Implemented:

    • The panda provides some isolation.
    • Some network services may be disabled.

  • Missing Implementation:

    • Strict Firewall Rules: Panda firewall rules need to be thoroughly reviewed and tightened.
    • Comprehensive Service Hardening: A complete audit and disabling of unnecessary services on the EON and within openpilot is needed.
    • VLAN Configuration: VLAN usage is likely inconsistent and depends on the specific installation.

Mitigation Strategy: Runtime Monitoring and Anomaly Detection

  • Description:

    1. Behavioral Monitoring (within controls and other modules): Implement code to monitor the behavior of openpilot and its interactions with the vehicle. Detect deviations from expected behavior (e.g., unexpected steering commands, inconsistent sensor data).
    2. Resource Monitoring (within openpilot): Monitor CPU usage, memory usage, and network traffic of the openpilot process. Detect unusual spikes or patterns.
    3. Safety Watchdog (software-based, within openpilot): Implement a software-based watchdog timer within openpilot. This is less secure than a hardware watchdog, but still provides some protection. If the main openpilot process fails to "pet" the watchdog, it should trigger a safe shutdown or disengagement.
    4. Logging and Auditing (within openpilot): Log all relevant events (sensor data, control commands, anomalies) to a secure location. This is crucial for post-incident analysis.

  • Threats Mitigated:

    • Zero-Day Exploits (Severity: High): Can help detect and mitigate the effects of unknown vulnerabilities.
    • Sophisticated Attacks (Severity: High): Can detect attacks that bypass preventative measures.
    • Software Bugs (Severity: Moderate): Can help detect and mitigate unexpected software errors.

  • Impact:

    • Zero-Day Exploits: Risk reduced (high to moderate).
    • Sophisticated Attacks: Risk reduced (high to moderate).
    • Software Bugs: Risk reduced (moderate to low).

  • Currently Implemented:

    • Some basic runtime monitoring and safety checks exist (e.g., in the controls safety module).

  • Missing Implementation:

    • Comprehensive Behavioral Monitoring: More extensive and sophisticated behavioral monitoring is needed.
    • Robust Resource Monitoring: More detailed resource monitoring is needed.
    • Software Watchdog (Robust Implementation): A more robust software-based watchdog timer could be implemented.
    • Comprehensive Logging and Auditing: The logging system needs to be more comprehensive and secure.

Mitigation Strategy: OTA Update Security

  • Description:

    1. Signature Verification (before installation): The openpilot update mechanism must verify the digital signature of the update package before installation.
    2. Integrity Checks (before installation): Verify the integrity of the update package (e.g., using a hash) before installation.
    3. Rollback Mechanism (within openpilot): Implement a robust mechanism to roll back to the previous version if an update fails or causes problems. This should be part of the openpilot update process.
    4. Atomic Updates (within openpilot): Ensure that updates are applied atomically – either fully applied or not at all.

  • Threats Mitigated:

    • Malicious Updates (Severity: Critical): Prevents installation of tampered updates.
    • Update Failures (Severity: Moderate): Allows recovery from failed updates.

  • Impact:

    • Malicious Updates: Risk significantly reduced (critical to low/negligible).
    • Update Failures: Risk reduced (moderate to low).

  • Currently Implemented:

    • Signature verification is generally implemented.
    • Some integrity checks are likely present.

  • Missing Implementation:

    • Robust Rollback: The rollback mechanism needs to be thoroughly tested and made more robust.
    • Atomic Updates: Full atomic update implementation may be missing.

Mitigation Strategy: Fail-Safe Mechanisms and Driver Override

  • Description:

    1. Disengagement Logic (within controls): Implement robust and reliable logic for disengaging openpilot in response to:
      • Brake pedal input.
      • Steering wheel input.
      • Dedicated disengagement button.
      • Detected anomalies or errors.
    2. Alerts and Warnings (within openpilot's UI): Implement clear and unambiguous audible and visual alerts to the driver when openpilot is engaging, disengaging, or encountering problems.
    3. DMS Integration (within openpilot): If a Driver Monitoring System is present, integrate its output into openpilot's control logic. Disengage or warn the driver based on DMS data.

  • Threats Mitigated:

    • System Malfunction (Severity: High): Allows the driver to take over in case of failure.
    • Unexpected Behavior (Severity: High): Allows the driver to take over if openpilot acts unexpectedly.
    • Driver Inattention (Severity: High): Helps prevent accidents due to driver distraction (with DMS).

  • Impact:

    • System Malfunction: Risk significantly reduced (high to low).
    • Unexpected Behavior: Risk significantly reduced (high to low).
    • Driver Inattention: Risk reduced (high to moderate/low, with DMS).

  • Currently Implemented:

    • Disengagement mechanisms exist (brake, steering, button).
    • Alerts and warnings are present.
    • Some DMS integration exists.

  • Missing Implementation:

    • Redundant Disengagement: Ensure disengagement mechanisms are truly redundant and don't rely on single points of failure.
    • Comprehensive DMS Integration: DMS integration could be more robust and consistent.