Software containers drive rapid development in SDVs, but their adoption brings critical security considerations for safe deployment, writes Omar Yang, Automotive Threat Researcher, VicOne.
Software containers have revolutionized deployment and integration, significantly accelerating the development of software-defined vehicles (SDVs). They offer a consistent, isolated environment for applications, enabling rapid development, testing, and scaling. With containers, automotive manufacturers (OEMs) and suppliers can streamline updates, enhance security, and ensure reliable software performance across diverse hardware platforms in SDVs.
Indeed, software containers offer many advantages, but their growing use also brings new considerations for security. As the automotive industry increasingly adopts container technology, it’s crucial to recognize the broader implications that arise in the SDV landscape. While containers enhance efficiency and flexibility, they also require attention to potential security concerns specific to this architecture.
Container Attack Vectors
In containerized architecture, attack vectors arise from both traditional system vulnerabilities and those unique to container environments. Containers, while offering isolation and scalability, still inherit certain risks from existing architectures. These include hardware vulnerabilities, host system weaknesses, security flaws in applications running on the host, and unsecure network configurations. In addition to these, container technology introduces its own specific attack vectors, such as misconfigured container runtimes, the use of compromised or malicious container images, and container escape vulnerabilities, where attackers break out of the container’s isolation. Addressing these attack vectors requires understanding the full scope of risks posed by both traditional and container-specific vulnerabilities.
Inherited Attack Vectors
Inherited attack vectors are attack vectors that exist in traditional architectures and persist in containerized environments:
- Hardware vulnerabilities: Containers run on physical hardware, and any vulnerabilities present at the hardware level (such as Spectre, Meltdown, or Rowhammer) can be exploited. Attackers can use these vulnerabilities to gain unauthorized access to the underlying system, bypass isolation mechanisms, or impact other containers sharing the same hardware.
- Host vulnerabilities: Since containers share the host operating system kernel, any vulnerabilities in the host’s kernel or other system components can be leveraged to compromise the security of containers. An attacker exploiting a host vulnerability can gain control over the entire system, affecting all containers running on the compromised host.
- Application vulnerabilities: Applications that run natively on the host or in containers might have security flaws, such as code injection vulnerabilities, buffer overflows, or privilege escalation issues. These vulnerabilities can be exploited to gain unauthorized access to data, execute malicious code, or take control of the system.
- Unsecure networks: If the containerized environment relies on unsecure networks, attackers could intercept traffic, perform man-in-the-middle (MITM) attacks, or exploit weaknesses in network configurations to gain access to containers or their communication channels. Security gaps might include improper network segmentation or lack of encryption in communications between containers.
Container-Specific Attack Vectors
Container-specific attack vectors are attack vectors that are unique to container technology and pose additional risks:
- Misconfigured container runtime: The container runtime is responsible for managing the lifecycle of containers, including their creation, execution, and termination. Poor or incorrect configuration of the container can expose containers to security risks. For instance, if containers are run with excessive privileges (e.g., root privileges) or with improperly configured resource limits, attackers can exploit these configurations to escape the container or exhaust system resources.
- Compromised container images: Container images, which serve as the blueprint for container creation, can be a significant source of security risks if compromised. Attackers can introduce malware, backdoors, or vulnerable software into publicly available images, which are then unknowingly used in production environments. Using unverified or unsigned images can lead to the deployment of containers that are already compromised from the start.
- Container escapes: Container isolation is a fundamental security feature, but vulnerabilities in the container runtime or the kernel can allow attackers to escape the container’s sandbox. A container escape occurs when an attacker inside a container manages to break out of the isolation layer and gain access to the host system. Once on the host, the attacker can move laterally, gaining access to other containers or critical host resources.
If containers are compromised, attackers could gain escalated privileges, which they could leverage to steal personally identifiable information (PII) or even manipulate vehicle functions. For example, researchers demonstrated that containers in the connected car architecture could be compromised primarily through vulnerabilities in the in-vehicle infotainment (IVI) module and the update process. Specifically, issues such as lack of digital signature checks during software updates could allow attackers to execute arbitrary code with root privileges. These issues could impact both security and safety by allowing attackers to gain root access, potentially leading to system takeover, backdoor installation, and manipulation of critical vehicle functions — thus compromising the vehicle’s safety and driver data security.
Additionally, in a containerized architecture, all applications share the same hardware resources. If an application is poorly optimized or becomes the target of an attack, it could consume excessive system resources. This overconsumption could lead to performance degradation or even cause denial-of-service (DoS) conditions for critical automotive functions. For example, it might delay crucial decision-making processes in advanced driver assistance systems (ADASs) or hinder the responsiveness of autonomous driving features. Such delays or disruptions pose significant safety risks, as they can impair the vehicle’s ability to respond promptly to driving conditions.
Readiness for Risks in SDVs: Securing Containers Today
Here are common methods to address container attack vectors:
- Lockdown of overprivileged configuration files: A container configuration file sets the parameters for building and running containers. If not properly defined, it could lead to security risks like overprivileged containers and unsecure networks. Attackers could exploit improperly defined configuration files for malicious activities, including privilege escalation and data theft. Using solutions with “config lockdown” features can help prevent unauthorized access and ensure secure configurations.
- Lockdown of applications to prevent unauthorized or malicious programs: To reduce security risks in containerized environments, approaches such as limiting privileges, ensuring image integrity, isolating networks, controlling resources, and monitoring activities are advised. Using solutions with “container application lockdown” can further prevent unauthorized or malicious program execution.
- Adaptive container escape detection: To counter container escape attempts, continuous monitoring of abnormal behavior is vital. Attackers often display unusual patterns when trying to escape containers. Recommended solutions are those that adapt to and learn from these escape behaviors, extract attack signatures, and apply expert rules to detect and prevent similar threats effectively.
Attack methods evolve constantly. Given that cars last over 10 years, it’s essential to implement comprehensive measures to handle emerging risks. The countermeasures can be categorized into phases, with different goals and focal points.
Development Phase
The development phase focuses on secure design and coding practices to ensure that containers are built with security in mind from the beginning.
- Software quality and reliability: Implement secure coding practices, and static and dynamic code analysis.
- Supply chain security: Validate third-party libraries and dependencies and utilize a software bill of materials (SBOM) for tracking dependencies.
- Threat intelligence: Incorporate threat intelligence to design security mechanisms against vulnerabilities.
Building/Testing Phase
In the building/testing phase, the container image is built and goes through thorough security checks before it’s ready for deployment.
- Software quality and reliability: Perform continuous testing during building, ensuring no new vulnerabilities are introduced during this phase.
- Behavior analysis: Conduct initial profiling and behavior analysis based on test cases to ensure that containers behave as expected.
Release/Deployment Phase
During the release/deployment phase, the software is released and deployed into the live environment. Security measures focus on ensuring the integrity and safety of the deployed containers.
- Network segmentation and isolation: Set up isolated networks for containers, limiting inter-container communication to essential services.
- Threat intelligence: Incorporate threat intelligence during deployment to address new risks and vulnerabilities in real time.
Operation Phase
In the operation phase, containers are actively running in production. Security methods focus on monitoring, maintaining, and responding to potential incidents in real time.
- Behavior analysis: Monitor container behavior at runtime for anomalies and deviations from the expected behavior that could indicate possible compromise.
- Incident detection and response: Apply patches and security updates to containers and their underlying infrastructure.
- Regular patch management and updates: Incorporate threat intelligence during deployment to address new risks and vulnerabilities in real time.
- Threat intelligence: Continuously monitor emerging threats and update systems accordingly.
Safeguarding containers in SDVs is essential for maintaining vehicle integrity and road safety. By proactively ensuring container security, the automotive industry can prevent potential cyberattacks that threaten vehicle functionality. As SDVs become more interconnected, container security directly impacts the safety of passengers and road users, making it essential to adopt robust protective measures at every stage of the automotive software development lifecycle.
Disclaimer: The views expressed by the author are his own and do not necessarily reflect the views of FMM magazine.
Disclaimer: The views expressed by the author are his own and do not necessarily reflect the views of FMM magazine.
Omar Yang
Automotive Threat Researcher
VicOne