Eclipse Kuksaのセキュリティ監査がリリースされました

しかしながら、これらのアプリケーションはデータブローカーのセキュアな実行に依存する必要があります。そこで、Quarkslabによる外部監査報告書の公開をお知らせできることを嬉しく思います。本監査はOSTIFおよびEclipse Foundationの仲介により実施され、Alpha-Omegaプロジェクトの資金提供によって実現しました。監査対象はKUKSAデータブローカーとその対応PythonクライアントSDKです。19件の発見事項があり、うち2件は深刻度が高いものでした。KUKSAチームは、報告書公開前にほとんどの指摘事項に対処しました。

本記事では、監査結果の一部とその対応策について説明します。監査報告書の全文はこちらからご覧いただけます。

プロバイダーは新しいシグナルを追加することでデータブローカーをクラッシュさせることができる

Kuksaの展開環境では、いわゆるプロバイダーが車載バス（例：CAN）から値を取得し、VSS信号に変換してデータブローカーに書き込むことでシグナルを更新する。Kuksa API「sdv.databroker.v1」を用いれば、プロバイダーはランタイムにデータブローカーが管理するデータモデルを拡張するため、新規シグナルを登録できる。しかし、プロバイダーが追加できるエントリ数に上限は設けられていませんでした。監査担当者が調査中に2,900万個のシグナルを登録したところ、32GBのRAMを搭載したコンピュータ上でオペレーティングシステムがデータブローカーを停止させました。VSS 4.0のデフォルトデータモデルは現在約1,000個のシグナルで構成されているため、このシナリオがいかに異常であるかが浮き彫りになりました。

ユーザーはサブスクリプションクエリでデータブローカーをクラッシュさせることができる

'sdv.databroker.v1' APIでは、ユーザーはシグナルの変更を購読できます。さらに、通知の受け取り条件を特定するフィルターを登録することも可能です。例えば、Vehicle.Speedが時速100キロを超える場合にのみメッセージを送信するクエリを定義できます。このAPIはSQLを用いてフィルタを表現するため、ユーザーが特定のクエリを作成することでデータブローカーをクラッシュさせる可能性があります。

ユーザーは起動時に明示的に「sdv.databroker.v1」を有効にする必要があります。そうしない場合、非アクティブのままとなります。Eclipse Velocitasなどの一部のアプリケーションは「sdv.databroker.v1」の機能に依存しているため、移行期間を延長するため、現時点では削除されていません。不足している機能のうち、『kuksa.val.v1』または将来のバージョンに含めるべきものについて、コミュニティからのフィードバックを収集します。『sdv.databroker.v1』に関係しないその他の発見事項については、提案された変更を実装しました。例えば、Python SDKにおけるいくつかの特殊ケースの処理などです。

本監査プロセスにおける協力と貴重なフィードバックを提供いただいたOSTIF、Eclipse Foundation、Quarkslabに感謝申し上げます。これらの結果と修正により、Python、Android、そして間もなくRust向けに提供予定のSDKを通じて、皆様のユースケースでデータブローカーをご利用いただけることを願っております。

今後のアップデートにご期待ください。Eclipse Kuksaの改善を続けてまいります！