Security audit for Eclipse Kuksa released

We are thrilled to announce the publication of an external security audit report for Eclipse Kuksa, a significant milestone in our ongoing commitment to secure and reliable automotive software development. Through their involvement in Eclipse KUKSA, developers from ETAS contribute to an open-source project that enables read and write access to vehicle signals using a simple and secure API. The resulting component is the Kuksa databroker, which manages data points defined by the Vehicle Signal Specification (VSS). This combination creates an abstraction layer that provides a holistic view of a vehicle, making it an ideal base for many applications in software-defined vehicle (SDV) systems.

However, these applications need to rely on the secure execution of the databroker. We are, therefore, happy to announce the publication of an external audit report carried out by Quarkslab. The audit was facilitated through OSTIF and the Eclipse Foundation and made possible by funding from the Alpha-Omega project. The audit focused on the KUKSA databroker and its respective Python client SDK. There were 19 findings, two of which had high severity. The KUKSA team addressed most findings before releasing the report.

In this post, we explain some of the findings and how they were addressed. You can access the full audit report here.

Audit process

The audit process began with an agreement to focus on analyzing the KUKSA databroker and the Python client SDK since these are the most used deliverables of the Eclipse Kuksa project. The team at Quarkslab based their work on a derived threat model and extended this through automated and manual static analysis. Additionally, they performed dynamic fuzz testing.

After completing the report, the auditors shared their results with the Kuksa team. The maintainers of Eclipse Kuksa then resolved all findings with low or higher severity. Here are some examples of those findings and their fixes.

Findings

Provider Can Crash Databroker by Adding New Signals
In a Kuksa deployment, so-called providers update signals by retrieving values from the vehicle bus (e.g., CAN), converting them to VSS signals, and then writing them to the databroker. With the Kuksa API 'sdv.databroker.v1', a provider can register new signals to extend the data model managed by the databroker during runtime. However, there was no upper limit on the number of entries a provider could add. During their investigation, auditors registered 29 million signals, causing the operating system to stop the databroker on a computer with 32 GB of RAM. The default data model of VSS 4.0 currently consists of around 1000 signals, highlighting how unusual this scenario is.

User can crash databroker with subscription query
In the 'sdv.databroker.v1' API, users can subscribe to any changes to a signal. Additionally, users can register specific filters for when they get notified or not. For instance, one could define a query where the databroker only sends a message when Vehicle.Speed is above 100 kilometers per hour. The API uses SQL to express such filters, allowing users to craft specific queries that caused the databroker to crash.

Further findings

The audit report also contains one finding with medium severity and ten findings with low severity. There were six more recommendations labeled as "info." Examples include:

Existing values could be overwritten with older timestamps since the databroker did not properly compare timestamps. It was possible to set metadata entries like version information through the ‘sdv.databroker.v1’ API. In the Python SDK, fuzzing detected cases where unexpected payloads caused crashes.

Resolutions and Changes
Most findings relate to the Kuksa API 'sdv.databroker.v1'. For several reasons—partially historical—the databroker implements a second gRPC API with a smaller feature set called 'kuksa.val.v1'. Based on audit results, we decided to accelerate deprecating 'sdv.databroker.v1' since many features leading to security issues are only present in that API but not in 'kuksa.val.v1'.

As a result:

Users now need to explicitly enable 'sdv.databroker.v1' during startup; otherwise, it remains inactive. Some applications like Eclipse Velocitas rely on features from 'sdv.databroker.v1', so it hasn't been removed yet to allow for an extended migration period. We will collect community feedback on which missing features should be part of 'kuksa.val.v1' or future versions.

For other findings unrelated to 'sdv.databroker.v1', we implemented proposed changes—for instance, handling several corner cases in Python SDK.

Deploy Kuksa in your setup

We want to thank OSTIF, Eclipse Foundation, and Quarkslab for their collaboration throughout this audit process and for providing valuable feedback. We hope these results and fixes encourage you to use the databroker in your use cases, e.g., through one of the SDKs currently available for Python, Android, and soon Rust.

Stay tuned for more updates as we continue improving Eclipse Kuksa!