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

Relevant to many of us:
http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway

"Uconnect, an Internet-connected computer feature in hundreds of 
thousands of Fiat Chrysler cars, SUVs, and trucks, controls the vehicle’s 
entertainment and navigation, enables phone calls, and even offers a Wi-Fi 
hot spot. And thanks to one vulnerable element, which Miller and Valasek 
won’t identify until their Black Hat talk, Uconnect’s cellular connection 
also lets anyone who knows the car’s IP address gain access from anywhere 
in the country."

Since they've so conveniently networked the entertainment system together 
with the steering, brakes, and transmission, an exploit into the former 
is an exploit into the latter.

So the discussion topic for all of us engineers is: whose job should it 
be to stop this sort of nonsense from occurring.  Ideally there'd be some 
sort of government standards dictating what security measures need to be 
taken, but practically government's understanding of technology 
occasionally covers the toaster.  Is it each of our jobs to call stop the 
presses when we something so blatantly stupid, and refuse at the expense 
of our jobs to work on a security flawed project?

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

On 7/21/2015 12:28 PM, Rob Gaddi wrote:
> Relevant to many of us:
> http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway
>
> "Uconnect, an Internet-connected computer feature in hundreds of
> thousands of Fiat Chrysler cars, SUVs, and trucks, controls the vehicle’s
> entertainment and navigation, enables phone calls, and even offers a Wi-Fi
> hot spot. And thanks to one vulnerable element, which Miller and Valasek
> won’t identify until their Black Hat talk, Uconnect’s cellular connection
> also lets anyone who knows the car’s IP address gain access from anywhere
> in the country."
>
> Since they've so conveniently networked the entertainment system together
> with the steering, brakes, and transmission, an exploit into the former
> is an exploit into the latter.

There's nothing uncommon about this sort of practice.  How many companies
have their "public presence" tied, somehow, to their *private* intranets?
"For convenience".

In the late 70's I designed a (LORAN-C) autopilot for use on maritime vessels.
Like today's GPS's, you could specify a *destination* (lat-lon) -- instead of
just a "heading".  This immediately suggests avenues for abuse:  go below
deck and work on <whatever>, take a nap, etc.  "Who's minding the ship??"

I suggested tying the autopilot to an alarm/annunciator that would alert
(annoy) the vessel's captain when a destination was reached (otherwise,
the boat would overshoot the destination -- as the autopilot only had
control of rudder -- and then "loop back", repeatedly).

Boss said, "The *first* thing the captain is going to do is cut the
wires to that annunciator...".  So, instead of being touted as the
world's first "consumer" closed loop autopilot, it would be remembered
as "that annoying, nagging beast".

> So the discussion topic for all of us engineers is: whose job should it
> be to stop this sort of nonsense from occurring.  Ideally there'd be some
> sort of government standards dictating what security measures need to be
> taken, but practically government's understanding of technology
> occasionally covers the toaster.  Is it each of our jobs to call stop the
> presses when we something so blatantly stupid, and refuse at the expense
> of our jobs to work on a security flawed project?

I think the only legislative solution is to mandate public disclosures of
these sorts of things.  No "gag orders" in litigation/settlements, etc.
I.e., you can keep settlement terms, amount$, etc. quiet -- but can't suppress
the technical findings that come to light.

Sadly, the rest is up to "good engineering"...

Unfortunately, I don't think many folks have the skillsets, mindsets or
*motivation* to look at vulnerabilities in their products (witness how
wildly enthusiatic -- NOT! -- most folks are about writing formal
specificaations, comprehensive testing/documentation, etc).  Boss doesn't
care about those ("We'll worry about it later") so your efforts are
likely to be seen as "obstructionist".

On Tuesday, 21 July 2015 11:29:40 UTC-8, Rob Gaddi  wrote:
> Relevant to many of us:
> http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway
> 
> "Uconnect, an Internet-connected computer feature in hundreds of 
> thousands of Fiat Chrysler cars, SUVs, and trucks, controls the vehicle's 
> entertainment and navigation, enables phone calls, and even offers a Wi-Fi 
> hot spot. And thanks to one vulnerable element, which Miller and Valasek 
> won't identify until their Black Hat talk, Uconnect's cellular connection 
> also lets anyone who knows the car's IP address gain access from anywhere 
> in the country."
> 
> Since they've so conveniently networked the entertainment system together 
> with the steering, brakes, and transmission, an exploit into the former 
> is an exploit into the latter.
> 
> So the discussion topic for all of us engineers is: whose job should it 
> be to stop this sort of nonsense from occurring.  Ideally there'd be some 
> sort of government standards dictating what security measures need to be 
> taken, but practically government's understanding of technology 
> occasionally covers the toaster.  Is it each of our jobs to call stop the 
> presses when we something so blatantly stupid, and refuse at the expense 
> of our jobs to work on a security flawed project?
> 
> -- 
> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> Email address domain is currently out of order.  See above to fix.

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.

Ian

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).

Too many protection domains routinely crossed due to the method of
implementation.  So, how can you ever hope to retrofit "security"
and "reliability" after-the-fact?  It's almost inherent in CAN that you
have a somewhat "flat" architecture.

Don Y <this@is.not.me.com> writes:
> Boss said, "The *first* thing the captain is going to do is cut the
> wires to that annunciator...".  So, instead of being touted as the
> world's first "consumer" closed loop autopilot, it would be remembered
> as "that annoying, nagging beast".

My dad was chief on a tugboat.  Once they tried to tie a computer to his
engine, and he made them cut the wires to the engine - and leave the
annunciator.

He did *not* want a computer in charge of his boat, ever.

He *did* want the computer yelling at him if something might be going
wrong.

On 7/21/2015 5:37 PM, DJ Delorie wrote:
>
> Don Y <this@is.not.me.com> writes:
>> Boss said, "The *first* thing the captain is going to do is cut the
>> wires to that annunciator...".  So, instead of being touted as the
>> world's first "consumer" closed loop autopilot, it would be remembered
>> as "that annoying, nagging beast".
>
> My dad was chief on a tugboat.  Once they tried to tie a computer to his
> engine, and he made them cut the wires to the engine - and leave the
> annunciator.

Then, he wouldn't be the sort who would even *consider* buying such
a device -- as its whole purpose was to *steer* the vessel.  (silly
to have an annunciator that tells him when *he* has piloted the
vessel to *his* desired destination!  :> )

OTOH, thousands of "small operators" (e.g., lobstermen) setting out
to open sea each day could easily be seen to treat the autopilot as an
"unpaid hand" -- i.e., it pilots the boat while they ready the pots,
nets, lines, etc.  Before leaving port, key in the lat-lon's of the
planned drops for your pots (or, locations of previously dropped pots),
set the throttle and go!  *Knowing* that it will effectively stop
(circle?) when it reaches it's destination can leave them free to do
the other things that their "free" eyes and arms can now manage.

> He did *not* want a computer in charge of his boat, ever.
>
> He *did* want the computer yelling at him if something might be going
> wrong.
>

On 7/21/2015 4:49 AM, Clifford Heath wrote:
> On 22/07/15 06:00, Don Y wrote:
>> On 7/21/2015 12:28 PM, Rob Gaddi wrote:
>>> "Uconnect, an Internet-connected computer feature in hundreds of
>>> thousands of Fiat Chrysler cars, SUVs, and trucks, controls the vehicle’s
>>> entertainment and navigation, enables phone calls, and even offers a
>>> Wi-Fi hot spot. And thanks to one vulnerable element, which Miller and Valasek
>>> won’t identify until their Black Hat talk, Uconnect’s cellular connection
>>> also lets anyone who knows the car’s IP address gain access from anywhere
>>> in the country."
>
>>> So the discussion topic for all of us engineers is: whose job should it
>>> be to stop this sort of nonsense from occurring.  Ideally there'd be some
>>> sort of government standards dictating what security measures need to be
>>> taken, but practically government's understanding of technology
>>> occasionally covers the toaster.
>
>> I think the only legislative solution is to mandate public disclosures of
>> these sorts of things.
>
> Perhaps, but please observe the actual behaviour of your government over the
> last decade. This indicates that their response is likely to be to focus on
> declaring war on hackers and security engineers, with massive enforcement and
> penalties for looking for, discovering or exposing such vulnerabilities. To say
> nothing of utilising them... The DMCA comes to mind as a precursor... fix the
> symptom not the cause.

Don't mistake my suggestion as an indication of what I think *will*
happen.  Rather, what I think is the "best compromise" between all the
stakeholders.

Businesses won't want to be legislated into more regulations.
Other groups would claim "The Market" will (magically!) solve
all these problems (gleefully ignoring the costs incurred -- by
OTHERS -- along the way).

OTOH, its hard to argue against *disclosure*.  You can wrap it in
as many "alleged" and "suspected" qualifiers as you want.  But,
exposing flaws instead of burying them in some lawsuit "settlement"
seems the best compromise mechanism for driving solutions to the
problems.

"Obscurity" just allows problems to linger.

Publicly disclose a vulnerability and you can bet your ass folks
will rush to plug the holes quickly -- instead of just letting it
sit in litigation for years, "as is".

>> Sadly, the rest is up to "good engineering"...
>
> Too hard. Engineers are human, all too human, and their bosses are lizards.

Despite being a cynic, I have more faith in folks.  All my boss/client
can do to force me to "let go" of a project is to take it away from me,
unfinished.  He's still stuck with getting it finished, afterwards!
If I'm good at my craft, he risks exposing a shoddy product to a market
that can then judge him, publicly (with $$$, or -$$$ as the case may be!).

On Tuesday, July 21, 2015 at 3:29:40 PM UTC-4, Rob Gaddi wrote:
> Relevant to many of us:
> http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway
> 
> "Uconnect, an Internet-connected computer feature in hundreds of 
> thousands of Fiat Chrysler cars, SUVs, and trucks, controls the vehicle's 
> entertainment and navigation, enables phone calls, and even offers a Wi-Fi 
> hot spot. And thanks to one vulnerable element, which Miller and Valasek 
> won't identify until their Black Hat talk, Uconnect's cellular connection 
> also lets anyone who knows the car's IP address gain access from anywhere 
> in the country."
> 
> Since they've so conveniently networked the entertainment system together 
> with the steering, brakes, and transmission, an exploit into the former 
> is an exploit into the latter.
> 
> So the discussion topic for all of us engineers is: whose job should it 
> be to stop this sort of nonsense from occurring.  Ideally there'd be some 
> sort of government standards dictating what security measures need to be 
> taken, but practically government's understanding of technology 
> occasionally covers the toaster.  Is it each of our jobs to call stop the 
> presses when we something so blatantly stupid, and refuse at the expense 
> of our jobs to work on a security flawed project?
> 
> -- 
> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
> Email address domain is currently out of order.  See above to fix.

This would be on topic at comp.risks
Probably is there already.

ed

On 7/21/2015 3:28 PM, Rob Gaddi wrote:
> Relevant to many of us:
> http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway
>
> "Uconnect, an Internet-connected computer feature in hundreds of
> thousands of Fiat Chrysler cars, SUVs, and trucks, controls the vehicle’s
> entertainment and navigation, enables phone calls, and even offers a Wi-Fi
> hot spot. And thanks to one vulnerable element, which Miller and Valasek
> won’t identify until their Black Hat talk, Uconnect’s cellular connection
> also lets anyone who knows the car’s IP address gain access from anywhere
> in the country."
>
> Since they've so conveniently networked the entertainment system together
> with the steering, brakes, and transmission, an exploit into the former
> is an exploit into the latter.
>
> So the discussion topic for all of us engineers is: whose job should it
> be to stop this sort of nonsense from occurring.  Ideally there'd be some
> sort of government standards dictating what security measures need to be
> taken, but practically government's understanding of technology
> occasionally covers the toaster.  Is it each of our jobs to call stop the
> presses when we something so blatantly stupid, and refuse at the expense
> of our jobs to work on a security flawed project?

No need for government standards on the technology.  The existing tort 
law has as much or more effect on auto makers.  They will perform all 
sorts of gyrations to minimize the impact of mistakes via law suits.  If 
the government sets mandates on the technology auto makers will use that 
as their defense to say they performed due diligence.  Whey users ask 
why the system has other types of problems such as lacking features or 
poor performance, the auto makers will point to the government standards 
saying they limit what they are allowed to do.

Instead the government should make it easier to hold auto makers 
accountable for their mistakes.  I haven't driven any of the fancy newer 
cars, but I would be willing to bet the first time you use the "smart" 
systems to have to click an OK on the user agreement that has two 
portions which are not in the consumer's best interest.  The first is a 
limitation of liability which attempts to prevent law suits, but is not 
perfect.  The other is a requirement of the user to indemnify the auto 
maker making it impossible to ever collect on a liability claim if the 
user does manage to win a suit.  Both of these provisions should be 
outlawed by federal law.

History has shown that auto makers try to use federal standards to limit 
their liability.  We can prevent this by proactive measures in 
electronic technology liability law.

-- 

Rick

On Tuesday, 21 July 2015 14:22:18 UTC-8, Don Y  wrote:
> 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).
> 
> Too many protection domains routinely crossed due to the method of
> implementation.  So, how can you ever hope to retrofit "security"
> and "reliability" after-the-fact?  It's almost inherent in CAN that you
> have a somewhat "flat" architecture.

Yes there are possibilities to do "neat things" at the expense of overall security. This stuff worried me enough to go back to the literature. The following paper seems to address a lot of the issues as well as explaining the typical method of interfacing between the various networks and the weaknesses of these approaches.

http://www.autosec.org/pubs/cars-oakland2010.pdf

Ian