|
You're crazy, but the good kind of crazy.
|
#
¿
May 3, 2015 07:16
|
|
|
|
| # ¿ May 12, 2024 03:05 |
|
|
 *click*Seriously though superstition is stupid and that's an awesome looking car. Hope they did actually fix the problems.
|
|
#
¿
May 4, 2015 00:08
|
|
|
Enourmo posted:Normally I'd agree, but have you seen this guy's car history? Of course, why else would I subscribe? It's gonna be good one way or another.
|
|
#
¿
May 4, 2015 00:40
|
|
|
CAT INTERCEPTOR posted:You most certainly can in older cars. quote:You again missed the point what I am getting at. The fact that that poo poo is BY WIRELESS able to be accessed should just never of happened. I can accept that such system can be accessed via the physical ODB port. But by loving wireless?!?!!? This shows a level of interconnect on CANBUS that just should never of happened at all. This is a fundamental design flaw that any dickhead could have seen would be exploited. mattfl posted:The GPS in my nav/infotainment unit can send the GPS data to the small cluster in my dash panel which also displays all kinda info about the actual Jeep(tire pressure, oil change info/etc), so I'm not sure if having it on separate networks would still allow that. My old E46 BMW has the entertainment and comfort systems on one network called I-Bus. The critical drive systems are on another similar network called K-Bus. The worst someone could do with access to the I-Bus is crank the radio and lower the windows. Supposedly one could also control the lights, but I never got that working when I was messing around with it. Cruise control and other safety-critical systems aren't available to the radio no matter what. IIRC the instrument cluster is attached to both networks, but is specifically designed to act as a restrictive gateway rather than providing raw access. This is a lot like all that software that needed a redesign when Windows Vista/7 came around and no longer allowed access to everything by default. Most software didn't actually need that access, but because they had it they took the lazy way out and ended up creating a security nightmare in the process.
|
|
#
¿
Jul 22, 2015 15:54
|
|
|
Z3n posted:While you can absolutely design secondary networks, firewall, segment, etc, all of these things are still subject to the same core problem that we build these systems with stacks of code on code on code that no individual has evaluated or understands as a comprehensive whole. There are only a tiny minority of folks who could be reasonably trusted to write secure code, fewer who can securely architect systems in a way that meets business goals, and the number of those people who are not currently employed by the tech or gov sectors is basically zero - baseline salary for these people is in the hundreds of thousands of dollars plus likely millions in stock, and I don't think the auto industry is at the point where they're ready to pay that kind of money, nor would they see the value in it. Some of these things are simple to implement if someone bothers to rub a few brain cells together. One-way data links for example. Almost any type of network connection that supports broadcast traffic (or is always effectively broadcast as is the case in a lot of bus-type networks) can be made one-way by simply not hooking up the transmitter on the insecure end (or the receiver on the secure end, depending on which is easier). Ethernet, K-Bus, CAN, the principle works the same on all of them. You don't need rocket scientists, just an awareness of the problems and a bit of caution. For situations where two-way communication is required it gets a bit harder, but it's still not that big of a deal. In whatever addressing format your network of choice uses, make sure everything the insecure devices need to talk to are within a certain range that can be masked. Put a hardware device in the path that filters any traffic not matching that mask. All "secure" endpoints for example could be put in the top end of the address range, so any traffic from the insecure side with the first bit of the address set to 1 gets dropped. Basically the people designing these systems should really just have a meeting with their corporate overlords' network security team. A one-way link is almost the same as a passive network tap (commonly used for intrusion detection systems or network troubleshooting), and bitmask-based address filtering is one of the simplest tasks a hardware firewall does. No one needs to be an expert in security, they just need to think about it in the slightest. Putting an internet connected computer directly on the chassis bus as shown in the images IOC posted is not even trying.
|
|
#
¿
Jul 22, 2015 20:28
|
|
|
|
| # ¿ May 12, 2024 03:05 |
|
|
Space Gopher posted:A fully air-gapped system would work, but a major bug would mean either a massively expensive recall, or a coverup. So, why not integrate them into the same system that handles the radio/nav/whatever, that has a firmware update mechanism built in? A dealership tech can quietly update it with a cable in the dash, as part of normal service that also fixes radio bugs and updates the nav map. The recall bill in the billions just got shaved to a tiny fraction of that cost. There's a happy medium in there which would be secure enough that most should be comfortable with it while still allowing such updates to be delivered remotely. Require the car be "booted" to an update mode before critical components can have their firmware updated. Use physical switch, a "cheat code" entered in via inputs like brake and gas that live on the "secure" network, a special command sent over the OBD2 port, whatever. Make it so the car won't start in this mode to prevent idiots from just leaving it enabled and have it control the write protect lines on the actual flash chips. If a critical component update is required the manufacturer can release it along with instructions on how to enable the update mode. A lot of people will be able to do it themselves, and for those that can't it now doesn't need to take up any skilled service tech time. Any random employee with a USB key can do the job. These are not unsolvable problems, they're not even really hard problems and they've been solved a number of times in different applications, just as with so many other things relating to digital security it's a matter of getting the right people to care when there's always pressure to get the product released yesterday.
|
|
#
¿
Aug 17, 2015 03:24
|
|