Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #21467

Re: Semi-OT: Hackers Remotely Kill a Jeep on the Highway

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>

Show all headers | View raw


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


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