Hacker News Reader

Comment by petertodd | Hacker News Reader

> There's really no winning with this.

There is: don't release devices with security flaws in the first place. The fact is, they released a fatally flawed device. That the flaw was discovered later doesn't change that fact.

I think the way we talk about security patches and updates obscures the fact that they're correcting fundamentally flawed software. In other circumstances, this would result in product recalls. Those financial incentives are a big reason why product recalls for serious faults are fairly rare in other types of products.

View on HN

Software should be more secure. However I don't think it's realistic to expect bug-free perfectly secure software. There is no field of engineering where 100% perfect tolerances are possible, and when you start getting past 99% the resource requirements to get to the next fraction of a % quickly go non-linear.

This is why 1) Security patches will pretty much always be necessary and 2) relying on perfect software alone is insufficient. Other precautions also need to be taken to prevent or mitigate attacks. In this case, it appears the My Book attack requires the IP address of the device. That indicates that people impacted may have been running these networked in a way that exposed them or the relevant ports to the world, which is very bad security.

Exposing IoT to the world is (going to be) common with IPv6, not sure how much SLAAC privacy extensions and "temporary" (hours to days ?) addresses help ?

> There is no field of engineering where 100% perfect tolerances are possible

This is a false proposition.

All actual engineering professions I know of have processes, checks and balances to avert disasters and premature failures. No one expects all of the shingles to be perfectly straight or have the same color, occasionally a roof may have a bit of a leak, yet I think even a single 4y old roof developing a massive leak would be a big deal. Imagine the consequences if all 4-11y old red roofs from a large construction company collapsed or developed massive leaks overnight.

Neither bridges nor roofs keep standing because they are built perfectly, nor are all bugs security issues. Yet a single fatal flaw can bring a bridge down and a single off-by-one can be a root exploit.

We shouldn't expect perfect software, yet we also shouldn't need security updates (at least not often and on everything). WD SW was fatally flawed, shouldn't have been released, WD should be responsible. SW "engineers" should be ashamed to be associated with such practices. I know I am.

Roof/building/bridge construction are things that have been around thousands of years. And they still get things extremely wrong sometimes: look up the footbridge in London as an example, it needed the equivalent of a security patch. On the issue of roofs, it's also often recommended that you do annual roof inspections and maintenance, looking for potential issues.

Regardless, we're talking about security, so let's go to the actual real-world equivalent. Physical security. Is perfection possible there? Nope. Anything even remotely capable of surviving a sustained attack is going to cost an amount of money reserved for corporations and nations, not everyday consumers.

If you think the current quality of physical engineering is something we should hold up as a comparison to the security quality expected of software, let's compare notes in a few hundred years when programming reaches the same level of maturity.

> thousands of years

Maybe I should have used electrical installations as an example?

> real-world equivalent. Physical security

Physical security isn't a good analogue, because you don't have a line of hackers, trying to get into your cupboard and magically also millions of other cupboards, closets and storage rooms with near 0 marginal cost and incomparably easy way to avoid getting caught.

Unlike physical security, perfect SW security is pretty much attainable (shocking, isn't it), with 0 marginal cost (no cost to duplicate). Physical access, social manipulation etc is physical security.

> footbridge in London

One bridge in 100, caught before it failed? Compared to all SW with network access and weekly updates.

We know how to engineer things so they are reasonably safe, we actually do it.

We also know many ways to make software much, much safer with only moderate investment, and some ways to make provably correct SW, and we do not care.

That's essentially impossible for this class of device, though. While this case is a bug in the on-device API, there are countless others involving previously unknown vulnerabilities in widely-trusted software components. Heartbleed comes to mind.

Hardware needs to be liberated from unsupported software, and users should be made aware of vulnerabilities and support status. Making software vendors liable for future exploits of unknown vulnerabilities opens a can of worms that would have non-neglible consequences for everyone who writes software, and not all of those would be beneficial to security.

Product recalls are for defects that can cause physical injury. If the MyBook had an electrical defect that could cause a shock hazard or start a fire, it would have been recalled.

Many products have flaws, but if the worst that can happen is that the customer feels ripped off, they don't get recalled. There might be remedies under a express or implied warranty, but tech products typically disclaim all of that in their terms of service.

Total remote control of the device allows quite a bit... disabling thermal protection, disabling fans, changing voltages on regulators to be out of allowed range, etc.

Just that attackers didn't choose to destroy a device in this instance, but just erased it, doesn't mean allowing control of all software on the device to randos on the internet, by not patching a root RCE vulnerability is not a physical safety issue.

> Total remote control of the device allows quite a bit... disabling thermal protection, disabling fans, changing voltages on regulators to be out of allowed range, etc.

Having total remote control of an IoT device doesn't mean any of these things. Thermal protection is hardware driven typically on die, on cheap devices fan control is implemented in hardware because it's cheaper and easier than software solutions. Voltage regulators are hardware devices that aren't adjustable, even adjustable ones have a working range that is set via resistor. Switching power supplies aren't software driven.

All of that is software controllable on many devices, especially on SoC based NASes. Working range of adjustable regulators is almost always higher than the device connected to it (resistor may be used to set the default voltage for example), on pretty much all HW I've seen so far with no way to set hard limits. And you can also cause issues just by abusing transients even on regulators that can only be turned on/off. Thermal protection on SoCs is usually based on SW regulation loop. (grep for cooling-device through DTSes in Linux tree, all those SoCs have regulation in SW)

Reply on news.ycombinator.com