Hacker News new | ask | show | jobs
by adamgravitis 3984 days ago
So, it's becoming abundantly clear that vehicle companies (autos, jets...) have approximately zero knowledge how to hire software engineers. Presumably they're somewhat more successful hiring mechanical engineers because that's always been their "thing".

It's all well and good for us to chuckle at the terrifying software/systems decisions being made by these teams, but how do we address the root of the problem? It's very clear that entire meta-categories of horrific errors are being made at a very fundamental level. Is this a problem of outsourcing? Of confusing "coders" with engineers?

And how do we solve it? Shame the software team such that they can never get hired in a serious role again anywhere? Professionalize the job into a strictly licensed regime like other branches of engineering?

Whenever I read these types of articles, my main thought has always been, "so who, the hell, wrote the code?" It'd be interesting to know their story.

11 comments

The fact that a dashboard system that controls your radio or AC has access to cut your transmission is also a hardware configuration issue. Accessories should be physically secured from ignition and drive train. The internet connected features of the car, in turn, should be severed from both of these. It should not be physically possible to turn on the wipers from the embedded processor that receives packets on the IP address of the car.
Read up on CAN-BUS. The entire industry is moving to one-wire protocols to reduce the labrynthine copper network that prevailed in the past. If you can put your transmissions diagnostic information on the radio's nice big LCD, why wouldn't you?

Some would say "this, this is why", but those people are not responsible for selling and maintaining millions of vehicles.

> If you can put your transmissions diagnostic information on the radio's nice big LCD, why wouldn't you?

Surely there's a way to make this information read-only. I can see information about my engine on my dashboard via the speedometer and tachometer; it would be ludicrous if I could kill my engine by grabbing the little needles and cranking them down to zero.

> Surely there's a way to make this information read-only.

There absolutely is a way. Just off the top of my head you could relay the information from the high-sec CAN bus to a low-sec one with a micro-controller. So the low-sec bus can only receive messages from the high-sec one.

Not enabling firmware loading over CAN on the relay is a must as well for obvious reasons, but the key is the code on the relay microcontroller can be kept very simple (easier to audit/secure).

Isn't that what the hacked car already doing? I don't know about Jeep specifically, but most cars have several CAN busses and some micro-controller passing messages from high-speed control network to low-speed infotainment network.

Problem is, most automotive engineers are clueless about security and most "hackers" are clueless about automotive hardware, software and protocols. There is no dialog.

I wish articles like these posted at least some specifics. A lot of these hacks in the past were completely impractical. Yes, yes, they had shown some interesting possibilities, but it was disingenuous to present them as real-life attacks (which many media outlets did).

For sures. The ECEs are very much complicit too. Perhaps this is a ECE<->software team communication or power problem? ECEs invent the systems architecture and some poor chap has to attempt to secure the thing? Or maybe the software guys have no avenue to push back against bad systems-level design.
And what are we going to do for self-driving cars? These are almost certainly going to rely heavily on internet access to perform basic driving functions. Figuring out how to make complex systems like these be secure in a trustworthy way is going to be a huge challenge as more and more critical devices are connected to the Internet.
No way a self driving car can rely on Internet access to "perform basic driving functions". Lag and connection failures would kill people.

They might need Internet access for updates, in which case, there should be a physical switch that connects the net and disables the engine.

An air gap is hardly a solution for traffic information the route planner HAS to talk to the computer responsible for getting from A to B. In the same way that firewalls are no longer particularly relevant, air gaps appear to be flawed now too, the only way to solve any security issue is better code quality..
It's not perfect, but an air gap can help reduce the attack surface and interval.

Better code quality is important too, of course.

I agree with cameldrv that it's going to be a challenge.

"And what are we going to do for self-driving cars? These are almost certainly going to rely heavily on internet access to perform basic driving functions."

Actually, no. Google's Urmson has spoken at "connected vehicle" conferences and indicated they don't need car to car communication.

Agreed. The key word here is "basic". Maps have been and can be downloaded, and algorithms to get to point B from A have been embedded for a decade at least. It's only the newer devices (phones) that have managed to push that all server-side. Real-time data like traffic conditions or weather hazards can be added as supplementary data through secure channels, but the entire system does not require an internet connection to work.

Thinking that "basic driving functions" will need to rely _heavily_ on internet access is thinking wrongly.

Which is the primary and most valid criticism of self-driving cars.
That's why they test on this car. Because the CAN buses are all connected without "firewalls".
It's almost like someone designed a network protocol without thinking about security. First time for everything, I guess...
I immediately thought of an unlocked firmware update (or boot over CAN) in some entertainment computer component that can then spoof other subsystems. The security model in modern cars is broken, esp with regard to control and data.
I don't think this has necessarily anything to do with engineering competence.

From a business perspective, security isn't a marketable feature until it becomes a problem—you don't install safety belts, or airbags, or protection against malware until after people start suffering from their absence in a vehicle.

Why? Because while you're busy building a well-secured system, your competitors are busy implementing new features that give them an actual advantage in the marketplace. As unfortunate as it might be, consumers tend to understand things like “remotely start your car with your phone” better than “your ability to brake won't be taken away from you while you're barrelling down the highway at 70 mph.”

It's sad and more than a little scary, but it's also nothing really new. Computer security, at least in the consumer sector, wasn't really a feature until viruses started showing up in the Eighties, and Internet security wasn't really a feature until the average Windows user's PC was getting taken over remotely the moment it was connected to the Net. Even Apple has only been able to tout security and privacy as a feature in its products by juxtaposing it to Google's business model—had the latter not existed and its data grab become part of public discourse, I doubt that Cupertino would have been able to make so much noise about it.

So, it's perfectly possible that every engineer and manager who worked on these systems is really quite competent and perfectly aware of the potential for security flaws (indeed, I doubt that they would have been able to make something so complex work otherwise), and still the sum of all the decisions made and market pressures applied caused the resulting product to be so vulnerable despite everyone's best intentions. It's not because people don't care or don't know, but rather because there are only so many resources available, and the market has pushed them all in a specific direction that happens to be away from security.

But this is also why we need this kind of research. Now that these problems are out in the open, and politicians are starting to take notice, security will become a feature that the public will care about, and, hopefully, car manufacturers will start adopting (or be forced to adopt) better standards.

Ethics are part of competence in my opinion.

Even if you disagree, preventing corporate liability is a component of competence in the law's opinion. That is, if the company is found liable, that's saying the employees responsible did something wrong, even if it's not holding them individually accountable.

Ianal, but from previous fallout on security issues, I'd assume legal liability stops well short of requiring actual competency.

Parent is 100% correct. It's market-adaptation. Same reason Samsung ships known-vulnerable extensions to Android: features >> security.

> So, it's perfectly possible that every engineer and manager who worked on these systems is really quite competent and perfectly aware of the potential for security flaws [...], and still the sum of all the decisions made and market pressures applied caused the resulting product to be so vulnerable despite everyone's best intentions.

I think this is key. Although I'd lump it more on management given that they allocate technical resources. When you have a lack of technical knowledge in management, you lose the ability to make technically informed decisions.

Sometimes the nuances of a situation can't be summed up in a PowerPoint slide. Especially when it's a slide that someone created to summarize a slide deck from an engineer that they saw.

You think at least some of the OPM vulnerabilities were internally unknown? Even with incompetence, you had to have actual engineers who looked at settings and/or lack of feedback and went "Hunh..."

In addition to your third paragraph, auto makers are disincentivized toward adding security features because they CAN'T advertise them. If Toyota started advertising the all new Prius with the feature "your ability to brake won't be taken away from you while you're barrelling down the highway at 70 mph", consumers wouldn't just not care, they would question why the fuck that wasn't there in the first place. This sort of stuff is expected to have been there from the start by consumers, so at this point its nothing but a cost sink to add it.
This will change as awareness of these attacks reaches the general public.

According to the article, US politicians are looking at introducing legislation to enforce cybersecurity measures. At that point, it will just be another safety rating that manufacturers can and do use to promote their vehicles.

For the same reason I am skeptical of the "Internet of Things". Do we really want every device in our home to be exploitable from someone across the globe? Continually applying firmware updates to appliances to close security holes? Something fundamental has to change about how we handle device security before I want to live in that world.
exactly!

I want all my devices to be as dumb as wires.

Wired technology just works, out-of-the-box, no setup, no maintenance, no nothing .. just make sure the plug fit in both ends, and done!

Wireless technology should work similar, but via the air, like an invisible wire .. not as a open gate to the internet!

..and please let's not add multi-purpose CPU just for the sake of marketing!

What? The Internet of Things is equally exploitable if your devices are connected over ethernet (or ethernet over powerlines). The key factor is whether or not it's connected to the Internet.
Are you pointing to the stellar security record of the software industry here?
Exactly. I'd like to see the perfect security implementations over large scale systems that exist in the software industry today.
Aviation is doing pretty well. I'd hope for the same standard of safety and security from automobile manufacturers.
People, and businesses, respond to incentives. The company probably did the economically rational thing here - the money they make from their remote-access features is more than the money they will lose for the insecurity.

Companies in industries that need to find ways to make secure software; it's not a hard problem if you're willing to throw enough money at it. But as long as customers don't care whether their products or data are secure, we'll get the security we pay for.

People do care if it makes the news. But the current official ways of doing the testing doesn't make the news and testing that is news worth gets the cops called on you. How convenient that testing a security flaw is viewed as more negligent than allowing them in the first place as a cost saving measure.
Allowing the flaw was negligent. This test was reckless. The law treats knowingly ignoring a risk as worse than unknowingly allowing one.
Unknowingly allowing a risk is a very generous way to describe policies that cut costs by increasing the chance of these risks. The ones who are endangering a small number of people to try to overall increase safety are currently looking at far more legal harm than those who endangered magnitudes more people for the sake of making more money. Don't contribute to stupidity what can be explained by amoral greed.
I think this also comes down to the curriculum and training that Computer Engineers receive during undergrad. Since the core courses touch embedded, hardware design, and software we're left with only the basics. Coming from the Detroit/Big 3 area a lot of my colleagues went off to Toyota (in ann arbor), GM, Chrysler, Ford, or one of their suppliers/contractors (Denzo et al.); and from what i've been told is that they do put a lot of effort into software, however it's focus is more on stability and function as opposed to security and portability.

This doesn't mean they're doing a good job though. Here's a link to where i previous discuss this: https://news.ycombinator.com/item?id=9801769

I imagine a not terribly experienced new team being told to do connected stuff in a car, not really understanding security and having ridiculous demands thrown at them as the manufacturer drools about getting subscription revenue from every car. But would be nice to have an inside story.
I don't know about the automotive industry, but this is absolutely true at some industrial equipment manufacturers.
Which entire meta-categories of horrific errors do you ascribe to software development for jets? Commercial avionics, while not error-free, is surely one of the most stringent sectors of software development around today.
The same shift to focus on security is happening with medical devices and the FDA. Maybe that's one place to look for success and failure.
Get a German car and you will not have such problems from what I know from my people. ;)
What's more probable?

a) The developers were this incompetent

b) This "exploit" was a feature requested by the DHS

Oh, I know this one! Is it c) "The developers were competent at designing car control software, but insufficiently concerned about the possibilities for remote control, and therefore didn't test appropriately"?