Slashdot Mirror
The Coming IT Nightmare of Unpatchable Systems
snydeq (1272828) writes "Insecure by design and trusted by default, embedded systems present security concerns that could prove crippling if not addressed by fabricators, vendors, and customers alike, InfoWorld reports. Routers, smart refrigerators, in-pavement traffic-monitoring systems, or crop-monitoring drones — 'the trend toward systems and devices that, once deployed, stubbornly "keep on ticking" regardless of the wishes of those who deploy them is fast becoming an IT security nightmare made real, affecting everything from mom-and-pop shops to power stations. This unpatchable hell is a problem with many fathers, from recalcitrant vendors to customers wary of — or hostile to — change. But with the number and diversity of connected endpoints expected to skyrocket in the next decade, radical measures are fast becoming necessary to ensure that today's "smart" devices and embedded systems don't haunt us for years down the line.'"
They had the same problem prior to the year 2000, so why wasn't this lesson already learned?
Feed the need: Digitaladdiction.net
Wait until we have driverless cars on the road. But I'm sure they'll all be bullet-proof secure, don'tcha think?
Well, that would be less of a problem if you didn't surf SlashDot using your refrigerator or crop-monitoring drone...
"Poorly designed", or "incorrectly designed" - perhaps. I'm fairly sure that even the ATM designers who went with an embedded MicroSoft operating system felt that they had mediated security risks adequately to deploy their systems. Incidentally, I had a chance to peek inside a local casino's slot machines - all of them, regardless of external appearance were based on an identical piece of hardware. Watching them boot showed me a MicroSoft OS underlying those slots. Not a problem, as I'm fairly certain that none of the slot machines on the floor have any conceivable way of ever connecting directly to any network except for the dark wire casinos use for exactly this purpose.
My takeaway point is that the summary is (IMHO) slightly biased. The original article appears to be well written. Just to ask - how many embedded systems should be permitted to ever connect to the internet? ATM's, for example, should demonstrably be either confined to a darknet or (as I've seen in some places) required to use dialup access. It's not perfect, but it adds a significant obstacle for crackers to overcome. The casino I mentioned earlier seems to get this point.
I don't mind smart appliances - but again, I don't see why they need internet access. The exceptions to this (smart TV's, for example) should be viewed with suspicion specifically because they are likely to be connected to the internet in some way, but my smart refrigerator probably shouldn't be - and ATM's, slot machines, SCADA systems, etc. almost certainly should never be.
"Unpatchable" does not mean "Unsecured" in fact, I'd say it adds to security in many senses. A system that can't be patched, can also not be altered to do the attackers bidding. At the very least, any privileges the attacker may have access to can not be elevated to create some even worse situation. Worst case scenario you just disconnect power to the device in question. Submit it for warranty repair. If you're using a closed source software product out of warranty/support it's your own stupid fault.
You know, I'll bet if you fixed your hosts file...
There are two bleeding edges. One is the leading edge of cutting technology.
There other is the trailing edge where systems age out because they take a lot of effort to update.
One way the trailing edge can not be updated because the overall system is designed to where there are critical parts that can not be monkeyed with in a low risk scenario. (This does happen).
The other option on the trailing edge is where the systems are not worth the effort. Most of the Internet of Everything appliances really have zero income after the first few months and yet are expected to have a longer lifetime than many major IT infrastructure requirements.
Make them patchable over the internet by default.
Oh, wait...
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
The overall level of system quality is so piss poor anyway what does it matter than your toaster is going to try to kill Sarah Connor? Anyone read the news recently? Car makers recalled about eleventy zillion cars recently and half the problems were on board computer based. Are you going to lose any sleep that your refrigerator will get hacked and join Skynet? Because the real problem is going to be that when your Refrigerator blows an 80 cent part on a 2 dollar circuit board it's going to cost $1100 to 'repair'.
Probably not unless the user wants it fixed, and most don't. People have plenty of experiences with patches breaking new things, or taking away old functionality they had come to depend on. When someone tells me "this patch will solve all your problems", they usually aren't advertising the list of new problems they're creating for me. Anyone who plays iPhone app games knows that the patches sometimes come with game-stopping bugs; other patches have been known to suddenly add annoying advertising.
Usually, I'm at a point of equilibrium where I am at least coping with the bugs in the devices surrounding me. If I know that the "mute button" on my GoogleTV box doesn't work unless I press it twice, I simply learn to press it twice; while I know it's a stupid workaround, it's one I can live with. What I might not be able to live with are the bugs that come with the next round of patches.
Now, we make that experience hurdle even harder to scale: as a end user, I think security patches are worse than regular patches. The end user doesn't see a physical benefit from the patches, but knows he might suffer. What does he care if his thermostat or washing machine is sending spam around the world, as long as his house is warm and his clothes are clean? But if he installs the patches, he risks having a cold house or dirty clothes, or even advertisements streaming across his refrigerator's screen. It's just not worth the risk to patch them.
And if you want to see a really risk-averse, don't-patch-me crowd, talk to the SCADA industrial control people. If you suggest you need to update the software running the sewage ejection pump, the city engineer is going to hand you an invoice for $20,000 and say "that covers my cost of testing your patch."
John
Well as an Embedded System Designer I have to speak up here, systems are usually not insecure because of lazy development, systems are insecure because clients, managers and stakeholders don't provide proper funding, deadlines or requirements. The number of times I've had to go to a manager or project manager and ask them to clarify a customers request is almost sad. The amount of times I've had to go to the same group and ask for twice or three times the amount of time to develop a solution is almost sad and the amount of times I've had to ask for much more funding to do a proper job is sad. For some unknown reason embedded designers aren't treated like normal software developers and the truth is we aren't. We don't rely on some insecure patched to hell OS to keep us safe and we don't trust laughable memory managers and kernels to keep us crash free and running smooth. We do the real work in the development world and generally it's the GUI designer who takes the credit.
We generally don't work in the world of garbage collected and managed languages, we don't work in the world where everything is already setup and ready to be called through some piss poor abstracted class implementation of system.IO and we don't get safety nets under us to catch what falls through in some kind of completely illogical and messed up exception error system ( C# ). To say embedded systems are insecure is really another way to say one of several things:
1. You didn't allocate enough time, money or proper requirements.
2. You didn't hire someone who is qualified to the job, such as putting a desktop developer onto an embedded project.
3. You didn't consider security when you dreamed up you're fragmented and broken project idea.
This is of course mitigated by a great developer who will go back to the table of executives and tell them they need what they need and won't start until it's delivered. You can't treat an embedded project like a normal software project, when you do you'll end up with systems that make Microsoft proud ( aka 0 security and patch opportunities to fly to the moon ), you need to treat an embedded project like an embedded project and give the embedded developer what he / she needs. Doing other wise will always end up you shit creek and generally the manager or stakeholder is left with the paddle looking like a fool.
<RANT>
One thing that's causing problems is the habit of Apple and Microsoft to abandon operating systems for new, often incompatible ones, instead of fixing the bugs in them. OSX 10.6.8 is full of problems; the only way to fix them is to move up to OSX 10.7 or further, which in turn can break a lot of things, because the later release isn't just fixed (if, in fact, it is fixed), it's a different animal altogether. Just one example. OS vendors take the view that you can either move forward with them, or die in a fire. Windows, Ubuntu, XP, etc... same deal.
I'm not saying these old OS's should get new features. But bugs? They should be fixed as long as humanly possible. The product was sold as having feature set X, and working. If it doesn't work as advertised, or is unreliable, it shouldn't be abandoned, it should be fixed. Except in the very rare case where it is not possible (I can't even think of one of those, actually.)
The problem is multifaceted. It isn't just that users are left with a choice of being left behind and becoming steadily more vulnerable to exploits; it is also that as the OS vendors keep jumping away from their buggy versions, the OS landscape, as it were, is left lettered with broken junk, and the new stuff is going to also be broken in new ways (plus, often, the old ways too), because:
None of these OS vendors ever intends to work any product into shape such that it becomes stable, reliable, and actually what it was advertised to be when it was sold. Instead, hey, look over here, New! Shiny!
Then we have application vendors that, for no particular good reason, make their apps not just use, but depend upon new OS features. Generally speaking, you don't have to do that. You can tie a feature to an OS, and there are very good reasons to do so (the feature may not even be possible under a previous one), but then there are things that have no sane reason to be tied to an OS, such as the ability to load a new image format (Apple, I'm thinking of Aperture here.) New interface to load images through? Sure, great idea. Abandoning the old interface? Not generally a sensible thing to do. No doubt there are applications out there that use the old interface, and there will be users with (shock!) new cameras.
I find the entire cycle of abandonment to be reprehensible and ethically bankrupt. I think applications should be maintained until they aren't broken under the OS's they were designed to run under, and OS's should be maintained until they work in every way they were supposed to in the first place, and are kept as secure as possible without actually breaking things. But that's just me.
</RANT>
I've fallen off your lawn, and I can't get up.
What if that could save you money? (it can.) What if it adds convenience and security? (it can.) What if it informs you about your usage such that you can improve your comfort level? (it can.) What if it gives you remote information, such as "the heater has failed, the pipes will freeze, you need to come deal with this" (it can.) What then? Still no business being Internet enabled?
It's not a failure of needlessly Internetting the device; it's a failure of vision on your part (and perhaps a failure on the manufacturer's part to make a secure device... that can be fixed, and pressure should be applied so the fix happens.) Sure, you can get along with your old thermostat. You could get along with a coal stove instead of a gas or electric range, too. But most of the time, not such a good idea.
The problem isn't accessibility. That's just a stopgap, though certainly a highly effective one. The real problem is security. Worthy of raving about, for sure. But with the idea of making it actually secure -- not of dumping capability out the window because of too little effort expended.
I've fallen off your lawn, and I can't get up.
We don't have unpatchable systems. What we have are vendors not wanting to maintain support for too long as they want to force people to buying always the newest to generate revenue.
There is this overall trend in IT industry that hardware gets softer and softer. With every generation, more features are implemented in software, and therefore are, in theory, patchable. But the possibilities of the soft hardware don't meet the commercial interest of the companies.
We have multiple benefits when using computer machines for doing human's work. But we also need to realize this doesn't come for free. Either we live with vulnerable systems, or we update them, simple as that. When purchasing new hardware it should always be a question to ask whether the software can be updated, and how the hw will be maintained. Compliances usually have a bad performance in this. Use well known parts, and be as mainstream as possible.
Computers don't have a long history of serving humans yet. I hope these update issues are a problem of the first generations.
Don't say that word, lest you summon ... him.
John
Microsoft doesn't want to produce a new version of Windows; they want to make money and selling new releases of Windows is how they accomplish this.
I truly do not understand why they are nixing Windows XP. The money making opportunity is tremendous: Take 1/10th of their O/S development team, and have them work on bug fixes for Windows XP. Pay them by charging subscriptions for XP support. It wouldn't have to be much: maybe $10 to $20 per year would be more than enough, and those still hanging on to Windows XP would very likely be completely happy to pay $12.95 per year to to have to mess with their obviously working system.
If you assume that the $25 or so that MS gets for a OS license from vendors covers 3 years, then $12.95 per year is at least 100% to 200% more per year, from customers that don't demand or want new features. It's like shooting fish in a barrel! If it's true that 30% of computers are still running Windows XP, this would easily become one of the most profitable divisions of MS in the near future.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I have an Onkyo amplifier (mid-range) and an LG BlueRay player (low-end). A few months back, the Onkyo no longer could connect to Rhapsody (yah, I know, Rhapsody, but the wife likes it). Onkyo knows about it, and basically says "tough" because it's an old model (~ 4 years). I can use Chromecast, but it's an annoyance, because now I have to have a phone or tablet around to listen to music. The BlueRay player no longer shows images for Netflix in its bundled application. I can use Chromecast, but again, it's annoying. It's apparently in neither company's interest to update the firmware (which is updateable on both devices) to fix these issues, because they believe I will go out and by a more recent device (if I do, obviously it will be from neither of these companies).
The whole concept of integrated A/V appliances continues to underwhelm me. Fortunately, I didn't drop extra coin for a "smart" TV, but it seems that it's how the market is moving.
Well said! Now if we could only get people also to apply the same ideas to fixing up programming languages and libraries (e..g Swift vs. C/D/Java/JavaScript/Smalltalk/etc.) instead of inventing new ones that just have different gaps and different bugs...
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.