Eclipse KUKSA's committers, with support from Eclipse Foundation, engaged with Quarkslab to perform an audit of Kuksa, an open-source framework that provides shared building blocks for Software Defined Vehicles. The goal of the audit was to assist the Eclipse Kuksa committers to increase their security posture using static and dynamic analysis (fuzzing in particular) and was organized by Open Source Technology Improvement Fund, Inc and made possible by the founding Eclipse Foundation received from the Alpha-Omega project.
Introduction
The open Eclipse KUKSA project aims to provide building blocks for the Software Defined Vehicles that can be shared across the industry. The Eclipse KUKSA project is composed of diverse solution pieces where the KUKSA Vehicle Abstraction Layer named KUKSA.val is the main deliverable of the project. It provides in-vehicle software components for working with in-vehicle signals which are based on Vehicle Signal Specification. The full report of the assessment can be found in the OSTIF website. All important findings have been taken into account by the Eclipse Kuksa committers following the audit and have been fixed in the meantime (not reviewed by Quarkslab). The report describes the steps of the research conducted by Quarkslab’s engineers on static analysis and fuzzing.
Scope
The scope of the audit was focused on the KUKSA.val databroker and the Python client SDK. At the time of the assessment, those two components are both distributed in the eclipse/kuksa.val GitHub repository. In the meantime, the Kuksa team moved the audited content to multiple repositories in a new GitHub organization. Quarkslab has defined a threat model to cover the security issues and provide an overview of the project’s inner workings. This step has allowed to identify the project’s purposes and critical functionalities. The security audit was based on four main attack scenarios described in detail in the full report.
Findings
The table below summarizes the findings of the audit. A total of 19 vulnerabilities were found, of which 2 had high severity, 1 had medium severity and 10 had low severity.
| ID | Title | Severity | Perimeter |
|---|---|---|---|
| HIGH-1 | A feeder can crash the databroker | High | Databroker Register Datapoints endpoint |
| HIGH-2 | Any user can crash the databroker | High | Databroker subscriptions |
| MED-1 | Recent values can be overwritten with old values | Medium | Databroker entries |
| LOW-1 | Databroker-specific entries can be modified remotely | Low | Databroker version |
| LOW-2 | Client can subscribe to unavailable scope and waits for data that will never be sent | Low | Databroker subscriptions |
| LOW-3 | An expired token can leak information about entries update timestamp | Low | Databroker subscriptions |
| LOW-4 | Entries metadata can be read by every client and feeder | Low | Databroker entries metadata |
| LOW-5 | Malicious JWT access token can crash a thread of the databroker | Low | Databroker JWT handling |
| LOW-6 | A malicious Protobuf error message can trigger an unhandled error | Low | Python SDK - Protobuf messages parsing |
| LOW-7 | Datapoint.from_message() does not check if no value is provided | Low | Python SDK - Protobuf messages parsing |
| LOW-8 | DataEntry.From_message() and ValueRestriction | Low | Python SDK - Protobuf messages parsing |
| LOW-9 | ValueRestriction without type field | Low | Python SDK - Protobuf messages parsing |
| LOW-10 | No check on timestamp uint value | Low | Python SDK - Protobuf messages parsing |
| INFO-1 | A vulnerability is known for the (atty) crate on Windows |
Info | Databroker dependencies |
| INFO-2 | Multiple databroker dependencies are out of date | Info | Databroker dependencies |
| INFO-3 | Subscription channels remain open after token expiration | Info | Databroker subscriptions |
| INFO-4 | UpdateDatapoints request format is not unified with other endpoints | Info | Databroker UpdateDatapoints endpoint |
| INFO-5 | (debug_assert) in (executor.rs) |
Info | Databroker subscriptions |
| INFO-6 | Slow input in (glob::to_regex()) |
Info | Databroker |
Conclusion
Quarkslab found several vulnerabilities in the KUKSA.val codebase using automated tools and manual investigations. In this specific audit, fuzzing allowed Quarkslab auditors to unveil one of the vulnerabilities with the highest severity. Some of these issues could be exploited in a real-world use case. Quarkslab provided leads and strategies on how to implement static and dynamic security analysis of the KUKSA.val databroker. Once implemented, these strategies enhanced the overall security level of the KUKSA project. Quarkslab had a successful collaboration with Eclipse Foundation, Eclipse Kuksa committers and OSTIF, and it was a real pleasure to work on this project.