4 ms·

IoT devices effectively run on microcontrollers and their security is usually even worse than PC class hardware/software. :P

Syonyk 5y ago
Not really. They run small embedded processors, but most IoT hardware is running a full Linux, for the sake of pushing a bit of data to some cloud server, and receiving responses. Just because you can do it in Python running with a full Linux stack behind things doesn't mean you should. A lot of that sort of stuff can be done with a far smaller microcontroller, preferably Harvard architecture, with a memory safe language - I'm not exceedingly familiar with it, but Rust shows a lot of promise for this type of work. Very, very limited functionality, and the minimum amount of hardware/software to make it work. Aggressive code reviews, fuzzing, etc, before deployment. It's literally the opposite of how most "things" are deployed, but it reduces the attack surface rather significantly. It does make updates harder, depending on how one implements it, but if it's properly done in the first place, this isn't a big problem. I absolutely despise the "Ship first, correct it later!" approach to software that has taken over literally everything these days. Yes. Great. Tesla was able to OTA update the brake controller for the Consumer Reports Model 3 and fix the braking - and nobody gets around to asking how on earth they shipped a near-production car to a review agency with broken brake control firmware in the first place. That's the sort of thing that should be tested, correct, and immutable after shipping. I'm not comfortable with trusting Silicon Valley companies to properly OTA update the brake firmware on my car, I'd rather it ship with working brakes that remain unchanged for the life of the vehicle. I'm aware this is totally at odds with the modern software ecosystems, and that's entirely deliberate. I do not like what modern software has become.
- d110af5ccf 5y ago
  To be fair, there's some nuance to be had here. OTA updates for cell phone firmware probably make a fair amount of sense. A mobile game shipping quickly and fixing things up later is likely financially favorable and it's not as though I can't find something else to do with my time if the devs inadvertently break it. OTA updates for brake control firmware, however, is an absolutely terrifying reality that should probably be made outright illegal in the first place. It creates a centralized attack vector of alarming scope that would never have existed otherwise. I get it, there's a CAN bus and diagnostics and now it's all hooked up to the mobile network for data collection and analysis purposes. That doesn't justify any of the essential systems attached to the bus being able to receive data though. Outside of direct physical access (ie plugging in a cable), safety critical systems should be broadcast only unless an incredibly compelling reason exists to do otherwise.
endymi0n 5y ago
That, and you just didn't just go to a system that's hard to attack, but also hard to develop for. Can you write software for that microcontroller in C? Sure, although you'd probably prefer Rust. Now if you managed to find someone with a low salary who'd put up with writing screen software for a train, try telling them there's not just no Java, but no Heap and that they'd have to connect to the GPS chip via serial instead of having OS managed location. And then they'd have to integrate the streaming MP4 video for the advertisements on their own, without a filesystem or FFMPEG. Haha, not gonna fly. No product manager in their right mind would greenlight that effort for "security reasons" if it suddenly takes 100x the amount of effort then. We're using operation systems for the features they provide and the ease of development (as well as debugging) they enable, that's the answer.

Syonyk 5y ago

Not really. They run small embedded processors, but most IoT hardware is running a full Linux, for the sake of pushing a bit of data to some cloud server, and receiving responses. Just because you can do it in Python running with a full Linux stack behind things doesn't mean you should. A lot of that sort of stuff can be done with a far smaller microcontroller, preferably Harvard architecture, with a memory safe language - I'm not exceedingly familiar with it, but Rust shows a lot of promise for this type of work. Very, very limited functionality, and the minimum amount of hardware/software to make it work. Aggressive code reviews, fuzzing, etc, before deployment. It's literally the opposite of how most "things" are deployed, but it reduces the attack surface rather significantly. It does make updates harder, depending on how one implements it, but if it's properly done in the first place, this isn't a big problem. I absolutely despise the "Ship first, correct it later!" approach to software that has taken over literally everything these days. Yes. Great. Tesla was able to OTA update the brake controller for the Consumer Reports Model 3 and fix the braking - and nobody gets around to asking how on earth they shipped a near-production car to a review agency with broken brake control firmware in the first place. That's the sort of thing that should be tested, correct, and immutable after shipping. I'm not comfortable with trusting Silicon Valley companies to properly OTA update the brake firmware on my car, I'd rather it ship with working brakes that remain unchanged for the life of the vehicle. I'm aware this is totally at odds with the modern software ecosystems, and that's entirely deliberate. I do not like what modern software has become.

d110af5ccf 5y ago
To be fair, there's some nuance to be had here. OTA updates for cell phone firmware probably make a fair amount of sense. A mobile game shipping quickly and fixing things up later is likely financially favorable and it's not as though I can't find something else to do with my time if the devs inadvertently break it. OTA updates for brake control firmware, however, is an absolutely terrifying reality that should probably be made outright illegal in the first place. It creates a centralized attack vector of alarming scope that would never have existed otherwise. I get it, there's a CAN bus and diagnostics and now it's all hooked up to the mobile network for data collection and analysis purposes. That doesn't justify any of the essential systems attached to the bus being able to receive data though. Outside of direct physical access (ie plugging in a cable), safety critical systems should be broadcast only unless an incredibly compelling reason exists to do otherwise.

endymi0n 5y ago

That, and you just didn't just go to a system that's hard to attack, but also hard to develop for. Can you write software for that microcontroller in C? Sure, although you'd probably prefer Rust. Now if you managed to find someone with a low salary who'd put up with writing screen software for a train, try telling them there's not just no Java, but no Heap and that they'd have to connect to the GPS chip via serial instead of having OS managed location. And then they'd have to integrate the streaming MP4 video for the advertisements on their own, without a filesystem or FFMPEG. Haha, not gonna fly. No product manager in their right mind would greenlight that effort for "security reasons" if it suddenly takes 100x the amount of effort then. We're using operation systems for the features they provide and the ease of development (as well as debugging) they enable, that's the answer.