Slashdot Mirror
Hundreds Of Smart Locks Get Bricked By A Buggy Firmware Update (bleepingcomputer.com)
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."
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."
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
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!
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
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.
Is the backup unlocking device.
This is exactly the type of shit that happens when you have millennial dipshits writing your code. Experience matters, a lot. Something the borderline millennial dipshits that run these companies don't understand.
No. Some code should not be written.
Find a different way.
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
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.
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???
Apparently people running illegal hotel services, and need a hotel key system for their "non-hotel" on airbnb.