Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Transportation Bug Programming Security

One In Five Vehicle Software Vulnerabilities Are 'Hair On Fire' Critical (securityledger.com) 85

Long-time Slashdot reader chicksdaddy quotes a report from Security Ledger: One of every five software vulnerabilities discovered in vehicles in the last three years are rated "critical" and are unlikely to be resolved through after the fact security fixes, according to an analysis by the firm IOActive. "These are the high priority 'hair on fire' vulnerabilities that are easily discovered and exploited and can cause major impacts to the system or component," the firm said in its report...

The bulk of vulnerabilities that were identified stemmed from a failure by automakers and suppliers to follow security best practices including designing in security or applying secure development lifecycle (SDL) practices to software creation... The result is that vehicle cybersecurity vulnerabilities are not solvable using "bolt-on" solutions, IOActive concluded...

The article argues we're years away from standards or regulations, while describing auto-makers as "wedded to the notion that keeping the details of their systems secret will ensure security."
This discussion has been archived. No new comments can be posted.

One In Five Vehicle Software Vulnerabilities Are 'Hair On Fire' Critical

Comments Filter:
  • by StandardCell ( 589682 ) on Sunday August 14, 2016 @08:55AM (#52699515)
    The recently publicized vulnerabilities in connected vehicles are examples of vehicle designers not understanding security threat models correctly (which also applies to IoT in general). In the rush for convenience and connectivity it is mind boggling that they wouldn't make more effort if for no other reason than to avoid the negative publicity.

    The easiest thing to do in these critical vehicle systems systems is to outright air gap them. There is no reason that there should be any network connection to the autopilot or auto-parking or braking system of a vehicle unless the threat model and the subsequent design of security was sufficiently thorough. Until that happens, it should literally be a discrete action by the driver through a physical interface inside the vehicle and at most have a one-way reporting interface that can be picked up by a network interface.

    The other thing that can be done is to hardware-interlock the network connection. For example, the steering motor controllers for automatic parking should have a logic AND control to the speed of the vehicle so that anything above a certain speed disables the motor control at a hardware level. At that point, one would have to physically tamper with the vehicle to overcome this safeguard, but if you could do that there's a lot more mayhem you could create anyway.
    • by twdorris ( 29395 ) on Sunday August 14, 2016 @09:13AM (#52699583)

      I understand what you're getting at and mostly agree. My only comment is that once you design these big in-vehicle fully-connected systems to do stuff like report on steering angle and live fuel pressure or whatever else, it's awfully tempting to turn around and implement the PUT or POST to go along with those GET APIs so that all your dealer diagnostics and datalogging tools just hook into the same point everything else does. It reduces the number of different systems and interfaces you have to design, implement and debug.

      I have no data on this, but I suspect cost cutting measures have to be insane at auto makers. I recall buying a nice turbo AWD Eclipse in the mid-90s for nearly $30k. Twenty years later and I can still buy a nice turbo AWD car for just a little more than that and this new car will have VASTLY superior features all around. The cost difference barely accounts for inflation. How they also crammed so much new tech and new hardware into it for what's effectively the same price today as it was 20 years ago boggles my mind.

      So I suspect this all comes down to trying to push more stuff through that new system to save a few bucks somewhere and then skipping that whole "security" check in the process.

      • How they also crammed so much new tech and new hardware into it for what's effectively the same price today as it was 20 years ago boggles my mind.

        That's just the nature of progress. The ability to buy a new 1TB HDD now for the cost of a 1GB HDD 20 years ago doesn't mean that the designers aren't making the same or even more profit on them.

      • I understand what you're getting at and mostly agree. My only comment is that once you design these big in-vehicle fully-connected systems to do stuff like report on steering angle and live fuel pressure or whatever else, it's awfully tempting to turn around and implement the PUT or POST to go along with those GET APIs so that all your dealer diagnostics and datalogging tools just hook into the same point everything else does. It reduces the number of different systems and interfaces you have to design, implement and debug.

        I have no data on this, but I suspect cost cutting measures have to be insane at auto makers. I recall buying a nice turbo AWD Eclipse in the mid-90s for nearly $30k. Twenty years later and I can still buy a nice turbo AWD car for just a little more than that and this new car will have VASTLY superior features all around. The cost difference barely accounts for inflation. How they also crammed so much new tech and new hardware into it for what's effectively the same price today as it was 20 years ago boggles my mind.

        So I suspect this all comes down to trying to push more stuff through that new system to save a few bucks somewhere and then skipping that whole "security" check in the process.

        Answer
        Robotics and automated assembly lines did away with workers. It takes far fewer workers to assemble a vehicle today, than it required 5 years ago.

  • The one that causes your sunroom motor to overheat, which causes your hair to catch on fire - this is (hair on fire)^2; quadratic fire events are always bad.
  • by jenningsthecat ( 1525947 ) on Sunday August 14, 2016 @09:26AM (#52699623)

    I get that digital technology has brought a lot to the party when it comes to efficiency, emissions, and other important performance metrics. But cars are one-tonne-plus hunks of metal which contain human beings and regularly travel at speeds in excess of 30 metres per second. Do we really want them connected to the same Internet used by Nigerian scammers, Ashley Madison hackers, and Donald Trump?

    The IOT - I guess it's not just for toasters any more...

    • by Mashiki ( 184564 )

      Unless the vehicle has steering that's drive-by-wire you're not really going to have to worry about much from a safety perspective, and there are a few vehicles that no longer have physical steering wheels but rather use electric motors for steering. Right now that's only in the very high-end vehicles. But over-all you're right, you don't want them connected as such, or you want specific parts to be separated from other components of the vehicle. I've got no problem with console/maps/etc being internet

      • Unless the vehicle has steering that's drive-by-wire you're not really going to have to worry about much from a safety perspective

        Steering? Oh man, steering is the least of your problems. Kill the engine along with your power steering mid turn and I don't need to do anything with your steering wheel to make you hit a pedestrian. How about that ABS? The electronic system which controls brake pressure? Fancy a wheel suddenly locking up while you're going down a highway?

        You don't need a self driving car, just a car made in the past 10 years connected to the internet with an exploitable hole in the CAN bus to cause some serious safety con

        • by Mashiki ( 184564 )

          Steering? Oh man, steering is the least of your problems. Kill the engine along with your power steering mid turn and I don't need to do anything with your steering wheel to make you hit a pedestrian. How about that ABS? The electronic system which controls brake pressure? Fancy a wheel suddenly locking up while you're going down a highway?

          Killing the engine is only going to cause you to drop in speed, and power steering is tied to the engine. It's much more difficult to turn the steering wheel, but not impossible. And if you're making a turn over 30km/h, you're already a shitty driver and that's a driver problem. ABS? Depends on the type is a braking type, then it already is using 50% of the brake pressure in the system on the other wheel to ensure you're not losing control. All braking systems are designed in a diagonal system in the e

          • Killing the engine is only going to cause you to drop in speed

            Yep, something that has caused deaths in the past.

            No you really do

            No you really don't. There are demonstrated exploits that simply kill the engine. There are documented cases of acceleration failure or even stalling engines causing fatal accidents.

      • Unless the vehicle has steering that's drive-by-wire you're not really going to have to worry about much from a safety perspective

        Yeah, it's basically that bad [wired.com]. Not just steering, but brakes, and acceleration.

    • Frakkin' Cylons! :P

  • by Opportunist ( 166417 ) on Sunday August 14, 2016 @09:46AM (#52699677)

    Back in the early 80s when Bosch invented the CAN bus, security was a non-issue. For more than one reason. First, no critical system of the car was part of the bus system. It was mostly used to easily bundle electronics so you don't have to run 200 cables across the car just to transmit different signals. Second, microelectronic wasn't so advanced that you could implement some huge protocols with security in mind, you were lucky if you found chips that could at least find out what signals were for them. And third, there was no "open ends" so to speak, there was no bluetooth, no wifi and most of all none of all this ended at the user side of the car, the user had zero chance to mess with the whole deal.

    But you know how it is, things grow and specs don't change. Because if you changed them, the existing technology wouldn't be compatible anymore, you'd have to develop new shit, your workers would have to be retrained and in the end, the whole crap simply costs more.

    And today we're now at this mess where we have a totally insecure bus that pretty much takes whatever signal you put into it without bothering to question the source that connects mission critical systems (from door opening to brakes) along with user space gadgets, and of course wifi, bluetooth and various other ways to connect wirelessly, from inside or outside the car.

    It does not take an expert in information security to see why this could possibly hint at being a wee bit of a potential problem, does it?

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      Back in the early 80s when Bosch invented the CAN bus, security was a non-issue. For more than one reason. First, no critical system of the car was part of the bus system. It was mostly used to easily bundle electronics so you don't have to run 200 cables across the car just to transmit different signals. Second, microelectronic wasn't so advanced that you could implement some huge protocols with security in mind, you were lucky if you found chips that could at least find out what signals were for them. And

      • Yes, CAN was never designed to be anything like Ethernet or run high level user space signals, the problem is that it's abused to do just that.

        I'm totally with you that it should not be used in such a way and that it is good for what it was designed for, the problem is that it's the hammer that is available so every problem is being turned into a nail so the hammer can be used as the tool to solve it. And that's simply not how it should be done.

      • My concerns are the same. The problem is that autonomous car makers are totally basing the reliability on the autonomy on the fact that the cars talk to each other. Is there any autonomous system being built where the car can operate independently?
        • The problem is that autonomous car makers are totally basing the reliability on the autonomy on the fact that the cars talk to each other.

          No they aren't. In fact every major autonomous car initiative currently in the testing phase doesn't communicate with any other car.

          Now in the trucking world that is different. Semi-autonomous trucks are designed to communicate with each other in order to safely platoon. i.e. drive close enough to each other that wind resistance is all but eliminated, and that's a fuel saving measure. Again trucks are the only place at the moment where autonomous driving is being tested where a vehicle has any communication

          • Well I know Autopilot needs to be connected, it is always sending driving data back to Tesla. I don't know about the others.
            • No it doesn't. Sending data back to Tesla serves no reliability purpose, it's diagnostics only to help drive developmental improvements. If you drive through a tunnel it doesn't magically drop your car out of autopilot.

  • You want to call it "engineering"? Then make it ENGINEERING, with actual consequences if you write bad code.

    You call it "art"? You wanna do "art"? Go to Michael's and get your ass some fucking finger paint.

  • No Internet-connected vehicle. No wireless unlocking or ignition switch.

    And no hair.

  • VW is just the first mega-liability case even though it is between governments and VW, with some benefits going to VW owners.

    The next issues are likely to be gigantic class action cases which might bring a car company to its knees.

    • The next issues are likely to be gigantic class action cases which might bring a car company to its knees.

      Don't worry, they are too big to fail. The Government will bail them out once again.

  • by schwit1 ( 797399 ) on Sunday August 14, 2016 @11:17AM (#52700005)
    ... of which manufacturers take vehicle systems' security seriously and which don't?
  • Cars were never built to be secure. Not one of these hackable technology issues is anywhere near as dangerous as all of the other dangers that have always existed for moving vehicles.

    Some thought experiments for you:

    imagine taking a handful of ball-berrings, and tossing them off of a bridge over a busy high-speed highway.

    imagine, late at night, grabbing a paint brush and some yellow/white paint, and "adjusting" the lane markings on the empty-but-will-be-busy-come-morning-rush-hour road.

    imagine, driving a r

    • by pem ( 1013437 )
      Most of your examples are not targeted, and most of the rest will leave tell-tale evidence.

      Some of the new exploits can be precisely targeted and presumably leave very little evidence.

  • If I wanted to promote a security consulting business, I could identify a niche of that market and make up a bunch of stats for that market that show a need and enough people might buy into what I wrote that I could get some consultancy business.

    The IOActive white paper seems to be a security analysis based on a review of other works, not work that they did themselves. The number are estimates based on their analysis, not measurement of real world vulnerabilities.

    Connected cars are likely full of secur

    • If I wanted to promote a security consulting business, I could identify a niche of that market and make up a bunch of stats for that market that show a need and enough people might buy into what I wrote that I could get some consultancy business.

      This is why every single scrap of "white papers," "studies" and "recommendations" from every single research group or "Think Tank" should automatically be suspect and raise the questions of "Who paid for this?" and "Who benefits from this?"

      Follow the money, and you'll find the benefactor.

  • by account_deleted ( 4530225 ) on Sunday August 14, 2016 @07:43PM (#52701849)
    Comment removed based on user account deletion
  • Every software team has to prioritize bug fixes, including security vulnerabilities. When deciding which ones to fix first, every team considers factors such as:
    - severity - how costly is the damage that occurs from the problem?
    - frequency - how often does it happen, or how often is it likely to happen?
    - cost - how much does it cost to fix?

    If a bug is really severe (bricks your device) but it happens only once for each 100 million installations, it might not be worth the effort to fix it.

    I think the author

  • I'm not familiar with "hair on fire". Is that a higher priority than "lp0 on fire"? Does it notify via Morse code on the SES light? Is the code a P number, or ASCII?

  • Sure, the AC and power steering are down, and it stalls when starting on a hill, but at least it isn't hackable!

    That said, if anyone wants to buy me a hackable car, I won't refuse it.

You know you've landed gear-up when it takes full power to taxi.

Working...