Audit de sécurité pour Eclipse Kuksa publié

Cependant, ces applications doivent s'appuyer sur l'exécution sécurisée du courtier de données. Nous sommes donc heureux d'annoncer la publication d'un rapport d'audit externe réalisé par Quarkslab. L'audit a été facilité par l'OSTIF et la Fondation Eclipse et rendu possible grâce au financement du projet Alpha-Omega. L'audit s'est concentré sur le courtier de données KUKSA et son SDK client Python respectif. Il a donné lieu à 19 conclusions, dont deux présentaient un niveau de gravité élevé. L'équipe KUKSA a corrigé la plupart des problèmes avant la publication du rapport.

Dans cet article, nous expliquons certaines des conclusions et la manière dont elles ont été traitées. Vous pouvez consulter le rapport d'audit complet ici.

Le fournisseur peut provoquer le plantage du courtier de données en ajoutant de nouveaux signaux.

Dans un déploiement Kuksa, les fournisseurs mettent à jour les signaux en récupérant les valeurs du bus du véhicule (par exemple, CAN), en les convertissant en signaux VSS, puis en les écrivant dans le courtier de données. Grâce à l'API Kuksa « sdv.databroker.v1 », un fournisseur peut enregistrer de nouveaux signaux afin d'étendre le modèle de données géré par le courtier de données pendant l'exécution. Cependant, il n'y avait pas de limite supérieure au nombre d'entrées qu'un fournisseur pouvait ajouter. Au cours de leur enquête, les auditeurs ont enregistré 29 millions de signaux, ce qui a provoqué l'arrêt du courtier de données par le système d'exploitation sur un ordinateur doté de 32 Go de RAM. Le modèle de données par défaut de VSS 4.0 comprend actuellement environ 1 000 signaux, ce qui souligne le caractère inhabituel de ce scénario.

L'utilisateur peut bloquer le courtier de données avec une requête d'abonnement.

Dans l'API « sdv.databroker.v1 », les utilisateurs peuvent s'abonner à toute modification d'un signal. De plus, ils peuvent enregistrer des filtres spécifiques pour déterminer quand ils souhaitent être avertis ou non. Par exemple, il est possible de définir une requête dans laquelle le courtier de données n'envoie un message que lorsque la vitesse du véhicule (Vehicle.Speed) est supérieure à 100 kilomètres par heure. L'API utilise SQL pour exprimer ces filtres, ce qui permet aux utilisateurs de créer des requêtes spécifiques qui provoquent le plantage du courtier de données.

Les utilisateurs doivent désormais activer explicitement « sdv.databroker.v1 » au démarrage, sinon il reste inactif. Certaines applications telles qu'Eclipse Velocitas dépendent des fonctionnalités de « sdv.databroker.v1 », qui n'a donc pas encore été supprimé afin de permettre une période de migration prolongée. Nous recueillerons les commentaires de la communauté sur les fonctionnalités manquantes qui devraient être intégrées à « kuksa.val.v1 » ou aux versions futures. Pour les autres conclusions sans rapport avec « sdv.databroker.v1 », nous avons mis en œuvre les modifications proposées, par exemple la gestion de plusieurs cas particuliers dans le SDK Python.

Nous tenons à remercier OSTIF, Eclipse Foundation et Quarkslab pour leur collaboration tout au long de ce processus d'audit et pour leurs précieux commentaires. Nous espérons que ces résultats et corrections vous encourageront à utiliser le courtier de données dans vos cas d'utilisation, par exemple via l'un des SDK actuellement disponibles pour Python, Android et bientôt Rust.

Restez à l'écoute pour plus d'informations alors que nous continuons à améliorer Eclipse Kuksa !