adds blog entry for security audit #77

eriksven · 2024-05-21T08:11:37Z

No description provided.

bs-jokri

I added some suggestions for improvements. Decided yourself if you want to apply or not.

bs-jokri · 2024-05-21T08:17:34Z

content/blog/2024-05-21-Audit.md

+banner = "img/banners/2024-05-21-auditBanner.png"
+++
+
+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](https://www.quarkslab.com). The audit was facilitated through [OSTIF](https://ostif.org) and the [Eclipse Foundation](https://www.eclipse.org) and made possible by the founding the Eclipse Foundation received from the [Alpha-Omega project](https://openssf.org/community/alpha-omega/).


... of Kuksa's components

Are we not more happy about having successfully performed the audit at all? Maybe: ... happy to announce that we carried out an an external audit with Quarkslab, which is now published

founding -> funding

I would say that the audit was mostly carried by Quarkslab and not the Kuksa team. The Kuksa mostly helped during the scope setting by responding to questions.

bs-jokri · 2024-05-21T08:29:38Z

content/blog/2024-05-21-Audit.md

+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](https://www.quarkslab.com). The audit was facilitated through [OSTIF](https://ostif.org) and the [Eclipse Foundation](https://www.eclipse.org) and made possible by the founding the Eclipse Foundation received from the [Alpha-Omega project](https://openssf.org/community/alpha-omega/).
+
+- The audit was scoped on the KUKSA databroker and the respective Python client SDK.
+- There were 19 findings with low or higher severity, of which two had a high severity.


There were 19 findings, of which 17 had low and two had high severity.

There were 2 High, 1 Medium, 10 Low and 6 Info findings. For the summary I thought this already too much detail. I changed it to only mention the total number of the number high findings.

bs-jokri · 2024-05-21T08:29:51Z

content/blog/2024-05-21-Audit.md

+
+- The audit was scoped on the KUKSA databroker and the respective Python client SDK.
+- There were 19 findings with low or higher severity, of which two had a high severity.
+- The KUKSA team fixed most findings before the release of the report.


Which ones not? And why?

We did not fix two Info findings due to other priorities like slow handling of regex due to other priorities like reworking the API. For the level of these bullets points and even the whole blog entry I thought this would be too specific. It is still possible to read this in the full report.

bs-jokri · 2024-05-21T08:32:00Z

content/blog/2024-05-21-Audit.md

+
+## 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 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.


which threat model? as you write the threat model, it feels I would need to know which one it is but I assume there are more then one possible

The report says here:
"The threat model is the initial step of the audit. It provides an overview of the project’s work. More importantly, this step identifies the project’s purposes and critical functionalities."

I will write "derived threat model"

bs-jokri · 2024-05-21T08:35:58Z

content/blog/2024-05-21-Audit.md

+
+## Findings
+
+There were two findings for which the auditors assigned a high severity:


Maybe also give one sentence to the low findings. Maybe give some examples on what those findings were

My idea was to mention this below under "Further findings"

bs-jokri · 2024-05-21T08:36:42Z

content/blog/2024-05-21-Audit.md

+
+### 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, and then writing them to the databroker. With the Kuksa API '[sdv.databroker.v1](https://github.com/eclipse-kuksa/kuksa-databroker/tree/main/proto/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.


consider linking VSS with its spec and expanding the appreciation

Good point, my thinking was that a person that reads the Kuksa blog is aware of what VSS is. I will expand the abbreviation.

bs-jokri · 2024-05-21T08:47:15Z

content/blog/2024-05-21-Audit.md

+
+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](https://github.com/eclipse-kuksa/kuksa-databroker/tree/main/proto/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.


consider linking Eclipse Velocitas

bs-jokri · 2024-05-21T08:52:01Z

content/blog/2024-05-21-Audit.md

+
+## Deploy Kukas in your setup
+
+We want to thank OSTIF, the Eclipse Foundation, and Quarkslab for the great collaboration and the chance to go through this audit process. 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.


... and the valuable feedback we received during the audit process

bs-jokri · 2024-05-21T08:52:30Z

content/blog/2024-05-21-Audit.md

+
+## Deploy Kukas in your setup
+
+We want to thank OSTIF, the Eclipse Foundation, and Quarkslab for the great collaboration and the chance to go through this audit process. 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.


maybe link the sdks?

eriksven · 2024-05-21T09:52:57Z

I updated the commit, @bs-jokri could you please have another look? Thank you!

bs-jokri

lgtm

bs-jokri previously approved these changes May 21, 2024

View reviewed changes

adds blog entry for security audit

63aac77

eriksven dismissed bs-jokri’s stale review via 63aac77 May 21, 2024 09:52

eriksven force-pushed the audit-blog-entry branch from f4d75b0 to 63aac77 Compare May 21, 2024 09:52

bs-jokri approved these changes May 21, 2024

View reviewed changes

bs-jokri merged commit 471d667 into eclipse-kuksa:master May 21, 2024
2 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

adds blog entry for security audit #77

adds blog entry for security audit #77

eriksven commented May 21, 2024

bs-jokri left a comment

bs-jokri May 21, 2024

eriksven May 21, 2024

bs-jokri May 21, 2024

eriksven May 21, 2024

bs-jokri May 21, 2024

eriksven May 21, 2024 •

edited

Loading

bs-jokri May 21, 2024

eriksven May 21, 2024

bs-jokri May 21, 2024

eriksven May 21, 2024

bs-jokri May 21, 2024

eriksven May 21, 2024

bs-jokri May 21, 2024

bs-jokri May 21, 2024

bs-jokri May 21, 2024

eriksven commented May 21, 2024

bs-jokri left a comment


		## 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 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, and then writing them to the databroker. With the Kuksa API '[sdv.databroker.v1](https://github.com/eclipse-kuksa/kuksa-databroker/tree/main/proto/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.


		## Deploy Kukas in your setup

		We want to thank OSTIF, the Eclipse Foundation, and Quarkslab for the great collaboration and the chance to go through this audit process. 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.

adds blog entry for security audit #77

adds blog entry for security audit #77

Conversation

eriksven commented May 21, 2024

bs-jokri left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eriksven May 21, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eriksven commented May 21, 2024

bs-jokri left a comment

Choose a reason for hiding this comment

eriksven May 21, 2024 •

edited

Loading