Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #21467
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway |
| Date | 2015-07-23 21:38 +0200 |
| Message-ID | <d1cu4vFgjleU1@mid.dfncis.de> (permalink) |
| References | (3 earlier) <2b477b24-3685-41cb-977f-9832e6803b98@googlegroups.com> <mopkn7$jik$1@speranza.aioe.org> <mopmf8$s70$1@dont-email.me> <92a1ra5pcdrn5abq9gs88u6kph6qas13u0@4ax.com> <moqffb$hb1$1@speranza.aioe.org> |
Am 23.07.2015 um 12:26 schrieb Don Y: > Exactly. Even if a "compromised" node does not have direct *physical* > access to a "special" bus, the fact that the compromised node can > effortlessly masquerade as ANY node on the bus(ses) to which it has > direct contact means any other gateway/bridge nodes *will* propagate > forged messages that it generates *to* that "other bus" AS IF the > messages were created by the genuine node instead. Only if the node it's masquerading as is on the same bus as the compromised one. And only if the firewall/gateway node is given no means to recognize the fact that there are now two data streams purporting to be from the same node. > This also assumes those gateway nodes are smart enough to recognize > *specific* traffic on "bus #1" as only legitimate *on* bus #1. I.e., > if a node on bus #1 forges a message that a node on bus #2 would > normally generate, the gateway *may* be naive enough to transport the > message across the protection domain even though it was detected on > the "wrong" bus! That error case is not a practically relevant one. Gateways have enough work on their plate as-is. They have to know which message they're supposed to receive on which bus, and which they're to echo/send, or they just couldn't handle the work load. Otherwise they would flood each network with the traffic of every other one. > Because the code is written to assume that traffic > on bus #1 is legitimate, regardless of content (security vulnerability). In practice, it's not. Car network designers really aren't _that_ daft (presently publicised bad example case possibly excluded). > Looking at a factory service manual for a Nissan Murano (we're in the > market for a new vehicle so I've been reading a lot of service manuals) > shows one or two CAN busses (depends on whether or not the vehicle has > the Advanced Driver Assistance System (ADAS) installed -- gizmo that acts > as a proxy for the driver). The *first* CAN bus always has the following > nodes: > - Engine Control Module > - Antilock Brake System > - Tranny Control Module > - Steering Angle Sensor > - All Wheel Drive Control Unit > - Automatic Backdoor Control Module > - Combination Meter (this is a display) > - Power Steering Control Module > - Audio / Visual Control Unit > - HVAC Control > - Body Control Module > - Intelligent Power Distribution Module That's quite a small, old-fashioned layout by today's standards. A current-model passenger car would have between twice and four times as many CAN ECUs as that, and putting drive train control units on the same CAN network as, say A/V or HVAC ones has gone out of fashion about a decade ago. There are still some nodes that are so central that it would be hard to the point of impossible to isolate their security-sensitive functions from their other ones, e.g. the steering wheel group. These days buttons and levers on and around the steering wheel (for very good reason, too) control a wild mix of systems, only some of which are critical (cruise control, driver assistance, control over what gets displayed in the combination display, blinkers, wipers, radio, telephone, ...). And then there's the airbag sitting in the middle of all that. And the meaning of buttons will change based on what the multimedia central display currently shows, or what options were ordered with the car. Good luck trying to implement security isolation zones in _that_! And then new legal requirements like "E-Call" practically require to break any isolation barriers between established critical systems and others like the multimedia/navigation/telephone ones that are by _huge_ popular demand about as architecturally open and as connected as a desktop PC, and consequently about as security conscious as those. It's basically a miracle they largely managed to keep MS bloody Windows out of those boxes so far, and now they're supposed to perform survival-critical emergency tasks! That's insanity, and I'm quite sure everybody involved knows it. > I.e., if the A/V Unit is hacked and emits a message > that *should* have originated from the ADAS *via* the gateway, > how can any node on the first bus know that it was NOT propagated > to the bus by the gateway? For starters, the gateway itself knows that (because it should have been sending that message, not receiving it). And it doesn't take much engineering to make such extra message trains recognizable. About the simplest one is a rolling counter in the original messages. That doesn't allow yet to detect which of two message streams is actually genuine, but it does allow detection that something's foul in the state of Denmark.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Semi-OT: Hackers Remotely Kill a Jeep on the Highway Rob Gaddi <rgaddi@technologyhighland.invalid> - 2015-07-21 19:28 +0000
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-21 13:00 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Clifford Heath <no.spam@please.net> - 2015-07-21 21:49 +1000
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-21 18:55 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway DJ Delorie <dj@delorie.com> - 2015-07-21 20:37 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-21 18:47 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Ian Yellowley <iany99@gmail.com> - 2015-07-21 14:35 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-21 15:22 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Ian Yellowley <iany99@gmail.com> - 2015-07-22 13:42 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-22 18:48 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway lasselangwadtchristensen@gmail.com - 2015-07-22 17:33 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Rob Gaddi <rgaddi@technologyhighland.invalid> - 2015-07-24 16:51 +0000
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Paul Rubin <no.email@nospam.invalid> - 2015-07-24 10:23 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-24 11:22 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-07-24 21:49 +0200
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway hamilton <hamilton@nothere.com> - 2015-07-24 12:45 -0600
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-22 16:59 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-22 21:30 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway lasselangwadtchristensen@gmail.com - 2015-07-22 15:30 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-22 18:53 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-22 19:49 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-22 23:20 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Robert Wessel <robertwessel2@yahoo.com> - 2015-07-23 03:49 -0500
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Don Y <this@is.not.me.com> - 2015-07-23 03:26 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-23 12:09 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-07-23 21:38 +0200
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-23 16:36 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-07-23 23:56 +0200
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-24 13:25 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-23 11:32 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Ed Prochak <edprochak@gmail.com> - 2015-07-21 20:00 -0700
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway rickman <gnuarm@gmail.com> - 2015-07-22 00:57 -0400
Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway Mel Wilson <mwilson@the-wire.com> - 2015-07-26 15:06 +0000
csiph-web