Security audit for Eclipse Kuksa released
Enhancing trust in automotive software development
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.
"Collaborating on open-source software accelerates innovation and streamlines the process of developing complex software by enabling developers with diverse backgrounds to collaborate on the code directly."
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.
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!
Contact us
Do you have any questions? Feel free to send us a message. We will be more than happy to help. Contact us today!