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

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.

Too hard. Engineers are human, all too human, and their bosses are lizards.

Reply to
Clifford Heath
Loading thread data ...

Relevant to many of us:

formatting link

"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.
Reply to
Rob Gaddi

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 , 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".

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".
Reply to
Don Y

i

I wonder why there should be any connection between these networks, I can s ee 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 stee r by wire systems many years ago and the extent to which we went to provide reliability, multiple layers of redundancy and isolation from other system s were fairly extreme. This was in a University lab...I would expect at lea st that from a commercial product.

Ian

Reply to
Ian Yellowley

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.

Reply to
Don Y

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.

Reply to
DJ Delorie

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.

Reply to
Don Y

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

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

Reply to
Don Y

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

ed

Reply to
Ed Prochak

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
Reply to
rickman

an

y but

th,

e

we

n
I

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

formatting link

Ian

Reply to
Ian Yellowley

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

-Lasse

Reply to
lasselangwadtchristensen

I think it would be very easy to provide security between the safety functions and the rest of the automotive systems. Use separate buses. There are *very* few military systems that support multiple levels of security on the same hardware... for a good reason. They don't feel software can provide the level of security required unless it is very carefully implemented which is something they don't feel they can do for networking in general. I know of one system that was approved for multiple levels of security over a common network, but that took several years to develop and was a closed system.

Why can't they just use a separate CAN bus for the safety related gear from the bus they use for the infotainment and climate controls, etc? The outside world could connect to the core automotive functions by wires or if wireless is needed they can use a separate wireless connection with high security or at least separate the two levels of security with a robust firewall.

--

Rick
Reply to
rickman

I expect the problem is that the ECU receives commands from the gas pedal over the bus or maybe there is an overall monitor that can shut down essential functions. Perhaps there is an anti-theft feature built in that works over the bus? Clearly they have the ability to control various functions by the bus rather than run many pounds of wire all through the car. I guess some wires are more important than others.

I will have to say it is hard to imagine a valid use case for shutting down the steering or the brakes.

--

Rick
Reply to
rickman

I think the programming model is something akin to having tons of "globals" -- and the assumption that nodes won't access things that they *shouldn't*... but, are free to access things that they *should*!

[This is apparently true of networked systems on modern aircraft!]

E.g., you can buy collision avoidance/mitigation systems that "watch" the road/pedestrians/bicyclists and brake in the event that you *fail* to do so! Likewise, cruise control systems that will automatically throttle back the "setpoint" if you creep up on the car in front of you (of course, cruise control itself has to talk to the engine as your proxy!).

Some cars offer an economy driving mode that does things like drop out the ACbrrr compressor when you accelerate. Others allow the responsiveness of the steering to vary with speed as well as "driver preference".

So, you've got all these little "hooks" poking at various settings, controls, sensors, etc. in the "system" (vehicle) with nothing really deciding "who" *should* see "what".

In my design of the automation system, here, I opted for wired comms for everything (because even encrypted wireless traffic can be victimized in DoS attacks!), encryption and, essentially, a dynamically reconfigured "one port firewall" on each and every port serviced by the network switch. So, if manages to get access to a particular network drop (e.g., the weather station on the roof or the "convenience port" on the front porch), the only traffic that will be accepted by that port ON THE NETWORK SWITCH is the traffic that it is *expected* to generate.

For example, the weather station never tries to visit google.com. Or, download files. Or... So, any traffic on that port attempting to do those things is blocked and the port is shut down.

As such, you could spend a night in our guest bedroom and freely access The Internet from any of the convenience ports located in that room. But, you won't be able to access any of the other automation devices in the house -- no matter how hard you try (you'd need *physical* access to the network switch to bypass its security).

So, you can have a single *physical* network that is partitioned into different logical security domains. E.g., the security camera at the front door can deliver streaming video to your laptop in the guest bedroom (if I so permit) but *nothing* to/from the weather station node on the roof. Nor any commands to (e.g.) unlock the front door!

You have to think about these things *before* implementation. retrofitting security is hard and expensive!

Reply to
Don Y

can

ity but

idth,

the

h we

ion

..I

e*?

u

ll 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 wea knesses of these approaches.

From what I've heard from people that work with this stuff that is how it is normally done, many separate busses access between them controlled centrally and you would have physically open and reprogram hardware to bypass that

I don't know how Chrysler screwed it up

-Lasse

Reply to
lasselangwadtchristensen

If you can block access between various ports, it is *not* a single physical network but rather a collection of interconnected networks with firewalls of some type between them.

Yes, if that security is done in hardware. Obviously if it is done in software it is rather much easier to retrofit.

--

Rick
Reply to
rickman

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

You have to consider any node in the system (modern vehicles have

*many* nodes!) as potentially being compromised. Once compromised, how reliable are your protocol-based security measures? Can I hack the door locks (body controller) and get a beachhead there? Or, the entertainment system? Or...

The security model seems to be one of "don't expect anything *foreign* or adversarial *inside* the vehicle". Sort of like most businesses try to keep adversaries *out* of their "intranets" but, do little to protect against an adversary that's already *inside* the firewall (e.g., a PC that becomes infected from a virus transported across the protection domain on a thumb drive!)

If, instead, you treat each interaction as a secure communication, then you don't care where (physical node or bus) the communication originated -- it self-authenticates.

Imagine lots of VPN's inside the box -- even a VPN *mesh*! An adversary can break physical security but still be locked out because it doesn't have the credentials for the VPN's of interest.

Finally, if you encode rules in the fabric itself (not really possible with the distributed nature of CAN), then you can ensure any infiltration is limited to mimicking the functionality that it has supplanted. E.g., your door lock system can send and receive only messages associated with door locks -- not braking functions, entertainment system functions, environmental controls, etc.

So, you limit the "damage" to the subsystem that has been compromised and nothing more -- you can masquerade ONLY as the subsystem that you've hacked and can't do anything more than that subsystem could do,

[This is where the lack of authentication leaves most systems vulnerable in unnecessarily cascaded "faults"]
Reply to
Don Y

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.

Or you say, screw the authentication and only allow external access to non critical functions by hardware separation.

--

Rick
Reply to
rickman

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?

And no, demanding separate displays and whatnot will never fly.

So it's not ever going to be quite a simple matter of hard physical separation between the critical and non-critical systems. More likely a node serving a firewall/gateway function between otherwise segregated systems makes sense. Rather than trying to implement security in hundreds of different nodes (maintained by a similar number of teams generally not communicating well with each other), concentrate (most) of it in the firewall node.

Reply to
Robert Wessel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.