Sicherheitsaudit für Eclipse Kuksa veröffentlicht

Diese Anwendungen müssen sich jedoch auf die sichere Ausführung des Datenbrokers verlassen können. Wir freuen uns daher, die Veröffentlichung eines externen Auditberichts bekannt zu geben, der von Quarkslab durchgeführt wurde. Das Audit wurde durch OSTIF und die Eclipse Foundation ermöglicht und durch die Finanzierung des Alpha-Omega-Projekts realisiert. Das Audit konzentrierte sich auf den KUKSA-Datenbroker und das zugehörige Python-Client-SDK. Es gab 19 Ergebnisse, von denen zwei einen hohen Schweregrad aufwiesen. Das KUKSA-Team hat die meisten Ergebnisse vor der Veröffentlichung des Berichts behoben.

In diesem Beitrag erläutern wir einige der Ergebnisse und wie diese behandelt wurden. Den vollständigen Prüfungsbericht finden Sie hier.

Der Anbieter kann den Datenbroker zum Absturz bringen, indem er neue Signale hinzufügt.

Bei einem Kuksa-Einsatz aktualisieren sogenannte Provider Signale, indem sie Werte aus dem Fahrzeugbus (zum Beispiel CAN) abrufen, diese in VSS-Signale umwandeln und dann in den Datenbroker schreiben. Mit der Kuksa-API „sdv.databroker.v1” kann ein Provider neue Signale registrieren, um das vom Datenbroker verwaltete Datenmodell während der Laufzeit zu erweitern. Allerdings gab es keine Obergrenze für die Anzahl der Einträge, die ein Anbieter hinzufügen konnte. Während ihrer Untersuchung registrierten die Prüfer 29 Millionen Signale, was dazu führte, dass das Betriebssystem den Datenbroker auf einem Computer mit 32 GB RAM stoppte. Das Standarddatenmodell von VSS 4.0 besteht derzeit aus etwa 1000 Signalen, was zeigt, wie ungewöhnlich dieses Szenario ist.

Nutzende oder Nutzerinnen und Nutzer können Datenbroker mit Abonnementabfrage zum Absturz bringen

In der API „sdv.databroker.v1” können Nutzende oder Nutzerinnen und Nutzer alle Änderungen an einem Signal abonnieren. Darüber hinaus können Nutzende oder Nutzer bestimmte Filter registrieren, um festzulegen, wann sie benachrichtigt werden möchten und wann nicht. So könnte man beispielsweise eine Abfrage definieren, bei der der Datenbroker nur dann eine Nachricht sendet, wenn die Fahrzeuggeschwindigkeit über 100 Kilometer pro Stunde liegt. Die API verwendet SQL, um solche Filter auszudrücken, sodass Nutzende oder Nutzerinnen und Nutzer spezifische Abfragen erstellen können, die zum Absturz des Datenbrokers führen.

Nutzende oder Nutzerinnen und Nutzer müssen nun „sdv.databroker.v1” beim Start explizit aktivieren, da es sonst inaktiv bleibt. Einige Anwendungen wie Eclipse Velocitas sind auf Funktionen von „sdv.databroker.v1” angewiesen, sodass es noch nicht entfernt wurde, um eine längere Migrationsphase zu ermöglichen. Wir werden Feedback aus der Community sammeln, welche fehlenden Funktionen Teil von „kuksa.val.v1” oder zukünftigen Versionen sein sollten. Für andere Erkenntnisse, die nicht mit „sdv.databroker.v1” zusammenhängen, haben wir vorgeschlagene Änderungen implementiert, beispielsweise die Behandlung mehrerer Sonderfälle im Python SDK.

Wir möchten OSTIF, der Eclipse Foundation und Quarkslab für ihre Zusammenarbeit während dieses Auditprozesses und für ihr wertvolles Feedback danken. Wir hoffen, dass diese Ergebnisse und Korrekturen Sie dazu ermutigen, den Databroker in Ihren Anwendungsfällen zu verwenden, zum Beispiel über eines der derzeit verfügbaren SDKs für Python, Android und bald auch Rust.

Bleiben Sie dran für weitere Updates, während wir Eclipse Kuksa weiter verbessern!