Technical Summary: Monitoring Vulnerabilities in Next-Generation Automotive Operating Systems

Problem Statement

The automotive industry is undergoing a radical transformation toward Software-Defined Vehicles (SDVs), shifting from distributed, proprietary Electronic Control Units (ECUs) to zonal architectures based on consolidated High-Performance Computers (HPCs). This evolution relies heavily on POSIX-compatible operating systems (e.g., Automotive Grade Linux, Android Automotive OS, Red Hat In-Vehicle OS) to support virtualization, containerization, and Over-The-Air (OTA) updates.

While this convergence accelerates feature deployment, it significantly expands the vehicle's attack surface. The integration of complex, interconnected software stacks introduces vulnerabilities common in traditional computing (e.g., Remote Code Execution, Local Privilege Escalation) into safety-critical and non-safety-critical vehicle domains.

Key Challenges Identified:

1. Relevance of CVEs: It is unclear to what extent disclosed Common Vulnerabilities and Exposures (CVEs) for POSIX/Linux ecosystems actually affect vehicle software stacks or remain exploitable in Original Equipment Manufacturer (OEM)-hardened, constrained environments.
2. Tooling Limitations: Existing vulnerability scanners are largely designed for generic container or package scanning. They often fail to parse, filter, and prioritize reports based on the specific context of automotive systems (e.g., distinguishing between developer toolchains and runtime binaries, or identifying non-exploitable utilities in a vehicle).
3. Lack of Cross-Layer Analysis: There is a scarcity of studies combining systematic vulnerability discovery with end-to-end penetration testing across the full SDV stack (Application → Middleware → OS/Hypervisor → Firmware).

Methodology

The authors propose VERA (Vulnerability Exposure and Reporting Analysis), a lightweight, offline-capable, and scalable vulnerability assessment suite designed specifically for automotive POSIX-based operating systems.

The VERA Framework

VERA operates within a Dockerized development environment to ensure reproducibility and isolation while preserving the exact filesystem, package lists, and software configurations of target systems. The architecture consists of several integrated components:

1. Scanning Engine:

   • Utilizes a local CVE dataset (MITRE CVE List V5).
   • Integrates multiple scanners: Grype and CVE Binary Tool (CBT) for container images and binaries; Vanir (Google) for Android source/code; and cve-check (Yocto Project) for Yocto-based systems.
   • Supports batch analysis of Docker images, Android emulators, and package inventories.

2. Data Processing and Normalization:

   • Parser: Aggregates results from various scanners, merges them, and normalizes data into a canonical format.
   • Filtering: Applies context-specific filters to exclude vulnerabilities irrelevant to the automotive environment. For instance, it filters out non-sudo command-line utilities (e.g., apt, git) and developer toolchains (e.g., gcc, cmake) that would not be present or usable by an attacker in a production vehicle, thereby reducing false positives.

3. Exploitability Assessment:

   • Analyser: Verifies the presence of specific vulnerable symbols or functions within binaries and traces their call paths.
   • Exploit Finder: Searches for available Proof-of-Concept (PoC) exploits and online exploit code.
   • Runner: Mounts exploits into the Docker environment to validate feasibility.

4. Risk Evaluation:

   • The framework incorporates CVSS (severity), EPSS (exploit prediction), and KEV (Known Exploited Vulnerabilities) indicators.
   • It utilizes the Automotive Threat Matrix (ATM) and TARA (Threat Analysis and Risk Assessment) methodologies from ISO/SAE 21434 to map vulnerabilities to specific attack scenarios (e.g., Initial Access, Lateral Movement, Affect Vehicle Function) and calculate feasibility and risk scores.

Key Contributions

1. Systematic Survey and Mapping: The paper provides a comprehensive survey of automotive operating systems, middleware, and deployment architectures, mapping platforms (e.g., QNX, VxWorks, AGL, AAOS) to their roles, use cases, and formal certification levels (EAL, ASIL, SIL, CAL).
2. Empirical Assessment of POSIX CVEs: The authors empirically assess how POSIX/Linux CVEs propagate into vehicle stacks. They demonstrate that while certification (e.g., ASIL D, EAL 4+) reduces risk, it does not eliminate the attack surface, as certified kernels and RTOSes still harbor significant numbers of high-severity CVEs.
3. VERA Tool Suite: The release of a specialized vulnerability scanning framework that goes beyond simple enumeration. It integrates static discovery with controlled penetration testing validation to evaluate the practical exploitability of CVEs.
4. Experimental Artifacts: The authors release the VERA source code, proof-of-concepts (PoCs), and exploit implementations to foster reproducibility and comparative analysis.

Experimental Results

The authors evaluated VERA across a diverse set of operating systems and middleware used in next-generation vehicles (e.g., Ubuntu, VxWorks, QNX Neutrino, Zephyr, ROS2, AGL, AAOS).

• Vulnerability Prevalence: The study revealed a heterogeneous vulnerability landscape.
  • High-Volume Platforms: Android-based systems (AGL, AAOS) and ROS2 exhibited the highest number of CVEs. For example, AGL had 1,203 CVEs, and Android 30 had 749.
  • Critical Severity: ROS2 was identified as having an exceptionally high-risk profile with 28 critical-severity vulnerabilities.
  • Certified Systems: Even highly certified systems like VxWorks 7 (EAL 6+) and QNX Neutrino (EAL 4+) showed significant vulnerability counts (33 and 56 CVEs, respectively), including high-severity findings.
• Filtering Efficacy: The proposed filtering mechanism significantly reduced noise. For instance, filtering reduced the reported CVEs for AutoSD by 59.8% and VxWorks 7 by 57.1%, removing non-exploitable classes like developer tools.
• Exploitability Validation:
  • The team successfully exploited CVE-2022-35737 (affecting SQLite) in an Android Automotive OS environment.
  • They implemented a de-association attack (targeting SOME/IP service discovery) which succeeded on AutoSD and TeslaOS but failed on AAOS, likely due to port randomization security mechanisms. This highlighted that identical severity ratings can lead to divergent operational outcomes based on platform configuration.
• Scenario Analysis: Two multi-stage attack scenarios were modeled:
  • Scenario A (Safety Threat): Remote compromise via a malicious infotainment app leading to vehicle function manipulation (e.g., braking).
  • Scenario B (Privacy/Control): Remote compromise for data collection and potential lateral movement to safety-critical ECUs.
  • Both scenarios were deemed feasible under specific conditions, with risk assessments ranging from Medium to High depending on the impact category (Safety, Financial, Operational, Privacy).

Significance and Claims

The paper claims to be the first work to systematically present software-stack component certifications in SDVs and to determine vehicle models' SoCs and OS configurations based on company disclosures.

Core Significance:

• Beyond Static Lists: The authors argue that raw CVE counts are imperfect proxies for risk. VERA shifts the focus from "catalogue-style" listing to measured, penetration-testing-driven validation.
• Contextual Relevance: By filtering out non-relevant vulnerabilities (e.g., tools not present in a vehicle), VERA provides a higher signal-to-noise ratio, allowing industry practitioners to prioritize remediation efforts on vulnerabilities that are truly exploitable in the automotive context.
• Certification is Not a Panacea: The results challenge the assumption that formal certifications (ISO 26262, EAL) guarantee immunity. The study demonstrates that certified platforms still possess substantial attack surfaces requiring continuous monitoring and patching.
• Practical Framework: VERA offers a practical, unified methodology for evaluating SDV security exposure, addressing the gap between theoretical vulnerability discovery and real-world exploitability assessment.

The authors maintain a modest tone regarding limitations, acknowledging that their Dockerized environment does not fully replicate vendor-specific kernel builds, proprietary firmware interactions, or hardware-dependent behaviors. They note that while their tool identifies potential attack vectors, the actual exploitability depends on specific deployment configurations and runtime defenses not always captured in static analysis.