May 21, 2024
Applications that utilize artifacts from the Kuksa project need to rely on the secure execution of these components. 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 the funding the Eclipse Foundation received from the Alpha-Omega project.
- The audit was scoped on the KUKSA databroker and the respective Python client SDK.
- There were 19 findings, of which two had a high severity.
- The KUKSA team fixed most findings before the release of the report.
In this post, we explain some of the findings and how they were addressed. The full audit report is available here
Audit process
Together with the auditors, there was an agreement to focus the analysis on the KUKSA databroker and the Python client SDK since these are the most used deliverables of the Eclipse Kuksa project. The team at Quarkslab then based their work on the derived threat model and extended this through automated and manual static analysis. In addition, 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 without another review by Quarkslab. We can now share some examples here for findings and their fixes.
Findings
There were two findings for which the auditors assigned a high severity:
Provider can crash databroker by adding new signals
In a Kuksa deployment, so-called providers update signals by retrieving the values from the vehicle bus (e.g., CAN), converting them to VSS signals (Vehicle Signal Specification), 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 the investigation, the auditors registered 29 million signals to cause 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, which gives an impression of the usual number of expected signals.
User can crash databroker with subscription query
In the ‘sdv.databroker.v1’ API, the user can subscribe to any changes to a signal. In addition, the API allows the user to register specific filters of when to get notified and when not. For instance, one could define a query where the databroker only sends a message when the signals Vehicle.Speed is above 100 kilometers per hour. The API uses SQL to express such filters, and a user could craft specific queries, which caused the databroker to crash.
Further findings
In addition, the audit report contains one finding with medium and ten findings with low severity. There were also six more recommendations with the severity level “info”.
Examples are:
- Existing values could be overwritten with values with an older timestamp since the databroker did not properly compare the timestamps.
- It was possible to set metadata entries like the version of the databroker through the ‘sdv.databroker.v1’ API
- In the Python SDK, fuzzing detected cases where unexpected payloads caused the SDK code to crash.
Resolutions and Changes
Most findings relate to the Kuksa API ‘sdv.databroker.v1’. For several reasons, which are partially also historical, the databroker implements a second gRPC API with a smaller feature set called ‘kuksa.val.v1’. The idea was already to support only one of the existing APIs or to design an API that combines the feature sets of both APIs. Based on the results of the audit, the Kuksa team decided to trigger and accelerate the deprecation of the ‘sdv.databroker.v1’ since many features leading to the security findings are only present in that API but not in the remaining ‘kuksa.val.v1’ API. As a result, the user now explicitly needs to enable the ‘sdv.databroker.v1’ API during the start of the databroker, or it is not active anymore. However, some applications and frameworks like Eclipse Velocitas rely on features from that API. Because of that, it has not been removed from the code base yet to have an extended migration period. In addition, this allows the collection of feedback from the community on which of the now missing features should be part of the ‘kuksa.val.v1’ API or an upgraded future version. The short-term plan is to reference the audit findings in the documentation and make people aware of the security risks involved when actively enabling and using the ‘sdv.databroker.v1’ API.
For the other findings that did not relate to the ‘sdv.databroker.v1’ API, the Kuksa team implemented the proposed changes. For instance, in the Python SDK, they added the handling of several corner cases.
Deploy Kuksa in your setup
We want to thank OSTIF, the Eclipse Foundation, and Quarkslab for the great collaboration, the chance to go through this audit process, and the valuable feedback we received. We hope the results and fixes encourage you to try out and use the databroker in your use cases, e.g., through one of the SDKs currently available for Python, Android, and soon Rust.