38 ms·

Interesting: BMW did share the OSS they used, and in the process they also revealed lots of outdated packages in use. This of course leads me to wonder: Vulnera

Interesting: BMW did share the OSS they used, and in the process they also revealed lots of outdated packages in use. This of course leads me to wonder: Vulnerabilities? It is after all an Internet-connected vehicle. Despite the article author's recognition given for BMW's OSS compliance, I am dismayed to see yet another example of likely inconsideration given toward implementation of security in the engineering of an Internet-connected vehicle. This sort of negligence is eventually going to result in some rather ugly outcome.

Sanddancer 11y ago
From the looks of it, they used the OSes the chipmakers provide in their reference packages. The stlinux stuff seems ripped pretty much verbatim from stlinux 2.4 [0] and the rest seems to be from Freescale/NXP's reference linux for their i.MX series [1]. Automakers, like a lot of other entities, rarely make their own distros themselves, but rather tend to use the reference OS provided by the chipmakers. [0] ftp://ftp.stlinux.com/pub/stlinux/2.4/ [1] http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors/i.mx53-processors/embedded-linux-for-i.mx-applications-processors:IMXLINUX?code=IMXLINUX&nodeId=0150522FC8ZrDR988D&fpsp=1&tab=Design_Tools_Tab http://www.nxp.com/products/microcontrollers-and-processors/...
- suzeanne 11y ago
  Excellent reply. Indeed, quite true. Though none of this excuses any negligence, no matter if it is the vendor of the manufacturer.
- cmurf 11y ago
  With software this old, there certainly are vulnerabilities, probably full on exploits available, that have also long since been patched. The attack surface of new products using old software is much higher than it ought to be. And consider not is it in need of updating before it's being driven off the lot, it's likely to have service updates for a time frame shorter than its useful service life. We're doing this wrong.
  - xyzzy_plugh 11y ago
    You'd be surprised at the amount of effort to apply upstream patches or fixes to older vendor software. Many vendors also maintain older forks indefinitely. I've spent an inhumane amount of time applying/porting modern security fixes to ancient codebases. The root of the problem is: you buy a part, and to use the part you need some software to talk to it. The vendor, along with the part, supplies you with some sample code, which uses some ancient kernel and ancient GPLv2 utilities. If you use their code, then you perpetuate the problem. If you choose not to, then they won't help you when you have issues. Why do vendors use such ancient software? Vendors care deeply about their IP, and to some extent tivoization does happen with individual products, but more usually through obfuscation. Not a whole lot of open firmware for wireless chipsets, is there? Customer demand can change things, but vendors are afraid of their customers stealing their technology, and taking it to a cheaper competitor, or building it themselves. This stuff happens all the time. So they give you some code that talks some foreign language to their part or give it a seemingly black box blob of code to run and suddenly it's a black box to you too. Patents (for hardware), and China's lack of concern for IP theft are the root of all of this.
    - adrianratnapala 11y ago
      I think there is something more primal going on too. Vendors might at some time chose to say "freeze" and now we will just deliver this same binary blob, or at best generate new binary blobs from an ancient source stack we have under version control. Making changes means, at best, going through an expensive testing procedure. At worst, there is no such procedure and all change is an anethema. So they only make changes when they have to, and as the cost of staying obsolete increases, so does the cost of becoming up to date.
      - xyzzy_plugh 11y ago
        I tend to agree, but remember that for many vendors providing code that doesn't run/isn't tested on some LTS kernel means no one will use it. Or, you'll incorporate the vendor delivering support as part of the deal. Many times I've spent late nights babysitting an employee from $VENDOR debugging/fixing/rewriting their driver to play nice with our stack.
hkmurakami 11y ago
On the hardware side, the product development cycle for a car is about 5 years, which design lockins in stages along the way (there's a mad rush for a "land grab" for engine compartment space by suppliers many years in advance to the actual launch of the car). It wouldn't surprise me if the software had a similarly long development and lock-in cycle.
a3n 11y ago
Total guess: as a regulated company, they may have to get approval for their code, which would include validated versions of 3rd party code. If they have to go through that with any new version of 3rd party code, they may not want to make that effort.
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
- suzeanne 11y ago
  Well, the first time a hacker vehicle exploit results in one or more deaths of the driver and/or passengers of one of these Internet-connected vehicles, it's going to be all over the news. Right around then... and when the lawsuits hit, some execs/directors are going to realize that such effort is far less costly than the PR disasters that can unfold when corners are cut. I mean, obviously some people at Volvo thought that actual emissions compliance was far too costly to bother with --and that didn't even result in a vehicle accident or personal injury. Certainly their bottom line has had a major impact as a result. The potential for PR disaster with Internet-connected vehicles is certainly much more concerning. The inevitability of some such future tragedy and resulting media-fueled PR disaster for one or more vehicle manufactures is a certainty. It's only a matter of when and which vehicle manufacturer(s) will be liable. When that happens, I’m certain that such sizable companies can figure out how to streamline the approval process with whatever regulatory bodies might be involved, or they’ll just learn to live with the pain… for being for less than the much greater pain of a PR disaster.
  - ChristianBundy 11y ago
    > Well, the first time a hacker vehicle exploit results in one or more deaths of the driver and/or passengers of one of these Internet-connected vehicles, it's going to be all over the news. Michael Hastings, anyone?
  - Animats 11y ago
deathanatos 11y ago
> Despite the article author's recognition given for BMW's OSS compliance, I am dismayed to see yet another example of likely inconsideration given toward implementation of security in the engineering of an Internet-connected vehicle. I hear you, but isn't this one of the reasons for wanting compliance around the (L)GPL? It allows us, the owners of the vehicle and users of the software to make that inspection, and hopefully, patch the vulnerabilities in the software, right? (I believe one of the provisions of the LGPL is that it must be possible to replace the LGPL'd software with a different version — this is why most software dynamically links to LGPL libraries: it allows the .so/.dll to be "simply" swapped out for a different one.)
- bonzini 11y ago
  Unless you're using v3 of the LGPL, the provision only extends towards providing separate object files for the program (if statically linked) or separate shared library files for the library (if dynamically linked). It is pretty much useless if you have no means to install a modified binary.
intrasight 11y ago
Open-source vulnerabilities are much less scary than closed-source vulnerabilities.
- datashaman 11y ago
  only if the code is updated.

Sanddancer 11y ago

From the looks of it, they used the OSes the chipmakers provide in their reference packages. The stlinux stuff seems ripped pretty much verbatim from stlinux 2.4 [0] and the rest seems to be from Freescale/NXP's reference linux for their i.MX series [1]. Automakers, like a lot of other entities, rarely make their own distros themselves, but rather tend to use the reference OS provided by the chipmakers. [0] ftp://ftp.stlinux.com/pub/stlinux/2.4/ [1] http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors/i.mx53-processors/embedded-linux-for-i.mx-applications-processors:IMXLINUX?code=IMXLINUX&nodeId=0150522FC8ZrDR988D&fpsp=1&tab=Design_Tools_Tab http://www.nxp.com/products/microcontrollers-and-processors/...

suzeanne 11y ago
Excellent reply. Indeed, quite true. Though none of this excuses any negligence, no matter if it is the vendor of the manufacturer.
cmurf 11y ago
With software this old, there certainly are vulnerabilities, probably full on exploits available, that have also long since been patched. The attack surface of new products using old software is much higher than it ought to be. And consider not is it in need of updating before it's being driven off the lot, it's likely to have service updates for a time frame shorter than its useful service life. We're doing this wrong.
- xyzzy_plugh 11y ago
  You'd be surprised at the amount of effort to apply upstream patches or fixes to older vendor software. Many vendors also maintain older forks indefinitely. I've spent an inhumane amount of time applying/porting modern security fixes to ancient codebases. The root of the problem is: you buy a part, and to use the part you need some software to talk to it. The vendor, along with the part, supplies you with some sample code, which uses some ancient kernel and ancient GPLv2 utilities. If you use their code, then you perpetuate the problem. If you choose not to, then they won't help you when you have issues. Why do vendors use such ancient software? Vendors care deeply about their IP, and to some extent tivoization does happen with individual products, but more usually through obfuscation. Not a whole lot of open firmware for wireless chipsets, is there? Customer demand can change things, but vendors are afraid of their customers stealing their technology, and taking it to a cheaper competitor, or building it themselves. This stuff happens all the time. So they give you some code that talks some foreign language to their part or give it a seemingly black box blob of code to run and suddenly it's a black box to you too. Patents (for hardware), and China's lack of concern for IP theft are the root of all of this.
  - adrianratnapala 11y ago
    I think there is something more primal going on too. Vendors might at some time chose to say "freeze" and now we will just deliver this same binary blob, or at best generate new binary blobs from an ancient source stack we have under version control. Making changes means, at best, going through an expensive testing procedure. At worst, there is no such procedure and all change is an anethema. So they only make changes when they have to, and as the cost of staying obsolete increases, so does the cost of becoming up to date.
    - xyzzy_plugh 11y ago
      I tend to agree, but remember that for many vendors providing code that doesn't run/isn't tested on some LTS kernel means no one will use it. Or, you'll incorporate the vendor delivering support as part of the deal. Many times I've spent late nights babysitting an employee from $VENDOR debugging/fixing/rewriting their driver to play nice with our stack.

hkmurakami 11y ago

On the hardware side, the product development cycle for a car is about 5 years, which design lockins in stages along the way (there's a mad rush for a "land grab" for engine compartment space by suppliers many years in advance to the actual launch of the car). It wouldn't surprise me if the software had a similarly long development and lock-in cycle.

a3n 11y ago

Total guess: as a regulated company, they may have to get approval for their code, which would include validated versions of 3rd party code. If they have to go through that with any new version of 3rd party code, they may not want to make that effort.

deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
suzeanne 11y ago
Well, the first time a hacker vehicle exploit results in one or more deaths of the driver and/or passengers of one of these Internet-connected vehicles, it's going to be all over the news. Right around then... and when the lawsuits hit, some execs/directors are going to realize that such effort is far less costly than the PR disasters that can unfold when corners are cut. I mean, obviously some people at Volvo thought that actual emissions compliance was far too costly to bother with --and that didn't even result in a vehicle accident or personal injury. Certainly their bottom line has had a major impact as a result. The potential for PR disaster with Internet-connected vehicles is certainly much more concerning. The inevitability of some such future tragedy and resulting media-fueled PR disaster for one or more vehicle manufactures is a certainty. It's only a matter of when and which vehicle manufacturer(s) will be liable. When that happens, I’m certain that such sizable companies can figure out how to streamline the approval process with whatever regulatory bodies might be involved, or they’ll just learn to live with the pain… for being for less than the much greater pain of a PR disaster.
- ChristianBundy 11y ago
  > Well, the first time a hacker vehicle exploit results in one or more deaths of the driver and/or passengers of one of these Internet-connected vehicles, it's going to be all over the news. Michael Hastings, anyone?
- Animats 11y ago

deathanatos 11y ago

> Despite the article author's recognition given for BMW's OSS compliance, I am dismayed to see yet another example of likely inconsideration given toward implementation of security in the engineering of an Internet-connected vehicle. I hear you, but isn't this one of the reasons for wanting compliance around the (L)GPL? It allows us, the owners of the vehicle and users of the software to make that inspection, and hopefully, patch the vulnerabilities in the software, right? (I believe one of the provisions of the LGPL is that it must be possible to replace the LGPL'd software with a different version — this is why most software dynamically links to LGPL libraries: it allows the .so/.dll to be "simply" swapped out for a different one.)

bonzini 11y ago
Unless you're using v3 of the LGPL, the provision only extends towards providing separate object files for the program (if statically linked) or separate shared library files for the library (if dynamically linked). It is pretty much useless if you have no means to install a modified binary.

intrasight 11y ago

Open-source vulnerabilities are much less scary than closed-source vulnerabilities.

datashaman 11y ago
only if the code is updated.