Forgot your password?
typodupeerror
Security IT

The Coming IT Nightmare of Unpatchable Systems 240

Posted by samzenpus
from the down-in-flames dept.
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.'"
This discussion has been archived. No new comments can be posted.

The Coming IT Nightmare of Unpatchable Systems

Comments Filter:
  • They had the same problem prior to the year 2000, so why wasn't this lesson already learned?

    • by ZouPrime (460611) on Monday June 02, 2014 @04:12PM (#47149165)

      The lesson wasn't learned, but the problem was somewhat mitigated. Big software companies adopted regular patch cycles and deployed patch management tools on their customers. It kinda worked because PC are powerful computers well designed to be upgraded and modified.

      This is not the case for many embedded systems. They are designed to be installed and then you forget about them. So the "classic" mitigation technique doesn't work. This is a big problem.

      • by Penguinisto (415985) on Monday June 02, 2014 @04:33PM (#47149349) Journal

        They are designed to be installed and then you forget about them. So the "classic" mitigation technique doesn't work. This is a big problem.

        Hell, I thought the "classic" mitigation schemata for embedded devices was to not have them networked at all, leaving them to run for years (decades?) on end.
        (See also the hordes of NT Telecom PBXes out there which are likely still around, requiring a goofball proprietary connection to a computer running OS/2 (!?) in order to patch it (or more commonly, you did it to add new/licensed features or to fix something gone corrupt).)

        Therein lies the whole problem with the paradigm, truth be told - originally, embedded devices didn't communicate with jack shit - you unpacked it, turned it on, maybe configured it, and then you forget that it existed until it broke (at which time the vendor/contractor sent someone out to fix it), or got replaced.

        All that said, hell, we already have a testbed for this nightmare - an ocean of smartphones whose carriers and manufacturers ceased to give a crap whether their wares ever got upgraded.

        • by Rich0 (548339)

          They are designed to be installed and then you forget about them. So the "classic" mitigation technique doesn't work. This is a big problem.

          Hell, I thought the "classic" mitigation schemata for embedded devices was to not have them networked at all, leaving them to run for years (decades?) on end.

          Unfortunately, the guys at Buffalo who sold me my router haven't heard of this principle. It contains a version of openssl known to be vulnerable to Heartbleed, and it has yet to be patched. Previously I figured I didn't use anything that depended on the library, but now the article came out that it potentially could be used for EAP - I have no idea if this is the case but I'd prefer not to wait and find out.

          Fortunately it runs DD-WRT which means that OpenWRT is almost certainly a practical option. I'll

      • by gbjbaanb (229885)

        its not the size - my motherboard bios can be upgraded and its tiny. The problem is that it costs effort to make them upgradeable, and companies are cheapskates.

        • by Archangel Michael (180766) on Monday June 02, 2014 @05:16PM (#47149759) Journal

          Companies aren't "cheapskates", customers are.

          Here, I'll prove my point,. You can buy something for $15 today, and have it supported until tomorrow(or whenever) or you can pay $300 for the same exact thing, only support will go for a guaranteed 10 years.

          Guess what, the company didn't make the choice, you did. The company is just following the choice you've taken.

          The problem is solvable. Like Cellphones, it is cheaper and easier in the long run to simply buy a new one every 2 years than it is to buy one that will last you five. And in two years, sufficient advancement means that your old cell phone won't do all the neat cool things that all the new phones want to do, and you're gonna upgrade it anyway, so buy the cheaper one now, and upgrade in two years.

          • by plover (150551)

            So perhaps they should be sold like that: "You can buy our Amazing zPhone 5 for $100, guaranteed to work until 2018, or our Amazing zPhone 5c for $150, guaranteed to work until 2021. We no longer sell the Ordinary zPhone 4, whose guarantee runs out in 2015, and will in fact quit working by 2016."

            Right now when someone buys a cell phone, they have it in their brains that they're making an "investment", that the phone will last for the next 20 years, or even forever. They are used to products that wear out

            • by mythosaz (572040) on Monday June 02, 2014 @06:15PM (#47150249)

              Right now when someone buys a cell phone, they have it in their brains that they're making an "investment", that the phone will last for the next 20 years, or even forever.

              They do? Who are these people?

              For a sufficiently true portion of "everyone," "everyone" just gets a new phone every two years on contract anyway.

            • The replacement date for cell phones is upfront and written into most contracts. It is a fundamental part of cell-phone contract marketing these days. So nobody is thinking 20 years unless they are deluded, and the phone companies are definitely not promoting that at all. The 2 year upgrade cycle is transparent, and well understood between customers and vendors. So what is your point?

              • by marka63 (1237718)

                Total BS. Phones should last 20 years. The old land line ones last 20+ years. The only thing in a modern phone that doesn't have a 20+ year life span is the battery and that is not through not trying.

                As for the 2 years that is the time to pay off the phone in instalments, not when it is supposed to be unusable any more. Yes, phone companies would like you to get a new phone every 2 years as that locks you into them for 2 more years.

                As for fixing bugs in the OS most of the time a bug that exists in one v

          • Companies aren't "cheapskates", customers are.

            Here, I'll prove my point,. You can buy something for $15 today, and have it supported until tomorrow(or whenever) or you can pay $300 for the same exact thing, only support will go for a guaranteed 10 years.

            And here is a counterpoint: I was evaluating a piece of robust hardware for installation at remote sites (~$5k). The hardware has a built in micro that monitors all the functions and provides configuration, it is programmed via DIP switches and a serial port

      • by Tom (822)

        This is not the case for many embedded systems. They are designed to be installed and then you forget about them. So the "classic" mitigation technique doesn't work. This is a big problem.

        Only because software development sucks and nobody takes the time and effort for not-so-much-fun things like code review.

        • by ZouPrime (460611)

          "Only because software development sucks".

          The solution isn't better coding. It's been CLEAR now, for many years, that we can't just wait for the world coders to magically become amazing and consistently produce flawless code. Yes, training is part of the solution, and so are advanced debugging tools and many other things, but just blaming that it is the coder's fault won't change anything. It's not a solution, it's a blame.

          It's like saying that car deaths would go down if only drivers were better.

      • by NReitzel (77941)

        Unpatchable systems are a problem, but if you view them as a black box, they are no different than non-logical systems that break.

        I'm rather fervently against systems that cannot be upgraded on the fly, but I understand why manufacturers might not like this.

        Consider, if you buy a traffic light controller that can be improved and modified, then where is the motivation for a second round of purchases when "upgrade" becomes necssary. After all, I certainly want the person who sold me a refrigerator to be able

    • by Sarten-X (1102295)

      I was thinking we had the same problem with work horses that got old, or with pre-OSHA workers who lost limbs in factories.

      The solution is the same, but now there's no ethics to be worried about. If your system or device can no longer perform its job (including meeting security requirements), replace it. Oh, sure, there's lots of sentimental value in having something obsolete that you already own rather than paying again for something with a support life, but that's why you were able to afford the thing in

    • by NoNonAlphaCharsHere (2201864) on Monday June 02, 2014 @04:27PM (#47149301)
      Different nightmare. The Y2K embedded system nightmare was systems that wouldn't know what to do when the clock rolled over. By and large, the doomsayers were completely wrong. The current problem is *Internet enabled* embedded systems, easily hackable, out of warranty, out of support, manufacturer TU, owner/deployer isn't even sure how many they have, or where they're located, etc., etc. Picture making a botnet out of all the traffic light controllers, or the elevator controllers, or smart water meters, or internet toasters.
      • by SuricouRaven (1897204) on Monday June 02, 2014 @05:05PM (#47149663)

        The doomsayers were right. A great deal of effort went into patching and testing all critical systems before the year ticked over. There was no disaster because systematic action to avert it was taken well in advance.

        • by wonkey_monkey (2592601) on Monday June 02, 2014 @06:01PM (#47150133) Homepage

          A deadline has a wonderful way of concentrating the mind. No deadline, less motivation.

          • A deadline has a wonderful way of concentrating the mind. No deadline, less motivation.

            This is the next big one: https://en.wikipedia.org/wiki/... [wikipedia.org]

            Honestly I wonder how many devices it will affect. I know anything which isn't patched and relies on security certificates is hosed, but what about the network printer that nobody cares about and is running completely unsecured?

        • The doomsayers were right.

          No they weren't. Many people updated and patched their systems. Plenty of other people did NOTHING. Neither had any significant issues. My company budgeted this much for Y2K preparations: $0. We figured we would just let the failures happen, and then deal with them after-the-fact. Here is a complete, exhaustive list of all the problems that occured on 1/1/2000:

          1. A javascript bug caused the date on our homepage to say "Jan 1st, 19100". Time to fix: 30 seconds.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        The doomsayers were wrong because we patched our systems.

    • by Lumpy (12016)

      Greed.

    • They had the same problem prior to the year 2000, so why wasn't this lesson already learned?

      No, it was a totally different problem.

      Y2K was about an optimization made early in the history of software development, when every bit and byte was precious, and it was expected that the software would be replaced long before it became a problem. Well, not all of it got replaced before then - but everyone knew the problem was there, and exactly when it would bite us, so a lot of people worked hard patching system so that there were no major problems. And before you sneer at the short-sightedness of ear

  • Slashdot keeps forwarding me to activeplayer.us, which tries to drive-by-download an installer. It looks like Adobe's FlashPlayer site.
  • Driverless cars... (Score:4, Insightful)

    by russbutton (675993) <russ@russbu[ ]n.com ['tto' in gap]> on Monday June 02, 2014 @04:12PM (#47149163) Homepage
    Wait until we have driverless cars on the road. But I'm sure they'll all be bullet-proof secure, don'tcha think?
    • by dkf (304284)

      But I'm sure they'll all be bullet-proof secure, don'tcha think?

      What kind of glass are you using?

      Oh, that kind of "bullet-proof". Not the Chicago Musicians' Union kind...

      • Eddie Jefferson was shot outside a Detroit nightclub in 1979 by a dancer who was pissed off at him. In 1972, Lee Morgan was killed on-stage in a New York night club by his jealous girlfriend. In 1988, Chet Baker died when he "fell out of a window". One of the greatest tragedies of all was when Clifford Brown died in 1956, at the age of 25, when a car he was riding in ran off a highway on-ramp in the rain. Probably the most amazing jazz musician's death was that of Buddy Rich, who somehow managed to

  • by mmell (832646) <mmell@hotmail.com> on Monday June 02, 2014 @04:15PM (#47149205)
    "Insecure by design". Faa.

    "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.

    • Page two of the article used the "Insecure by Design" meme. I guess the fault's with the article, not the poster.

      And - yes, these kind of incidents are mistakes. I stand by my previous assertion that nobody set out to create insecure embedded systems. Poor design, incorrect design, or just plain inept management oversight has led to these kinds of mistake. Much as I'd like to blame MicroSoft for all of it, I can't. Sorry - love to, can't. I'm still certain that all of the entities involved believed t

    • Internet access isn't needed, though. You can do some searching and find ATM hacks using the mag card reader.
      I would assume that with enough playing around, there may be a key combination that could cause an exploit on the slots, but the cameras all over the casino do a good job mitigating that threat.

      • by mythosaz (572040) on Monday June 02, 2014 @06:31PM (#47150361)

        Slots? Impossible :)

        http://www.wired.com/images_bl... [wired.com]

        The "hack" was to get the operator of the video poker machine to enable the "double or nothing" bonus, which had a unique bug.

        Most newer video poker and slot machines allow (or can allow) you to play at various coin values. Each credit can be $0.01, $0.05, $0.25, $1, $5, etc.

        This particular machine would allow you to wager at $0.01, reach the Double or Nothing screen, use a combination of keys to get to the credit value change screen, and return to the Double or Nothing wager with your bet still pending.

        In short, you would put in a $100 bill. You would wager 100 of your 10,000 credits at $0.01/credit ($1) until you won, and when reaching the Double or Nothing screen, you would navigate out to the change credit screen. You'd change your credit value to $5 per credit (dropping you down to ~20 credits in the bank), return to the DoN screen with your bet IN CREDITS, NOT DOLLARS still pending and then you'd stand a chance to win 400 credits (twice your original CREDIT win) on your DoN bet. you could win $400 on $1, on what should have been a simple 2-1 (doubled) 4-1 payout.

        The spread likely wasn't $0.01/$5.00, probably was $0.25/$2.00 at the most, but by picking and choosing good payouts to DoN on, they were essentially playing machines with a winning paytable. [Since DoN's didn't pay double or zero, they paid 16x or zero.]

    • For some reason companies try to put computers and networks into everything. Take cars for example, not only they are full of computers running very complex software (most of which is not really needed), now there is even internet connection for cars. Why? My 1982 car does not have internet connection and I really don't see a reason why it should.

      I started preferring simpler devices, usually ones that I can repair myself if they break. Sure, computers are an exception and I have an older smartphone (Nokia E

    • by plover (150551) on Monday June 02, 2014 @05:07PM (#47149673) Homepage Journal

      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.

      Just because you haven't encountered a specific example for yourself doesn't mean they don't exist in the real world.


      • The TV? Netflix, of course.

      • The BluRay player? New keys for new disks, and to unlock "extra special downloadable content" (whatever that may be.)

      • The thermostat? You're coming home from summer vacation and want to turn on the A/C a few hours before you arrive.

      • The laundry machines? You're upstairs, out of earshot of the dryer, and want to know when the load is done so you can hang up your clothes to prevent wrinkles.

      • The smart refrigerator? Maybe you're having a problem, and need the technician to connect to it to remotely diagnose it and give you an estimate without making an expensive house call.

      • The freeze alarms? You're out of town during the winter, and want to be alerted if your house temperature drops to the point where it's threatening to freeze your water pipes, so you can call a neighbor for help or a repairman to fix the furnace.

      • The door camera, locks, and security alarms? You're still out of town and want to let the repairman in, so you look at the ID he holds up to the camera and remotely unlock the door for him.

      • The window shades? They're located high up in the skylights where you installed a motorized system to operate them, so it was a small additional expense to add a remote control. And as today may be very sunny, you want to close them while at work to keep the house cooler.

      • The dishwasher? It might need to know the scheduled price of electricity in order to avoid running during peak rates, and save you money.

      These are not made up examples - they happen every day. If someone already has the connectivity, and pays for the equipment to have the capabilities, there's no reason they shouldn't also enjoy the convenience.

      Note that this is true whether or not you personally think it's a good idea to connect your washing machine to the internet: the reality is Sally Soccermom and Charlie Cuttingedge already have houses full of this tech. You can buy all this stuff at Best Buy and Home Depot and Verizon today.

      Of all of these systems, most are designed and built with a remote update mechanism. Some that aren't (door locks, freeze alarms) are generally run through a home automation controller that is itself updatable; so even if you can't remotely patch your freeze alarm, you can at least patch the controller that interfaces with the network. Also of note, most are aware of the typical home firewall configuration, and are designed to "phone home" to check for updates. They generally don't sit on the raw internet and listen for incoming connections, so the attacker generally has to get inside the firewall to abuse them (which is not that big of a problem for many models of firewalls, that's for sure.)

      • by AdamHaun (43173) on Monday June 02, 2014 @05:43PM (#47149983) Journal

        A lot of those examples are solved problems, and at worst are minor inconveniences. Many IoT proposals can easily be replaced with three existing categories of solution: "other people", "paying attention", and "non-networked computing". To address your specific examples:

        Thermostat: Schedule the turn-on in advance. Alternate, come home, move your luggage inside, turn on the AC, and go out to dinner.
        Laundry machines: Check a clock every so often.
        Broken fridge: Show failure status on an LCD. Or have a USB port that you can plug a laptop or a smart phone into.
        Freezing weather: Ask a neighbor or a friend to check on your house once every day or two. You may already be doing this if you have pets.
        Door opening: See above re: neighbor or friend, or hide a key somewhere.
        Out-of-reach window shades: Close them before you leave for work.
        Dishwasher: Assuming that scheduling is really that much of a money-save, start it manually before you go to bed. Or use a time delay. Or load the data into the washer via USB.

        The more serious problems are much more rare, and that must be weighed against the constant vulnerability from having internet-connected appliances and the upkeep required to secure them.

        Perhaps a better option would be to get away from the idea that networking should imply both internet access and full remote control. Is there any reason an embedded device can't limit communications to its own subnet? Stick an upgradable, patchable PC on the network to act as a master, and have it talk to the outside world. Meanwhile, the appliance should be designed at the hardware level so that remote access only gets you status information and the ability to trigger a few well-defined fail-safe modes. Using a stove as an example, you would be able to tell if the burners are on, or force them off, but you wouldn't be able to turn them on or change the heat setting.

        • Re: (Score:3, Informative)

          by radish (98371)

          Door opening: See above re: neighbor or friend, or hide a key somewhere.

          A truly special reply suggesting mitigating a theoretical, limited, network security vulnerability by quite literally leaving the physical keys to the castle out in public. Please hand in your risk assessment credentials at the door.

          • by AdamHaun (43173)

            A truly special reply suggesting mitigating a theoretical, limited, network security vulnerability by quite literally leaving the physical keys to the castle out in public. Please hand in your risk assessment credentials at the door.

            I think you misunderstand. I'm not saying you should leave a key right outside the door all the time. I'm suggesting hiding a key somewhere non-obvious, *temporarily*, as a backup method in case you can't have an actual human being present. The alternative is an always-on, globally-accessible network attack surface for your front door lock. If that's compromised, getting in is as easy as "send me X bitcoins and I'll open the door at Y o'clock".

        • by plover (150551)

          You completely missed the point. Nobody cares if you don't want your stuff connected to the internet, or if you have clumsy workarounds to offer them.

          This stuff already exists and it is already connected to the internet. It is an existing problem that will only get worse as more stuff is added.

          It doesn't matter if you personally think hooking things to the network isn't safe. They're not products under your control. Samsung and JVC and Sony and LG and Panasonic and Honeywell and everybody and his brother

          • by AdamHaun (43173)

            This stuff already exists and it is already connected to the internet. It is an existing problem that will only get worse as more stuff is added.

            Just because the equipment is present doesn't mean it's connected. At the very least, the user has to pick a wireless network and enter the password. I see your point, though.

        • by Lumpy (12016)

          Internet enabled window shades? how dumb. just use a simple wireless non IP protocol. like this tone for UP and that tone for down, like 99% of all somfy and other motorized shades use and have used for the past 40 years.

          • by plover (150551)

            Here's a better use case: they're part of a home theater setup, where when the user sets the "watch movie" scene, the lights dim, the shades darken, and the A/V system powers up. They may not be directly on the internet, but controllable through a home automation system.

            If you already have Somfy blinds, here's a plug in for Vera home automation systems: http://wiki.micasaverde.com/in... [micasaverde.com]

            • by Lumpy (12016)

              I have had that for well over 15 years, Two contact closures work perfectly over wires embedded in the wall.

    • 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.

      I'm sure they connect to a network. The question is, is the network attached or otherwise accessible from outside, or by other means (social engineered hack). Unless the network is 100% completely separated from the outside (and even then..) it is at risk.

    • player life has a web site and is tied to games in lot's of casinos

  • wait (Score:3, Interesting)

    by Charliemopps (1157495) on Monday June 02, 2014 @04:17PM (#47149215)

    "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.

    • by plover (150551)

      A system that can't be patched, can also not be altered to do the attackers bidding.

      That's not completely true. Even if a device loads its code from ROM on every reboot, with no capability of flashing new software, an attacker can still patch the running instance of code to do his evil bidding. Many machines will run for months or years without rebooting, allowing the attacker to benefit from them over and over.

      The attackers who are hacking into your thermostat or washing machine have little interest in making your house hot, or your clothes dirty. They want to make money. They do that

    • by znrt (2424692)

      this makes no sense. nothing is unpatchable. where you read "unpatchable" you should read: "we will not patch it because it isn't profitable, so please upgrade to our new shiny shit which we obviously won't patch either".

      of course folks with malicious intent can find a way to patch it, and will. there is nothing adding to security here, quite the contrary. it's just a big clusterfuck. industry is only interested in perceived security. then of course people get what they pay for.

      time to take opensource softw

      • by plover (150551)

        There are plenty of embedded systems that are "unpatchable": those that have their programs burned into ROM instead of Flash or EEPROM. The physical hardware required to modify the ROM chips simply doesn't exist in the equipment the manufacturer shipped; or the chips themselves may not even be modifiable once burned.

        However, "unpatchable" does not mean they are "unhackable", as the CPU of a von Neuman architecture chip can still be subverted to execute code dynamically loaded into a RAM buffer (and the co

  • A systemic problem (Score:4, Insightful)

    by rijrunner (263757) on Monday June 02, 2014 @04:31PM (#47149337)

    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.

  • Your fridge sends out a little packet that says: "Hey, I am past my warranty! Time to up the ad volume to MAX". Or: "Please press OK to agree to the new privacy terms and conditions or your device wont work anymore".
    There are many serious problems that are here NOW and must be addressed.

  • by roc97007 (608802) on Monday June 02, 2014 @04:33PM (#47149359) Journal

    Make them patchable over the internet by default.

    Oh, wait...

  • 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 're

  • The problem IS that things are trusted by default... but not in the way the author thought. If you trust every program you run by default, you are doomed. An operating system should NEVER trust anything by default... Linux, Windows, OSX all violate this principle. So do embedded devices base on some variant of them.

    Never trust by default, and you stop having to worry about side-effects, and start deciding what the limits are ahead of time.

  • by Murdoch5 (1563847) on Monday June 02, 2014 @04:52PM (#47149539)
    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.
    • But, But you can just put Linux on there. Then you can use Java for all those fancy things you mentioned. That will solve all your problems.
      https://xkcd.com/801/ [xkcd.com]
      Seriously, I'm pretty sure I've seen this on an old Vonage box I was playing around with.

      For many of the smaller microcontrollers we're lucky to have a full libc. It's always a wonderful day when I have to choose between rewriting an algorithm to use integers or taking a chance with new hardware with a built in floating point unit when the ship

      • by Murdoch5 (1563847)
        It's hilariously funny how often I've heard, "Just put Java on it and you'll have memory management." Java is a good language for when you need portability and don't care about overhead and run time speeds, to be clear, I'm not saying Java is slow, but it's slow compared to C or ASM.

        It's also funny how often that is included with the discussion about why I don't need more time because Java and languages like Java exist. The last time I had to sit in a board room and had to listen to a desktop develop
  • [...]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[...]

    This is a weighty issue. I will take it before the elders of my own company -- surely those wise fathers will know what to do. In the meantime, send forth the maidens to wail and weep in the streets, that all the people may know how grievous is this news.

  • by NotInHere (3654617) on Monday June 02, 2014 @05:37PM (#47149939)

    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.

  • by Sir Holo (531007)
    Why would I ever want my refrigerator to have internet access?

    The marketers, sure, they want me to think that I need that. But, really, what conceivable value or advantage would the ($30-extra purchase price) confer to me?

    None? Well, I must be a sucker.

    Or, wait, I have to actually exert more effort to maintain the internet security of my refrigerator, which wasn't and should have never been internet-connected in the first place? If you find yourself in this latter situation, you are dumber than a s
  • You know, all of this stuff MUST be connected to the internet.. or it will EXPLODE!

    Oh wait it wont.. so just not plugging it in makes it 100% hack proof.

  • by Carcass666 (539381) on Monday June 02, 2014 @08:20PM (#47151089)

    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.

  • I'm not a software engineer, just a user, but why do we need to have new OS versions every fucking year? Really, couldn't Microsoft have an OS that looks largely like Windows 3.1 or XP or whatever to the user, but is streamlined and patched to modern standards of security and interoperability?

    I'm not trying to start a flame war, but really - as a user I see more change in software as churning to turn a dollar vs. actual improvement. A model where a software might be patched and "recalled" for improvement fo

Save energy: Drive a smaller shell.

Working...