On Sunday, 6 January 2019 14:16:38 PST Roland Hughes wrote: > > And those devices still have an input mechanism: their scanner ports. It's > > possible to send malformed data to their I/O pins to cause an exploit. > > Heck, it's theoretically possible to do that with the scanning head > > itself: paint your chest with some pattern in UV and when you go for a > > tomography, bam! the device gets hacked. Remember how the iPhone 1 was > > jailbroken by a 1x1 pixel TIFF image opened in the Safari browser? > > I have no idea what you are speaking of here. Perhaps it is from a part > of the medical device world I've never worked in. None of the devices > I've worked with have exposed I/O pins.
They don't need to be exposed directly for data to be sent to them. The medical devices have probes, image and video acquisition, etc. You can hack through those. Granted, this would be a terribly difficult hack and the hacker would be right there visible to everyone, but it's theoretically possible. > Even the patient monitor I > worked on had to have electrical protection so if someone stabbed the > thermometer into a wall outlet the current would never get to a patient > hooked to one of the other leads. That's an electrical DoS, not what I am talking about. > Perhaps I've just been lucky, but every device I've worked on to date > has had isolated components which communicate via a message queue. The > message queue only supports a limited number of serialized messages > (usually serialized COOA messages with fixed length fields.) If a stream > of garbage came in from a replaceable component, the stream would be > ignored by the message queue and an alarm sounded. Even the USB ports > I've seen on them will not communicate with an off-the-shelf keyboard, > mouse, thumb drive, or insert USB device here. Only a limited set of > custom devices could connect in any way. But there's a higher layer that parses the messages that were received. My point is that a suitably crafted message could trigger an exploit / DoS in the device. And again, you don't need access to the bytes to send that message, you can do it by causing the actual capture device generate them. > This is a bit of a misconception. A company isn't allowed to "update" > it's tool set without going through the full development process of > creating all of the documentation, getting approval, complete test set, > etc. The required QA process can be shorter, depending on the scope of > the change. A fix to correct a memory leak in a core tool like say, some > Qt class, could theoretically get through in months. Changing out a tool > like, say, "updating" from Qt 4.8 to 5.9 is treated as a new product. > Some companies may be able to get that treated as just an "enhancement" > but, generally it is viewed and treated as a new replacement product for > an existing product. Even with an accelerated approval process you will > be looking at a year or more from the time you start and several million > dollars spent. I do understand you. > > Maybe the IoT surgical robot is not a 2019 technology, but there are > > plenty of other IoT ones that are. Those MUST update. Frequently. For > > those, if you're not able to deploy a fix within one week, do us all a > > favour and don't sell your device. > > Should I assume that last statement was directed at Google and Android? > <Grin> No, since Android does actually have an update cycle and Google's own Android devices get those updates very quickly. Apple is good too. They don't update every week, but they have the ability to do so if required. No, it's aimed at everyone else, those who take months or a year to update, if at all. Whether it's running Android, Tizen, WebOS or a custom-built Linux (using Yocto Project or not) is not important. > Automatic updates sound good, but we've all been on the other side of > them. One client site I was at recently pushed out Windows 10 updates to > their fleet of ThinkPad T440s laptops which bricked them. Their tech > support team didn't even blink when I turned the machine in. Every time > they push out updates a percentage of the machines in the field brick. > They didn't even waste much time testing them before pushing out another > batch because it always happened. On the other hand, millions of iPhones update in the first week of Apple releasing their iOS updates. So it is possible to do that, especially if you control the hardware and know exactly what's on the device. Laptops and desktops are clearly more difficult, but we're talking about IoT here. > How many of us have left automatic updates turned in in our routers only > to come in one day to learn some or all were no longer working thanks to > an update? I have, that's why my routers are set to manual update now. Never had an update problem with OpenWRT. All config settings persist after sysupdate; I just need to install more packages that don't come with the image. Well, that was until I learned to use the image builder tool these holidays... > Having said all of this, I agree, IoT is going to be a train wreck hit > by a plane crash which rolls down hill into a daycare center during > afternoon play. :-) > Many of those devices have no ability to patch > themselves or be patched by a non-technical user. Lots of "new" products > being sold on eBay and other places which only list Android as their OS, > not the version. One has to go digging into other sources with the model > number and date of manufacture to learn they are still running, in some > cases, cupcake. These machines will just keep moving from home to home > with whatever exploit installed on them. Right. Those are the ones I am kindly asking the manufacturer to not sell at all. If you don't have a full ifecycle update plan, don't sell. That may be as little as 2 years until obsolescence, but it can be 10 or 15 years. If I don't get an update after 2 years, my smart fridge will be 2 years smart and 13 years a dumb fridge I overpaid. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
