4 ms·

It doesn't matter if it's the infotainment system so long as it's connected to the rest of the electronics. Yes, hacks have already exploited critical vehicle c

It doesn't matter if it's the infotainment system so long as it's connected to the rest of the electronics. Yes, hacks have already exploited critical vehicle controls via Internet infotainment systems. So long as vehicle manufacturers do not physically separate the electronics, such vulnerabilities will surface. Currently, the standard practice is to build out the electronics for a vehicle as a single system.

noselasd 11y ago
I'd rather wait until your claims of security issues and remote hacks are verified for the particular vehicle here. All of this is just crying wolf so far.
- nitrogen 11y ago
  Remote-drive vulnerabilities have been demonstrated in infotainment systems, proving that the class of vulnerabilities is real. There's no need to prove it can happen for every single vehicle to be concerned about general best practices.
  - noselasd 11y ago
    Yes there is. If this system have no write ability onto the relevant CAN-bus, the class of vulnerability you talk about (which comes from the Jeep hack) does not exist. But sure - best practices should be followed.
kaftoy 11y ago
> Currently, the standard practice is to build out the electronics for a vehicle as a single system. What do you mean by this? The car itself is a single unit so you can assume the electronics inside communicate at some level (CAN networks usually), but the electronics are separated. You have a control unit for the engine, another one for the ABS, another for the gearbox and many others for various body control functions. Some of them communicate with each other over the CAN, but only transmit/receive messages of particular interest. For example, the ABS unit in some cases tells the engine control unit the vehicle speed. The engine control unit transmits the engine RPM to the body control unit for obvious reasons. The same for the anti-theft mechanism. To the subject: Having outdated drivers in production level software is common practice. During final validation of the SW, before start of production, if some drivers are found outdated (even declared invalid by the driver/package owner), people do not jump to upgrade immediately. It undergoes a process of analysis: is there any critical bug which the new version fixes? Does it impact the current project configuration? If not, why upgrade? You run the risk of introducing a regression => requires extra validations which can take weeks or months. Nobody will approve that just to fix some bug without functional impact in that particular system. So when you claim that a certain package has to be updated to the latest version, you have to come up with arguments. "Newest is always better" does not count. There are countless examples when newer versions of some piece of SW fixed some bug but broke something that was working. SW updates after the majority of the validation process is finished happens only on a NEED TO HAVE basis.

noselasd 11y ago

I'd rather wait until your claims of security issues and remote hacks are verified for the particular vehicle here. All of this is just crying wolf so far.

nitrogen 11y ago
Remote-drive vulnerabilities have been demonstrated in infotainment systems, proving that the class of vulnerabilities is real. There's no need to prove it can happen for every single vehicle to be concerned about general best practices.
- noselasd 11y ago
  Yes there is. If this system have no write ability onto the relevant CAN-bus, the class of vulnerability you talk about (which comes from the Jeep hack) does not exist. But sure - best practices should be followed.

kaftoy 11y ago

> Currently, the standard practice is to build out the electronics for a vehicle as a single system. What do you mean by this? The car itself is a single unit so you can assume the electronics inside communicate at some level (CAN networks usually), but the electronics are separated. You have a control unit for the engine, another one for the ABS, another for the gearbox and many others for various body control functions. Some of them communicate with each other over the CAN, but only transmit/receive messages of particular interest. For example, the ABS unit in some cases tells the engine control unit the vehicle speed. The engine control unit transmits the engine RPM to the body control unit for obvious reasons. The same for the anti-theft mechanism. To the subject: Having outdated drivers in production level software is common practice. During final validation of the SW, before start of production, if some drivers are found outdated (even declared invalid by the driver/package owner), people do not jump to upgrade immediately. It undergoes a process of analysis: is there any critical bug which the new version fixes? Does it impact the current project configuration? If not, why upgrade? You run the risk of introducing a regression => requires extra validations which can take weeks or months. Nobody will approve that just to fix some bug without functional impact in that particular system. So when you claim that a certain package has to be updated to the latest version, you have to come up with arguments. "Newest is always better" does not count. There are countless examples when newer versions of some piece of SW fixed some bug but broke something that was working. SW updates after the majority of the validation process is finished happens only on a NEED TO HAVE basis.