Domanda:
Un'unità CD su un'auto senza conducente rappresenterebbe un rischio per la sicurezza?
Jake Wickham
2016-10-11 17:18:39 UTC
view on stackexchange narkive permalink

Gli hacker sono intelligenti. Potrebbero hackerare un'auto a guida autonoma attraverso il suo lettore CD? Da quello che ho capito, un codice dannoso potrebbe essere caricato sull'auto senza conducente tramite CD che potrebbe dare loro accesso a freni, tergicristalli, sensori, ecc. (Che potrebbero essere utilizzati per commettere potenzialmente un omicidio o trattenere il riscatto dell'auto).

Qualsiasi sistema potrebbe teoricamente essere violato da qualsiasi mezzo di input.Ma ciò non significa che il sistema non possa essere implementato in modo ragionevolmente sicuro.
O, sai, costruisci il sistema in un modo in cui il lettore CD sia completamente separato da qualsiasi cosa critica?
La maggior parte dei sistemi che ho visto hanno accesso diretto tramite lo slot per schede SD di solito per aggiornare le mappe.Sarei più interessato a quello che a un CD.Nella maggior parte dei sistemi nell'ambiente di oggi, il lettore CD salterà tutto ciò che non è .WAV (Raw) o un formato codificato che comprende.Non significa che non possa essere usato come DOS, avevo un lettore CD in una vecchia Mazda che avevamo creato un disco con un paio di centinaia di migliaia di nomi di file e si bloccava così tanto che non ti lasciava nemmeno espellere ildisco.Ho dovuto estrarre l'unità e utilizzare il metodo del perno di espulsione manuale.
Un attacco tramite lettore CD richiede l'accesso fisico.Suppongo che il detto sull'accesso fisico ai computer possa essere esteso alle auto (senza conducente o meno)
Qual è il tuo modello di minaccia?Non è possibile valutare i rischi per la sicurezza senza un modello di minaccia.Alla tua ultima frase sul non essere convinto che siano al sicuro, considera che è del tutto possibile che uscirai dalla porta domani mattina e verrai investito da un camion della spazzatura canaglia.Significa che non esci mai di casa?Inoltre, una persona senza scrupoli potrebbe tagliare le linee dei freni, con o senza un lettore CD in macchina.
@CortAmmon Ma, con un lettore CD in macchina, poteva ascoltare la sua musica preferita mentre tagliava le linee dei freni.Sarebbe più divertente, quindi sarebbe più probabile che lo facesse.Pertanto, i lettori CD rappresentano un rischio per la sicurezza.
Perché dovresti mettere un lettore CD in un'auto senza conducente?Non ci sarebbe nessuno ad ascoltarlo.
@emory I passeggeri possono ascoltarlo.
Questa domanda non è in ritardo di 5 anni?CD, davvero?
Sarei più preoccupato per le minacce senza accesso, come l'hotspot wifi in macchina o il sistema bluetooth.
"Gli hacker sono intelligenti" è l'intera base della tua preoccupazione?Una via di attacco verificata non sarebbe una ragione migliore per una domanda?
Vedere [Protezione dello spazio eseguibile - Wikipedia] (https://en.wikipedia.org/wiki/Executable_space_protection).Questa descrizione non è del tutto accurata ma si applica il concetto generale.I moderni processori e sistemi operativi non consentono alle applicazioni a livello di utente di eseguire dati che non sono designati come eseguibili.Le auto non sono speciali;i concetti sono gli stessi.Cose come Google Play sono fondamentali poiché servono dati che vengono successivamente eseguiti.
Come fai a sapere che l'unità CD non è un computer completamente separato con il proprio potere?Se puoi hackerare con quel particolare sistema ... allora puoi saltare da un dispositivo all'altro (il che sarebbe fantastico di per sé) o puoi in qualche modo hackerare attraverso il potere (anche incredibile)
@VirtualAnomaly Ai tempi in cui i lettori CD erano ancora standard, * dovevano * essere integrati in tutto poiché gli aggiornamenti di sistema o di navigazione dovevano essere eseguiti tramite CD.Il disaccoppiamento del sistema non era un'opzione allora e probabilmente non lo sarà ora poiché le persone presumibilmente vorranno essere in grado di controllarlo dal sistema di bordo della loro auto.
Sei risposte:
paj28
2016-10-11 18:42:25 UTC
view on stackexchange narkive permalink

Non su un'auto ben progettata

Il lettore CD fa parte del sistema multimediale. È probabile che il sistema multimediale abbia una serie di vulnerabilità di sicurezza e un CD dannoso può probabilmente assumere il controllo del sistema multimediale. Sarebbe difficile risolvere questo problema senza aumentare notevolmente il costo o limitare la funzionalità di questo.

I sistemi di controllo dell'auto - il bus CAN - dovrebbero essere fortemente separati dai sistemi multimediali. Negli attacchi precedenti, come l ' Jeep hacking, gli aggressori sono riusciti a passare dal sistema multimediale al CAN bus. Tuttavia, questo rappresenta una cattiva progettazione e implementazione. I due sistemi dovrebbero essere tenuti separati - o almeno avere un'interfaccia altamente limitata - ed è possibile farlo a un costo ragionevole.

Resta da vedere se le future auto senza conducente saranno ben progettate.

* "Resta da vedere se le future auto senza conducente saranno ben progettate." *
Dovresti modificare la tua risposta in: "Sì, ma non dovrebbe su un'auto ben progettata".Di volta in volta vediamo questo tipo di hacking.Non ho familiarità con questi sistemi, ma date le tendenze attuali dubito che stiano utilizzando un "traferro" tra i sistemi.
@David - Questo è stato il mio punto nel paragrafo finale.A proposito, probabilmente non vuoi un traferro completo, ci sono alcuni motivi per interconnetterti, come i sensori di parcheggio che suonano attraverso gli altoparlanti stereo.Ma l'interfaccia dovrebbe essere fortemente limitata.
Anche se penso che questa sia una risposta vera, è un po 'una tautologia.Se posso parafrasare, "il lettore CD è sicuro fintanto che l'auto è progettata in modo che il lettore CD sia sicuro".Tutte le auto collegate in un modo che consenta a un hacker di subentrare vengono automaticamente contrassegnate come "non ben progettate", quindi è un po 'barare.
@CortAmmon - Touché!In tutta onestà, spiego come renderlo sicuro, quindi spero che la mia risposta sia utile a qualcuno.
Nell'hacking di Chrysler, i due sistemi _did_ hanno un'interfaccia estremamente limitata.Ma non abbastanza limitato.Vedi [questa presentazione da 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% 20inalterato% 20passenger% 20vehicle% 20-% 20Video% 20and% 20Slides.mp4).
@MichaelHampton: Il tipo appropriato di restrizione sull'interfaccia sarebbe il flusso di dati in una sola direzione (a livello fisico non solo logico, ovvero senza invio di richieste di lettura o controllo di flusso).Sebbene ci sia una grande quantità di spionaggio che potrebbe essere abilitato inviando informazioni sull'auto al media center, non consentirà mai di prendere il controllo dell'auto.
@BenVoigt - Gli aggiornamenti over-the-air sono una delle ragioni per il flusso di dati dai media al controllo dell'auto.So che questo è stato preso di mira in precedenti hack.Ma è possibile eseguire bene gli aggiornamenti firmati e i vantaggi degli aggiornamenti over-the-air sono significativi.Inoltre, un'auto senza conducente avrebbe bisogno di informazioni sul percorso per passare dal media center al pilota automatico.
Anche se è completamente isolato nel software, è comunque necessario avere anche l'hardware giusto, altrimenti verrà sfruttato.Per esempio.pulsando fili vicini relativi ai media per indurre un segnale anomalo nel bus CAN o qualcosa del genere
La mia macchina ha due lettori CD, uno per i CD audio e l'altro per le mappe di navigazione.
@el.pescado È questa la configurazione di fabbrica?Mi chiedo perché non aggiungono semplicemente un interruttore fisico per attivare il connettore tra il sistema audio e di navigazione.
Sì, questa è la configurazione di fabbrica (è una Opel Vectra del 2007).Penso che il motivo sia quello di consentire di utilizzare la navigazione durante l'ascolto di musica, quindi l'usabilità piuttosto che la sicurezza.
J.A.K.
2016-10-11 17:23:59 UTC
view on stackexchange narkive permalink

Sì, lo sarebbe.

I ricercatori della UC San Diego hanno effettivamente implementato un attacco attraverso questo vettore:

"Abbiamo trovato un difetto in un lettore CD nella nostra macchina ," Egli ha detto. "Puoi scegliere una canzone e codificarla in modo tale che, se la suoni sul tuo PC, la riproduca bene, ma se la suoni in macchina, la riprenderà."

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

Molto probabilmente questo è attraverso una vulnerabilità di danneggiamento della memoria nei tag meta informazioni nel file audio. In questo modo probabilmente erano in grado di indirizzare i comandi al sistema CAN che regola l'auto.

Ma non hai nemmeno bisogno di un CD; nel peggiore dei casi può accadere da remoto tramite reti mobili

Supponiamo che questo sarebbe un inconveniente per l'attaccante per non dire altro ... Immagino che siamo al sicuro * applaude *
Fatta eccezione per la parte sull'hacking da remoto tramite reti mobili; (
"Vorrei" è troppo forte."Potrebbe" sarebbe più corretto.Non vi è alcuna garanzia che un lettore CD abbia delle vulnerabilità o sia collegato ad altri sottosistemi, quindi non è corretto affermare che rappresenterebbe sicuramente un rischio per la sicurezza.
La distribuzione dei media su un servizio di condivisione di file online comporterebbe anche questo in un attacco non mirato.
Mi infastidisce il fatto che gli autori di compilatori C non riconoscano come requisito comune l'idea che ai programmi a cui vengono forniti dati di input non validi sia consentito produrre dati di output arbitrari, ma il formato di output e altri comportamenti devono rimanere definiti.Se ai programmatori non interessa quali pixel o campioni audio vengono generati da un file non valido, soggetto ai vincoli di cui sopra, richiedere che i programmatori gestiscano rigidamente tutti i casi angolari non solo creerà buchi di sicurezza ogni volta che i programmatori non lo fanno, ma danneggerà le prestazioniquando lo fanno (rispetto a lasciare che i compilatori abbiano più libertà).
@supercat - Dai un'occhiata a [Rust] (https://www.rust-lang.org/en-US/)
@paj28: Esiste ancora un supporto cross-compilatore ARM?L'ultima volta che ho controllato, sia D che Rust sembravano linguaggi interessanti, ma nessuno dei due mi è stato utile senza il supporto per la compilazione incrociata ARM.
@supercat - Non conosco la compilazione incrociata, ma ARM [è supportato] (https://github.com/warricksothr/RustBuild).Immagino che tu possa allungare almeno un Raspberry Pi per fare la tua compilazione?
@paj28: Cool.La pagina che hai collegato in precedenza a prima vista sembrava avere solo download relativi al PC disponibili;Dovrò vedere se Rust sembra fattibile per ARM.
@paj28 "discussioni senza gare di dati"?Quindi Rust non consente le variabili condivise?
@JAB - Non conosco i dettagli, ma [questo blog] (http://manishearth.github.io/blog/2015/05/30/how-rust-achieves-thread-safety/) sembra interessante
@paj28 Ok, quindi Rust non ti impedisce di introdurre condizioni di gara se ci provi davvero, ma fornisce solo strumenti migliori per evitarle.
@supercat: Un compilatore C non potrebbe assumersi l'onere di mantenere il "formato di output e altri comportamenti" per programmi difettosi.Anche capire qual è il formato di output corretto richiederebbe al compilatore di leggere la mente del programmatore.Anche lingue molto più sicure come Rust o Haskell non possono offrire quel tipo di garanzia.
@supercat Il compilatore potrebbe compilare una funzione in modo che produca dati di output non validi con dati di input non validi, senza altri effetti collaterali negativi.Ma poi l'output di quella funzione viene usato come indice in una tabella di puntatori a funzione, il che fa sì che la funzione `send_command_to_engine` venga chiamata invece della funzione` play_music`, per esempio.
@immibis: In molti tipi di programmazione, è necessario tenere traccia di quali dati sono stati disinfettati e quali no.I compilatori avevano tradizionalmente consentito che molte operazioni fossero eseguite in sicurezza su dati non disinfettati senza prima disinfettarli, a condizione che i risultati di tali operazioni fossero considerati non disinfettati.Ciò che è killer è che i compilatori osservino che poiché una parte del codice ha calcolato x << y (in uno scenario in cui l'output sarebbe considerato non disinfettato), il compilatore può prendere altrove le funzioni `if (y <40) [y] (qualunque); `e ometti il controllo dell'intervallo perché y" non può "essere superiore a 32.
@user2357112: I requisiti per molti programmi del mondo reale includono alcune parti che devono essere soddisfatte per tutti gli input, e alcune che devono essere soddisfatte solo per input validi.Se si suppone che una funzione valuti `int32a * int32b
... il calcolo sia calcolando un prodotto a 32 bit ed estendendolo con il segno, calcolando un prodotto a 64 bit e usandolo direttamente, sia facendo qualsiasi altra cosa che funzioni nei casi in cui il risultato rientri in un "int di 32 bit""e restituirà uno 0 o 1 in tutti gli altri casi?Il punto è che i programmatori dovrebbero essere autorizzati a usare i controlli dei limiti nei casi in cui dovrebbero influenzare le azioni del programma e ometterli nei casi in cui non dovrebbero averne bisogno, senza che i compilatori considerino l'omissione dei controlli dei limiti in alcuni casi come un invito a ometterlida tutti i casi.
pjc50
2016-10-12 01:59:48 UTC
view on stackexchange narkive permalink

Non importa il lettore CD, i tuoi pneumatici stanno cospirando contro di te

"Vulnerabilità alla sicurezza e alla privacy delle reti wireless per auto: un caso di studio sul sistema di monitoraggio della pressione dei pneumatici"

Abbiamo anche scoperto che le attuali implementazioni non sembrano seguire le pratiche di sicurezza di base. I messaggi non vengono autenticati e anche la ECU del veicolo non sembra utilizzare la convalida dell'input. Siamo stati in grado di iniettare messaggi falsificati e di accendere le spie di avvertenza di bassa pressione dei pneumatici su un'auto che viaggia a velocità autostradale da un'altra auto vicina, e siamo riusciti a disabilitare l'ECU TPMS sfruttando lo spoofing dei pacchetti per accendere e spegnere ripetutamente le spie di avvertimento.

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

Parlando per esperienza personale qui, non è una possibilità a palle di neve all'inferno.

Facevo parte di un team che ha scritto uno stack di dispositivi completamente nuovo per un sistema di infotainment automobilistico nel 2008. Molto tempo fa, ma anche allora abbiamo capito la necessità fondamentale di proteggere il nostro stack software.

Il nostro problema è stato aggravato perché il sistema girava (e gira) su Linux. E abbiamo rispettato pienamente i termini della GPL 2, il che significa che potresti inserire un codice sviluppato da te e l'auto lo lo accetterebbe.

Tuttavia, questo non era specificamente un rischio per la sicurezza perché l'auto utilizzava un sistema di firma digitale. Il tuo codice verrebbe eseguito, ma l'auto si è semplicemente rifiutata di parlare con il tuo software. E comunque non ascoltava: il sistema di infotainment nella migliore delle ipotesi aveva accesso in sola lettura a un piccolo insieme di elementi di dati enumerati come la velocità dell'auto.

So che il nostro sistema era all'avanguardia dell'ingegneria automobilistica all'epoca e il già citato hack Jeep è avvenuto in seguito. Non è davvero sorprendente. C'è un bel po 'di eredità in corso, le riprogettazioni senza foglio non sono così comuni. Jeep è ovviamente un marchio minore di un'azienda in difficoltà, quindi non è una grande sorpresa che siano in ritardo. Ma quello non sarebbe un marchio che ti aspetteresti che produca prima un'auto senza conducente: i principali sospettati sarebbero aziende più sane (potrebbe essere Mercedes, potrebbe essere Toyota e, naturalmente, Tesla)

Ri: "non una possibilità di palle di neve all'inferno".L'OP non ha chiesto del "tuo sistema CD", penso che intendesse qualsiasi sistema.Quindi sembri smentire il tuo commento elencando casi che hanno avuto problemi e li respingi come se non ci fossero quel tipo di società nel settore automobilistico senza conducente.Inoltre, sebbene un sistema possa essere sicuro, è protetto solo contro le cose da cui gli sviluppatori erano in grado di pensare di proteggersi.Spero che il tuo processore non sia stato costruito in Cina, altrimenti chissà quali backdoor aspettano di essere utilizzate.
Il tuo modello di sicurezza era per collegare il controllo dell'auto e i sistemi di infotainment e rafforzare il sistema di infotainment?Sembra che tu abbia preso sul serio la sicurezza, ma penso ancora che sia un progetto rischioso.La superficie di attacco perimetrale è enorme e presumibilmente include cose come i decoder MP3 che devono essere ad alte prestazioni.
Sono d'accordo con @paj28 - "non una possibilità di palle di neve all'inferno" è un'affermazione piuttosto difficile.Le firme digitali dipendono dalle implementazioni crittografiche e gli algoritmi crittografici stessi si trovano deboli e sfruttabili nel tempo, senza contare che spesso anche le loro implementazioni hanno bug.Poi ci sono tutti gli attacchi del canale laterale (come il timing) ecc. L'accesso in sola lettura può anche essere sfruttato per la scrittura tramite bug (ad esempio, nei controlli di accesso stessi - come kernel, hypervisor) o nell'hardware stesso (ricordate Rowhammer?).
@Dunk: Considerando che avevamo bisogno del processore per avviare solo kernel firmati, ed è un prodotto automobilistico, puoi presumere che non sia un bit cinese casuale.Sì, c'è un modulo di protezione "nascosto dal sistema operativo", ecco perché possiamo applicare la firma digitale.
@paj28: Il modello non doveva "indurire" il sistema di infotainment.Il modello doveva considerarlo compromesso per impostazione predefinita: chissà che tipo di codice non firmato potrebbe essere in esecuzione?Fino ai driver, l'intera sorgente del kernel era disponibile.Questo restringe notevolmente la superficie di attacco.
@MatijaNalis: In realtà, il codice non è nemmeno in esecuzione quando le firme vengono controllate e l'intero processo di controllo delle firme è inosservabile (profondamente incorporato).Questa non è una sicurezza di per sé, ma chiunque disponga del livello di accesso fisico richiesto potrebbe semplicemente sostituire o aggiungere hardware aggiuntivo.
Il governo degli Stati Uniti di @MSalters-The non consente nemmeno la costruzione di determinati tipi di prodotti altamente critici che hanno parti fabbricate in Cina a causa di questa preoccupazione.La firma digitale non può aiutare a rilevare che il produttore ha aggiunto transistor extra nel silicio che potrebbero essere utilizzati per attivare meccanismi che possono essere utilizzati per sfruttare il sistema.
@Dunk: La cosa buona è che quando acquisti un milione di chip all'anno per un'applicazione a rischio relativamente basso, il venditore ha una buona ragione per non fregarti.Il problema del governo degli Stati Uniti è che acquistano 1000 chip per applicazioni ad alto rischio.
0x1gene
2016-10-12 20:33:08 UTC
view on stackexchange narkive permalink

La sicurezza sulle auto a guida autonoma sta diventando un argomento di tendenza, poiché le auto ottengono sempre più software.

Più codice e hardware ci sono, più il sistema è esposto perché la superficie di attacco è maggiore. Detto questo, non mi preoccuperei troppo del lettore CD. La più recente auto a guida autonoma sarà connessa a Internet per ottenere vari dati (meteo, traffico, musica in streaming, calendario di sincronizzazione, ecc.). Se un'auto fosse mirata a un cd non sarebbe una scelta saggia e, come hai detto tu, gli hacker sono intelligenti, quindi probabilmente mirerebbero a porte più moderne e aperte verso il mondo esterno.

Detto questo, diciamo fai finta che ci sia un flusso nel tuo lettore cd: l'hacker dovrebbe farti scaricare una canzone, farti masterizzare su un CD e poi sperare che tu la suoni sulla tua auto che si guida da sola - Quindi se non scarichi in modo improprio è praticamente impossibile per loro e sicuramente non vale la pena ...

Un'ultima cosa da aggiungere è che la canzone stessa potrebbe dare somme comandi vocali all'auto se è compatibile ( come cosa hanno fatto per i telefoni). Anche in questo caso dovresti prendere la canzone da una fonte losca e questo non ti consente di fare qualcosa che non è progettato per funzionare con l'interfaccia vocale. Quindi è piuttosto improbabile che una canzone dica alla tua auto di rompersi ...

Dal punto di vista di uno sviluppatore, penso che le auto che si guidano da sole non saranno al 100% a prova di proiettile, ma lo saranno (e lo sono già) essere molto molto più sicure delle auto azionate da esseri umani. Questo è solo perché un computer ha un tempo di risposta più breve, non è mai ubriaco, assonnato o distratto, ha molti più sensi. si fa affidamento su un campo visivo di 200-220 °, il computer può contare su un sistema di telecamere 360 ​​accoppiato a radar a lungo raggio, sensore di prossimità ecc ...

Siamo onesti, quando lanciamo un razzo , è gestito da un computer, non da un essere umano, c'è una ragione per questo.

Spero che ti abbia aiutato a capire meglio i rischi e ad avere meno paura delle auto che guidano da sole.

Sarei piuttosto spaventato da un'auto senza conducente controllata da un computer con un tempo di risposta ** più lento **.Vuoi dire più veloce o più breve.
@AnthonyGrist ahah è vero!Intendevo più breve grazie :)
Quando pilotiamo un aereo, è gestito da un computer, per un motivo.Quando atterriamo su un aereo, non lo è.
@WilliamKappler sia Boeing che Airbus hanno pilotato (gioco di parole) computer che atterrano aerei;così come volo computerizzato completo.Il volo o la navigazione potrebbero essere più semplici del trasporto via terra per un computer.
MikeP
2016-10-13 00:57:21 UTC
view on stackexchange narkive permalink

Se è connesso ai sistemi che fanno funzionare l'auto, allora tutto è possibile.
Se non è connesso, ad es. è un Discman, quindi no.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...