Question:
Un lecteur de CD sur une voiture sans conducteur poserait-il un risque pour la sécurité?
Jake Wickham
2016-10-11 17:18:39 UTC
view on stackexchange narkive permalink

Les hackers sont intelligents. Pourraient-ils pirater une voiture autonome grâce à son lecteur de CD? D'après ce que j'ai compris, un code malveillant pourrait être téléchargé sur la voiture sans conducteur via un CD, ce qui pourrait leur donner accès aux freins, aux essuie-glaces, aux capteurs, etc. (qui pourraient tous être utilisés pour commettre un meurtre ou détenir la rançon de la voiture).

Tout système pourrait théoriquement être piraté à partir de n'importe quel moyen d'entrée.Mais cela ne signifie pas que le système ne pourrait pas être mis en œuvre de manière raisonnablement sûre.
Ou, vous savez, construisez simplement le système de manière à ce que le lecteur CD soit complètement séparé de tout élément critique?
La plupart des systèmes que j'ai vus ont un accès direct via la fente pour carte SD, généralement pour mettre à jour les cartes.Je serais plus concerné par cela qu'un CD.Dans la plupart des systèmes de l'environnement actuel, le lecteur de CD ignorera tout ce qui n'est ni .WAV (Raw) ni un format codé qu'il comprend.Cela ne veut pas dire qu'il ne peut pas être utilisé comme DOS, j'avais un lecteur CD dans une ancienne Mazda sur laquelle nous avions créé un disque avec quelques centaines de milliers de noms de fichiers et il serait tellement suspendu qu'il ne vous laisserait même pas éjecter ledisque.J'ai dû retirer le lecteur et utiliser la méthode manuelle de la broche d'éjection.
Une attaque via un lecteur CD nécessite un accès physique.Je suppose que le dicton sur l'accès physique aux ordinateurs peut être étendu aux voitures (sans conducteur ou non)
Quel est votre modèle de menace?Vous ne pouvez pas évaluer les risques de sécurité sans modèle de menace.À votre dernière phrase sur le fait de ne pas être convaincu qu'ils sont en sécurité, considérez qu'il est tout à fait possible que vous sortiez demain matin et que vous soyez renversé par un camion à ordures non autorisé.Cela signifie-t-il que vous ne quittez jamais votre maison?De plus, un individu sans scrupules pourrait couper vos conduites de frein, avec ou sans lecteur CD dans la voiture.
@CortAmmon Mais, avec un lecteur CD dans la voiture, il pouvait écouter sa musique préférée tout en coupant les conduites de frein.Ce serait plus agréable, donc il serait plus susceptible de le faire.Par conséquent, les lecteurs de CD représentent un risque pour la sécurité.
Pourquoi mettriez-vous un lecteur CD dans une voiture sans conducteur?Il n'y aurait personne pour l'écouter.
@emory Les passagers peuvent l'écouter.
Cette question n'est-elle pas en retard d'environ 5 ans?CD, vraiment?
Je serais plus inquiet des menaces sans accès, telles que le hotspot wifi dans la voiture ou le système Bluetooth.
«Les hackers sont intelligents» est-il la base de votre préoccupation?Une route d'attaque vérifiée ne serait-elle pas une meilleure raison de poser une question?
Voir [Protection de l'espace exécutable - Wikipedia] (https://en.wikipedia.org/wiki/Executable_space_protection).Cette description n'est pas totalement exacte mais le concept général s'applique.Les processeurs et les systèmes d'exploitation modernes ne permettent pas aux applications de niveau utilisateur d'exécuter des données qui ne sont pas désignées comme exécutables.Les voitures ne sont pas spéciales;les concepts sont les mêmes.Des choses comme Google Play sont essentielles car elles diffusent des données qui sont ensuite exécutées.
Comment savez-vous que le lecteur CD n'est pas un ordinateur complètement séparé avec sa propre alimentation?Si vous pouvez pirater avec ce système particulier ... alors vous pouvez soit sauter à travers les appareils (ce qui serait incroyable en soi) ou vous pouvez en quelque sorte pirater le pouvoir (également incroyable)
@VirtualAnomaly À l'époque où les lecteurs de CD étaient encore standard, ils * devaient * être intégrés dans tout car les mises à jour du système ou de la navigation devaient être effectuées via CD.Découpler le système n'était pas une option à l'époque et ce ne sera probablement pas maintenant, car les gens voudront vraisemblablement pouvoir le contrôler à partir du système embarqué de leur voiture.
Six réponses:
paj28
2016-10-11 18:42:25 UTC
view on stackexchange narkive permalink

Pas sur une voiture bien conçue

Le lecteur CD fait partie du système multimédia. Il est probable que le système multimédia présente un certain nombre de vulnérabilités de sécurité, et un CD malveillant peut probablement prendre le contrôle du système multimédia. Il serait difficile de résoudre ce problème sans augmenter considérablement le coût ou restreindre la fonctionnalité de celui-ci.

Les systèmes de contrôle de la voiture - le bus CAN - devraient être fortement séparés des systèmes multimédias. Lors d'attaques précédentes, telles que le piratage Jeep, les attaquants ont pu passer du système multimédia au bus CAN. Cependant, cela représente une conception et une mise en œuvre médiocres. Les deux systèmes doivent être séparés - ou du moins, avoir une interface très restreinte - et il est possible de le faire à un coût raisonnable.

Reste à savoir si les futures voitures sans conducteur seront bien conçues.

* "Reste à savoir si les futures voitures sans conducteur seront bien conçues." *
Vous devriez modifier votre réponse comme suit: "Oui, mais cela ne devrait pas être le cas sur une voiture bien conçue".À maintes reprises, nous voyons ce genre de piratage se produire.Je ne suis pas familier avec ces systèmes, mais étant donné les tendances actuelles, je doute qu'ils utilisent un «intervalle d'air» entre les systèmes.
@David - C'était un peu mon argument dans le dernier paragraphe.À propos, vous ne voulez probablement pas un entrefer complet, il y a plusieurs raisons de s'interconnecter, comme les capteurs de stationnement qui sonnent à travers les haut-parleurs stéréo.Mais l'interface doit être fortement restreinte.
Bien que je pense que c'est une vraie réponse, c'est un peu une tautologie.Si je peux paraphraser, "le lecteur CD est sûr tant que la voiture est conçue de telle sorte que le lecteur CD est sûr".Toutes les voitures qui sont connectées d'une manière qui permet à un pirate de prendre le relais sont automatiquement marquées comme "pas bien conçues", donc c'est un peu de la triche.
@CortAmmon - Touché!En toute honnêteté, j'explique comment le rendre sûr, alors j'espère que ma réponse sera utile à quelqu'un.
Dans le hack Chrysler, les deux systèmes _did_ ont une interface très restreinte.Mais pas assez restreint.Voir [cette présentation de DEF CON 23] (https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20video%20and%20slides/DEF%20CON%2023%20Conference%20-%20Charlie% 20Miller% 20-% 20Remote% 20exploitation% 20of% 20an% 20unaltered% 20passenger% 20vehicle% 20-% 20Video% 20and% 20Slides.mp4).
@MichaelHampton: Le type approprié de restriction sur l'interface serait le flux de données dans une seule direction (au niveau physique non seulement logique, c'est-à-dire pas d'envoi de demandes de lecture ou de contrôle de flux).Bien qu'il y ait beaucoup d'espionnage qui pourrait être activé en envoyant des informations sur la voiture au centre multimédia, cela ne permettra jamais de prendre le contrôle de la voiture.
@BenVoigt - Les mises à jour en direct sont l'une des raisons du flux de données du support au contrôle de la voiture.Je sais que cela a été ciblé dans les hacks précédents.Mais il est possible de bien faire des mises à jour signées, et les avantages des mises à jour en direct sont considérables.De plus, une voiture sans conducteur aurait besoin d'informations d'itinéraire pour passer du centre multimédia au pilote automatique.
Même s'il est complètement isolé dans le logiciel, vous devez également obtenir le bon matériel, sinon il sera également exploité.Par exemple.en pulsant des fils liés aux médias à proximité pour induire un signal indésirable dans votre bus CAN ou autre
Ma voiture est équipée de deux lecteurs de CD - l'un pour les CD audio et l'autre pour les cartes de navigation.
@el.pescado Est-ce la configuration d'usine?Je me demande pourquoi ils n'ajoutent pas simplement un commutateur physique pour basculer le connecteur entre le système audio et le système de navigation.
Oui, c'est la configuration d'usine (c'est une Opel Vectra 2007).Je pense que la raison est de permettre d'utiliser la navigation tout en écoutant de la musique - donc convivialité plutôt que sécurité.
J.A.K.
2016-10-11 17:23:59 UTC
view on stackexchange narkive permalink

Oui.

Des chercheurs de l'UC San Diego ont en fait mis en œuvre une attaque via ce vecteur:

«Nous avons trouvé une faille dans un lecteur CD de notre voiture ," il a dit. "Vous pouvez choisir une chanson et la coder de telle sorte que si vous la jouez sur votre PC, elle jouera correctement, mais si vous la jouez dans votre voiture, elle la prendra en charge."

http://www.sandiegouniontribune.com/news/education/sdut-ucsd-professor-cyber-hacking-2015aug28-story.html

Il s'agit probablement par une vulnérabilité de corruption de mémoire dans les balises méta-informations du fichier audio. Grâce à cela, ils ont probablement pu diriger les commandes vers le système CAN qui régule la voiture.

Mais vous n'avez même pas besoin d'un CD; dans le pire des cas, cela peut se produire à distance via les réseaux mobiles

Supposons que ce serait un inconvénient pour l'attaquant pour dire le moins ... Je suppose que nous sommes en sécurité * applaudissements *
Sauf pour la partie sur le piratage à distance via les réseaux mobiles; (
"Serait" est un trop fort.«Pourrait» serait plus correct.Il n'y a aucune garantie qu'un lecteur de CD aurait des vulnérabilités ou serait connecté à d'autres sous-systèmes, il est donc incorrect de dire qu'il poserait définitivement un risque de sécurité.
La distribution des médias sur un service de partage de fichiers en ligne permettrait également d'accomplir cela lors d'une attaque non ciblée.
Cela me dérange que les rédacteurs du compilateur C ne reconnaissent pas comme une exigence courante la notion selon laquelle les programmes qui reçoivent des données d'entrée invalides soient autorisés à produire des données de sortie arbitraires, mais le format de sortie et les autres comportements doivent rester définis.Si les programmeurs ne se soucient pas des pixels ou des échantillons audio générés à partir d'un fichier non valide, sous réserve des contraintes ci-dessus, exiger que les programmeurs gèrent rigoureusement tous les cas de coin créera non seulement des failles de sécurité chaque fois que les programmeurs échouent à le faire, mais cela nuira aux performancesquand ils le font (vs laisser les compilateurs avoir plus de liberté).
@supercat - Découvrez [Rust] (https://www.rust-lang.org/en-US/)
@paj28: Existe-t-il encore un support de cross-compilateur ARM?La dernière fois que j'ai vérifié, D et Rust semblaient être des langages intéressants, mais ni l'un ni l'autre ne me sont utiles sans le support de la compilation croisée ARM.
@supercat - Je ne connais pas la compilation croisée, mais ARM [est pris en charge] (https://github.com/warricksothr/RustBuild).Je suppose que vous pouvez étendre au moins un Raspberry Pi pour faire votre compilation?
@paj28: Cool.La page que vous avez liée plus tôt à première vue semblait simplement avoir des téléchargements liés au PC disponibles;Je vais devoir voir si Rust semble faisable pour ARM.
@paj28 "threads sans courses de données"?Donc Rust interdit les variables partagées?
@JAB - Je ne connais pas les détails, mais [ce blog] (http://manishearth.github.io/blog/2015/05/30/how-rust-achieves-thread-safety/) semble intéressant
@paj28 D'accord, donc Rust ne vous empêche pas d'introduire des conditions de course si vous essayez vraiment, il fournit simplement de meilleurs outils pour les éviter.
@supercat: Un compilateur C ne pourrait pas assumer la charge de maintenir "le format de sortie et d'autres comportements" pour les programmes bogués.Même déterminer quel est le format de sortie correct nécessiterait que le compilateur lise l'esprit du programmeur.Même des langues beaucoup plus sûres comme Rust ou Haskell ne peuvent pas offrir ce genre de garantie.
@supercat Le compilateur pourrait bien compiler une fonction afin qu'elle produise des données de sortie invalides étant donné des données d'entrée invalides, sans autres effets secondaires négatifs.Mais alors la sortie de cette fonction est utilisée comme index dans une table de pointeurs de fonction, ce qui provoque l'appel de la fonction `send_command_to_engine` au lieu de la fonction` play_music`, par exemple.
@immibis: Dans de nombreux types de programmation, il est nécessaire de garder une trace des données qui ont été nettoyées et de celles qui ne l'ont pas été.Les compilateurs avaient traditionnellement permis à de nombreuses opérations d'être effectuées en toute sécurité sur des données non désinfectées sans les nettoyer au préalable, à condition que les résultats de ces opérations soient traités comme non désinfectés.Ce qui tue, c'est que les compilateurs observent que puisqu'une partie du code a calculé x << y (dans un scénario où la sortie serait considérée comme non assainie), le compilateur peut ailleurs prendre `if (y <40) fonctions [y] (peu importe); `et omettez la vérification de la plage car y" ne peut pas "être supérieur à 32.
@user2357112: Les exigences pour de nombreux programmes du monde réel incluent certaines parties qui doivent être satisfaites pour toutes les entrées, et certaines qui ne doivent l'être que pour des entrées valides.Si une fonction est censée évaluer `int32a * int32b
... le calcul soit en calculant un produit 32 bits et en l'étendant par signe, en calculant un produit 64 bits et en l'utilisant directement, ou en faisant tout ce qui fonctionnera dans les cas où le résultat s'inscrit dans un int 32 bits"et donnera un 0 ou 1 dans tous les autres cas?Mon point est que les programmeurs devraient être autorisés à utiliser des vérifications de limites dans les cas où ils devraient affecter les actions du programme et les omettre dans les cas où ils ne devraient pas avoir besoin de le faire, sans que les compilateurs traitent l'omission des vérifications de limites dans certains cas comme une invitation à les omettrede tous les cas.
pjc50
2016-10-12 01:59:48 UTC
view on stackexchange narkive permalink

Peu importe le lecteur de CD, vos pneus conspirent contre vous

"Vulnérabilités en matière de sécurité et de confidentialité des réseaux sans fil embarqués: étude de cas du système de surveillance de la pression des pneus"

Nous avons également découvert que les implémentations actuelles ne semblent pas suivre les pratiques de sécurité de base. Les messages ne sont pas authentifiés et l'ECU du véhicule ne semble pas non plus utiliser la validation d'entrée. Nous avons pu injecter des messages falsifiés et allumer les voyants d'avertissement de basse pression des pneus sur une voiture roulant à des vitesses d'autoroute à partir d'une autre voiture à proximité, et avons réussi à désactiver l'ECU TPMS en tirant parti de l'usurpation de paquets pour allumer et éteindre à plusieurs reprises les voyants d'avertissement.

MSalters
2016-10-12 01:21:36 UTC
view on stackexchange narkive permalink

Parlant d'expérience personnelle ici, pas une chance de boules de neige en enfer.

Je faisais partie d'une équipe qui a écrit une toute nouvelle pile d'appareils pour un système d'infodivertissement automobile en 2008. Il y a assez longtemps, mais même dans ce cas, nous avons compris le besoin critique de protéger notre pile logicielle.

Notre problème a été aggravé parce que le système fonctionnait (et fonctionnait) sous Linux. Et nous nous sommes entièrement conformés aux termes de la GPL 2, ce qui signifie que vous pouviez insérer un code auto-développé et que la voiture accepterait cela.

Cependant, ce n’était pas spécifiquement un risque de sécurité car la voiture utilisait un système de signature numérique. Votre propre code fonctionnerait, mais la voiture refusait simplement de parler à votre logiciel. Et il n'a pas écouté de toute façon - le système d'infodivertissement avait au mieux un accès en lecture seule à un petit ensemble d'éléments de données énumérés tels que la vitesse de la voiture.

Je sais que notre système était à la pointe de l'ingénierie automobile à l'époque, et le piratage Jeep déjà mentionné s'est produit plus tard. Ce n'est pas vraiment surprenant. Il y a pas mal d'héritage en cours, les refontes propres ne sont pas si courantes. Jeep est bien sûr une marque mineure d'une entreprise en difficulté, il n'est donc pas surprenant qu'ils soient à la traîne. Mais ce ne serait pas une marque dont on s'attendrait à ce qu'elle produise d'abord une voiture sans conducteur - les principaux suspects seraient des entreprises plus saines (pourrait être Mercedes, pourrait être Toyota, et bien sûr Tesla)

Re: "pas une chance de boules de neige en enfer".L'OP n'a pas posé de question sur "Votre système CD", je pense qu'ils signifiaient n'importe quel système.Vous semblez alors réfuter votre commentaire en énumérant les cas qui ont eu des problèmes et les rejeter comme s'il n'y avait pas ce genre d'entreprises dans l'industrie automobile sans conducteur.De plus, même si un système peut être sécurisé, il ne l'est que contre les éléments contre lesquels les développeurs ont pu penser à se protéger.J'espère que votre processeur n'a pas été construit en Chine, sinon qui sait quelles portes dérobées attendent d'être utilisées.
Votre modèle de sécurité était-il destiné à relier les systèmes de contrôle de la voiture et d'infodivertissement et à renforcer le système d'infodivertissement?On dirait que vous avez pris la sécurité au sérieux, mais je pense toujours que c'est une conception risquée.La surface d'attaque du périmètre est massive et comprend probablement des éléments tels que les décodeurs MP3 qui doivent être de haute performance.
Je suis d'accord avec @paj28 - "pas une chance de boules de neige en enfer" est une affirmation assez difficile.Les signatures numériques dépendent des implémentations de cryptographie, et les algorithmes de cryptographie eux-mêmes se révèlent faibles et exploitables avec le temps, sans compter que leurs implémentations comportent souvent également des bogues.Ensuite, il y a toutes les attaques de canaux secondaires (comme le timing), etc. L'accès en lecture seule peut également être exploité pour écrire via des bogues (par exemple, dans les contrôles d'accès eux-mêmes - comme les noyaux, les hyperviseurs) ou dans le matériel lui-même (vous vous souvenez de rowhammer?).
@Dunk: Étant donné que nous avions besoin du processeur pour démarrer uniquement les noyaux signés, et qu'il s'agit d'un produit automobile, vous pouvez supposer que ce n'est pas un bit chinois aléatoire.Oui, il y a un module de sécurité "caché du système d'exploitation" - c'est la raison pour laquelle nous pouvons appliquer la signature numérique.
@paj28: Le modèle n'était pas de "durcir" le système d'infodivertissement.Le modèle devait le considérer comme compromis par défaut - qui sait quel type de code non signé il pourrait exécuter?Jusqu'aux pilotes, toute la source du noyau était disponible.Cela réduit considérablement la surface d'attaque.
@MatijaNalis: En fait, le code n'est même pas en cours d'exécution lorsque les signatures sont vérifiées, et l'ensemble du processus de vérification des signatures est inobservable (profondément intégré).Ce n'est pas une sécurité en soi, mais toute personne disposant du niveau d'accès physique requis pourrait simplement remplacer ou ajouter du matériel supplémentaire.
Le gouvernement américain @MSalters-The n'autorise même pas la fabrication de certains types de produits hautement critiques dont les pièces ont été fabriquées en Chine en raison de cette préoccupation.La signature numérique ne peut aider à détecter que le fabricant a ajouté des transistors supplémentaires dans le silicium qui pourraient être utilisés pour déclencher des mécanismes pouvant être utilisés pour exploiter le système.
@Dunk: La bonne chose est que lorsque vous achetez un million de puces par an pour une application à faible risque, le fournisseur a une bonne raison de ne pas vous foutre en l'air.Le problème du gouvernement américain est qu'il achète 1000 puces pour des applications à haut risque.
0x1gene
2016-10-12 20:33:08 UTC
view on stackexchange narkive permalink

La sécurité sur les voitures autonomes devient un sujet tendance, car les voitures reçoivent de plus en plus de logiciels.

Plus il y a de code et de matériel, plus le système est exposé car la surface d'attaque est plus grande. Cela dit, je ne m'inquiéterais pas trop du lecteur de CD. La voiture autonome la plus récente sera connectée à Internet pour obtenir diverses données (météo, trafic, diffusion de musique, calendrier de synchronisation, etc.). Si une voiture devait être ciblée, le cd ne serait pas un choix judicieux, et comme vous l'avez dit, les hackers sont intelligents, donc ils cibleront probablement des portes plus modernes et ouvriront vers le monde extérieur.

Cela dit, allons prétendez qu'il y a un flux dans votre lecteur de CD: le pirate devrait vous faire télécharger une chanson, vous la graver sur un CD et espérer que vous la jouerez sur votre voiture autonome - Donc, si vous ne téléchargez pas douteux fichiers c'est fondamentalement impossible pour eux et ne vaut certainement pas l'effort ...

Une dernière chose à ajouter est que la chanson elle-même pourrait donner des commandes vocales à la voiture si elle est compatible ( comme quoi ils l'ont fait pour les téléphones). Encore une fois, vous devrez obtenir la chanson d'une source douteuse et cela ne permet pas de faire quelque chose qui n'est pas conçu pour fonctionner avec l'interface vocale. Il est donc peu probable qu’une chanson dise à votre voiture de se briser ...

Du point de vue du développeur, je pense que les voitures autonomes ne seront pas à 100% à l'épreuve des balles, mais elles le seront (et sont déjà) beaucoup plus sûres que les voitures à commande humaine. C'est simplement parce qu'un ordinateur a un temps de réponse plus court, il n'est jamais ivre, somnolent ou distrait, il a beaucoup plus de sens. vous comptez sur un champ de vision optique 200-220 °, l'ordinateur peut s'appuyer sur un système de caméra 360 couplé à des radars longue portée, capteur de proximité etc ...

Soyons honnêtes, quand on lance une fusée , il est géré par un ordinateur, pas par un humain, il y a une raison à cela.

J'espère que cela vous a aidé à mieux comprendre les risques et à avoir moins peur de la conduite autonome.

J'aurais assez peur d'une voiture sans conducteur contrôlée par un ordinateur avec un temps de réponse ** plus lent **.Vous voulez dire plus rapide ou plus court.
@AnthonyGrist ahah vrai ça!Je voulais dire plus court merci :)
Lorsque nous pilotons un avion, il est géré par un ordinateur, pour une raison.Lorsque nous atterrissons un avion, ce n'est pas le cas.
@WilliamKappler Boeing et Airbus ont piloté des avions d'atterrissage d'ordinateurs (jeu de mots);ainsi qu'un vol informatisé complet.Le vol ou la navigation de plaisance peuvent être plus simples que le transport terrestre pour un ordinateur.
MikeP
2016-10-13 00:57:21 UTC
view on stackexchange narkive permalink

S'il est connecté aux systèmes qui font fonctionner la voiture, alors tout est possible.
S'il n'est pas connecté, par exemple c'est un Discman, alors non.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...