Slashdot Mirror

← Back to Stories (view on slashdot.org)

Hundreds Of Smart Locks Get Bricked By A Buggy Firmware Update (bleepingcomputer.com)

Posted by EditorDavid on from the world's-smartest-bricks dept.

An anonymous reader quotes BleepingComputer: On Tuesday, August 8, smart locks manufacturer LockState botched an over-the-air firmware update for its WiFi enabled [RemoteLock 6i] smart locks, causing the devices to lose connectivity to the vendor's servers and the ability to open doors for its users... The device costs $469 and is sold mainly to Airbnb hosts via an official partnership LockState has signed with the company. Hosts use the smart locks to configure custom access codes for each Airbnb renter without needing to give out a physical key to each one. The botched firmware bricked the device's smart code access mode. Physical keys continued to work. The botched firmware was a nuisance for private home owners, but it was a disaster for Airbnb hosts, who had to scramble to get customers physical keys so they could enter their rents.
The post includes tweets from angry lock owners, one complaining about a two-week wait for a replacement. The company is also offering to fix the defective units within "5-7 days," promising that "Every employee and resource at LockState is focused on resolving this for you as quickly as possible."

11 of 119 comments (clear)

  1. Inside Job... by js290 · · Score: 5, Insightful

    Yet another data point demonstrating outages are better caused by admins than by hackers.

    --
    "Tempers are wearing thin. Let's just hope some robot doesn't kill everybody." --Bender
  2. Cloud equivalent by CaptainOfSpray · · Score: 5, Interesting

    Yet another data point to underpin the motto "Never allow any data or access or service that you value to be controlled by Somebody Else's Computer"

    --
    "Cock Up Your Beaver" does not mean what you think. This sig is intended to clog filters and annoy do-gooders
    1. Re:Cloud equivalent by arth1 · · Score: 4, Insightful

      However big a QA screwup this is, at least give this company credit for actually trying to upgrade their firmware.

      Um, no. Allowing a firmware change mechanism is the flaw here, and should not be commended.
      The time to harden a lock isn't after it's sold.

    2. Re:Cloud equivalent by AmiMoJo · · Score: 5, Insightful

      Their mistake was trying to build an impossible product: an internet connected, secure lock that people can rely on.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    3. Re:Cloud equivalent by ctilsie242 · · Score: 5, Insightful

      A lock is a relatively simple device, where the states are obviously known. Devices like this should ship and not need firmware upgrades from the factory. There are many embedded subsystems that cannot or will not be upgraded, so the people who made them did it right the first time, and didn't follow the philosophy of "it builds, ship it."

      A lock isn't rocket science. It also is the last thing you need fetching OTA updates. Instead, updates should be delivered via some physical means, if only to ensure someone is on site to test and verify functionality.

      Making sure a device doesn't brick itself is not impossible. I have an older Nook tablet that, if it doesn't boot after eight times, it automatically reloads itself from its original firmware, just so the device is usable in some degree. With a deadbolt, you might want a more secure way of failing, so having multiple areas where ROMs are stored, so if it fails to boot, it goes back to a previous ROM. That way, it might grab some bad code and brick a few times, but once the failed update is off the servers, it would fetch a correct one and be fine.

      Lesson learned from this... find a lock maker that treats their offerings as a security item, and not some throwaway IoT device.

  3. Software Engineers for the Win! by Anonymous Coward · · Score: 5, Insightful

    Way to Go Software "Engineers". I can't wait for the self driving cars to roll out.

    We are sorry that your self driving car veered off the road and killed all its passengers. We have isolated the bug to the periphery scanning routine. Please accept 1 Mo of free self-driving car time, or 1 Mo of free Uber/Lyft service, and this complimentary condolence ham. Remember, our liability is limited to the price of the software, please accept this 1499.99 as full compensation for the death of your relatives.

    Your insurance is fully liable for the remaining costs, re: the 4 pedestrians that were killed. Our liability ends here, have a great day!

    1. Re:Software Engineers for the Win! by Megane · · Score: 5, Funny

      Way to Go Software "Engineers".

      But they were the finest Millennials that stock options could buy!

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
  4. QA testing.... by Minupla · · Score: 5, Insightful

    I've seen it increasingly over the last few years, shortcuts on testing in order to get an update/new product out the door. This is short sighted. In a year, noone is going to remember it took you a week longer to get it out the door. People WILL remember if you brick all your devices.

    --
    On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
    1. Re:QA testing.... by Maximum+Prophet · · Score: 4, Informative

      If you are late delivering the product, you *will* be fired. If you send the product prematurely, you *might* brick the device, and have to stay up late fixing it. You decide.

      --
      All ideas^H^H^H^H^Hprocesses in this post are Patent Pending. (as well as the process of patenting all postings)
    2. Re:QA testing.... by Minupla · · Score: 4, Interesting

      In most companies I've worked in, *you* don't decide. You raise the risk to your risk management team, who breaks the bad news to the people who get paid to make the 'hot seat' decisions.

      So failure analysis suggests one of the following happened, all of which fall under the "QA" side of the business processes::

      1) QA was not thorough enough to detect that this firmware update would have enough of a worse failure rate to raise business risks to an unacceptable level.
      2) Risk management wasn't doing their job
      or
      3) Management made a poor business call on letting this go out, and didn't plan for the risk coming to pass (e.g. with pre-staged replacement devices, prepared messaging, etc)

      --
      On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
  5. Wait, wait, wait... WHAT? by Opportunist · · Score: 4, Informative

    Can I hear that again?

    [...]causing the devices to lose connectivity to the vendor's servers[...]

    So, lemme get this straight: These things, that lock my home doors, have a connection to their vendor, reacting to this vendor's command to unlock or lock my home. Did I get that right?

    What sane person would WANT that in the first place???

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.