Eclipse Kuksa 安全审计报告发布

然而，这些应用程序需要依赖数据代理的安全执行。因此，我们很高兴宣布由Quarkslab完成的外部审计报告现已发布。本次审计通过OSTI和Eclipse基金会协调推进，并由Alpha-Omega项目提供资金支持。审计重点针对KUKSA数据代理及其对应的Python客户端SDK，共发现19项问题，其中两项为高危问题。KUKSA团队在报告发布前已处理了大部分发现问题。

本文阐述了部分发现及其处理方式。您可在此处查阅完整的审计报告。

提供者可通过添加新信号导致数据代理崩溃

在Kuksa部署中，所谓的提供者通过从车辆总线（如CAN总线）获取值、将其转换为VSS信号，再写入数据代理来更新信号。借助Kuksa API 'sdv.databroker.v1'，提供者可在运行时注册新信号以扩展数据代理管理的数据模型。然而，提供者添加的条目数量此前并无上限。审计人员在测试中注册了2900万个信号，导致配备32GB内存的计算机上操作系统终止了数据代理运行。当前VSS 4.0的默认数据模型仅包含约1000个信号，这凸显了此类场景的异常性。

用户可通过订阅查询导致数据代理崩溃

在'sdv.databroker.v1' API中，用户可订阅信号的任何变更。此外，用户还能注册特定过滤器来控制通知接收条件。例如，可定义查询条件使数据代理仅在车辆速度超过100公里/小时（Vehicle.Speed）时发送消息。该API采用SQL表达此类过滤器，允许用户构造特定查询——正是这些查询导致数据代理崩溃。

用户现在需要在启动时明确启用'sdv.databroker.v1'；否则该组件将保持非活动状态。由于某些应用程序（如Eclipse Velocitas）依赖于'sdv.databroker.v1'的功能，为延长迁移周期，该组件尚未被移除。我们将收集社区反馈，确定哪些缺失功能应纳入'kuksa.val.v1'或后续版本。对于与'sdv.databroker.v1'无关的其他发现，我们已实施建议变更——例如处理Python SDK中的若干边界情况。

我们谨向 OSTIF、Eclipse 基金会和 Quarkslab 致谢，感谢他们在整个审计过程中通力合作并提供宝贵反馈。我们希望这些结果和修复措施能鼓励您在用例中使用数据代理，例如通过当前可用的Python、Android 及即将推出的 Rust 版本的 SDK 实现。

敬请期待更多更新，我们将持续优化Eclipse Kuksa！