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

Groups > comp.arch.embedded > #21461

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

Show all headers | View raw

On 7/23/2015 6:26 AM, Don Y wrote:
> On 7/23/2015 1:49 AM, Robert Wessel wrote:
>> On Wed, 22 Jul 2015 23:20:33 -0400, rickman <gnuarm@gmail.com> wrote:
>>
>>> On 7/22/2015 10:49 PM, Don Y wrote:
>>>> On 7/22/2015 3:30 PM, lasselangwadtchristensen@gmail.com wrote:
>>>>> Den onsdag den 22. juli 2015 kl. 00.22.18 UTC+2 skrev Don Y:
>>>>>> On 7/21/2015 2:35 PM, Ian Yellowley wrote:
>>>>>>
>>>>>>> I wonder why there should be any connection between these
>>>>>>> networks, I
>>>>>>> can see consolidation of steering, suspension and braking info for
>>>>>>> stability but the rest??? There would seem to be huge differences in
>>>>>>> required bandwidth, latency and reliability so is there a cost
>>>>>>> saving? I
>>>>>>> was involved in the design of steer by wire systems many years
>>>>>>> ago and
>>>>>>> the extent to which we went to provide reliability, multiple
>>>>>>> layers of
>>>>>>> redundancy and isolation from other systems were fairly extreme.
>>>>>>> This
>>>>>>> was in a University lab...I would expect at least that from a
>>>>>>> commercial
>>>>>>> product.
>>>>>>
>>>>>>  From the (limited) exposure I've had to automotive control systems,
>>>>>> there
>>>>>> doesn't seem to be a cohesive, integrated "system design" at work.
>>>>>> Instead, there are all these little islands of control that are
>>>>>> hacked
>>>>>> together and "integrated" after-the-fact.
>>>>>>
>>>>>> [Often, individual subsystems are farmed out to third parties.  E.g.,
>>>>>> you
>>>>>> can bet that the auto manufacturer doesn't design the navigation
>>>>>> system,
>>>>>> entertainment system, security system -- perhaps not even the engine
>>>>>> control system itself!]
>>>>>>
>>>>>> E.g., why would the ECU need to talk to anything other than the
>>>>>> *engine*?
>>>>>> "Ah, but we can tell the air conditioning compressor to disengage
>>>>>> when we
>>>>>> are calling for extra demand from the engine!  So, let the
>>>>>> *engine* tell
>>>>>> the air conditioner to 'pause' -- instead of having some higher
>>>>>> level of
>>>>>> integration impose those rules.  Likewise, let the tranny controller
>>>>>> tell
>>>>>> the door locks to engage when the vehicle is put in gear (or, when
>>>>>> the
>>>>>> wheels attain a certain speed).
>>>>>
>>>>> afaiu from a guy I know that works a lot with car electronics as in
>>>>> building
>>>>> ECUs, gearbox controllers and integrating them with the different
>>>>> system in
>>>>> a number of different cars, most of the systems are stand alone and
>>>>> mostly
>>>>> listen to each other, i.e. the ECU does nothing but run the engine and
>>>>> broadcast what it is doing, ditto for all the other systems
>>>>>
>>>>> so if the doorlocks see the tranny broadcasting a speed over x it can
>>>>> decide to lock the doors, if the AC see the engine broadcast a load
>>>>> over x
>>>>> it can decide to pause, if the ECU see the ABS module broadcast
>>>>> wheelspeeds
>>>>> that indicate wheelspin it can turn down the power
>>>>>
>>>>> I guess it is similar to the unix philosophy, do one thing and do
>>>>> it well
>>>>
>>>> Modern cars are more highly (functionally) integrated.
>>>>
>>>> There is little inherent in the protocols that directly supports
>>>> authentication.  E.g., a node has no *proof* that a message/datum
>>>> actually originated from a node that is *intended* to source messages
>>>> of that type.  So, the "radio link" -- once hacked -- can *forge* a
>>>> message indicating the engine speed is X or the shift lever has been
>>>> placed in 'R' or...
>>>
>>> Only if the radio link has access to the bus for the engine and
>>> transmission.  It is a simple matter to maintain adequate separation
>>> between the core functions and the peripheral functions.
>>
>> There are/will be inevitable points of intersection.  Things like the
>> primary display will need to be attached to both the entertainment
>> system and the more critical car functions.  The engine and nav system
>> will need to send messages to the main display and audio system, the
>> main display will configure drive system parameters ("teenager mode",
>> for example).  What about the need for your car's crash safety system
>> to chat with the cellular radio in the case of a crash?
>
> 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.

That is based on the assumption that there are messages that can travel 
from the insecure bus to the secure bus.  Obviously that has to be 
prevented in all cases.


> 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!  Because the code is written to assume that traffic
> on bus #1 is legitimate, regardless of content (security vulnerability).

Yes, I suppose a total idiot might design a secure system this way.  Or 
they would design it to preserve security.


>> And no, demanding separate displays and whatnot will never fly.
>
> 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
>
> When the ADAS is present, it resides on a separate CAN bus along with the
> Driver Seat Control Unit and a Gateway Module (to the first bus).
>
> So, hack any of these modules -- regardless of how "critical" they
> are for the vehicle to "operate as a means of transportation" -- and
> you can effectively masquerade as *any* of the other nodes on the
> same physical bus.  And, potentially, as any node on the "other"
> bus as well!  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?  How does any node know that it was
> not generated *by* the ADAS???

Why would the ADAS need to *control* any of the units on the secure bus? 
  The ADAS might have commands to query devices on the secure bus, but 
if you allow control that is a way for hackers to get in.

How does the A/V unit get hacked?   Does it have a wireless connection? 
  If so, that is a problem and needs to be corrected.

-- 

Rick

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