So, what is it about freezers that's so appealing?

The capability to do this is something to do with the automatic defrost function that prevents build up of ice inside the freezers.

I agree it seems weird to allow it to do this for anything other than a few (tens of?) minutes. The normal purpose of a freezer being to freeze!

Unless you missed it, the issue is IOT hacking and security.

Temperature controls are fairly simple devices. There's really no point in building in application-specific limitations.

Commercial/civil regs set acceptible ranges in any application.

ANY hack of settings is potentially damaging. Freezers and chillers set to 50C simply turn off, resulting in room temperature contents.

Alarm arrangements usually have to address loss of power/control, and need to be independent.

RL

The software would presumably have blocked those high temperatures, but it had been hacked. Fridges and freezers use heat pumps to control the temperature and these are bi-directional.

The temperatures sensors I've worked with just push out a voltage that has a more or less linear (but perfectly predictable) relationship with the temperature being measured over a much wider range than the temperatures I've need to measure

You seem to be asking the manufactures to put in a second level of supervisory control that will be inaccessible to hackers and can over-ride the regular controls if the temperature inside the fridge-freezer goes outside a "reasonable range" which you haven't bothered to specify.

I can see the sense in a supermarket chain wanting to be able to read the temperatures in every ridge-freezer in every store in the chain.

But allowing for remote control of the temperature in each one seems a bit unnecessary. The people running each particular store are going to control what goes into every fridge-freezer, and they should have the same exclusive control of the temperature in that fridge-freezer.

I suspect the problem comes down to senior people wanting to be able to control everything from their desks, even when they don't know enough for this to be a good idea.

It's unclear if that's the case -- or, if it is just a simple controller that now has a setpoint that will ALWAYS be satisfied (except when deployed in subsharan Africa!)

Our freezer had such a defrost *coil* that facilitated rapid ice removal. But, it was rarely on for more than 10 minutes and didn't have enough power to change the internal temperature of the freezer compartment, noticeably; you just need to melt enough of the ice to create a thin layer of water for the "chunks" to fall off.

It seems like someone just took an off-the-shelf temperature controller and wired it to the compressor/evaporator without thinking about the application domain at all -- checking to see if the user input made any sense in that context.

Of course, it's not the automation provider's "fault" as they likely delivered what was requested. Maybe folks will learn to better specify what they *want* (which requires actually THINKING about their needs).

What *you've* missed is the reliance on a single layer of protection (i.e., access to the controller).

A better design would layer those protections

Why? Because it dramatically adds complexity to the problem?

"if (setpoint > 10C) then setpoint = 10C"

Presumably, there is a limit so the user can't specify a setpoint of 300C. How does changing that limit to something more practical affect the cost/complexity/reliability of the controller?

I can limit the number of "free balls" a player can earn while playing a pinball game. Why? Because I don't want him to play forever and deprive other players (paying *customers*!) of that ability. That one line of code adds considerable value (in years past, it was a bolt inserted on a mechanical "stepped" wheel)

There's a reason you can't easily put a car in reverse (e.g., by "missing" the desired gear). All applications should assume the user can make mistakes and take measures to protect against that. "Do you REALLY want to set the temperature to that -- realizing that any foodstuffs will likely spoil?"

Our old commercial home thermostat allows the temperature to be set in a range of 40F to 90F (for heating). If the user wants to disable ALL heat (to allow the house to approach freezing and put the plumbing at risk), he can turn the thermostat/plant off. He's gone above and beyond the abilities of the thermostat to ensure "rational" behavior.

But, he can't accidentally set it to "30" when he meant "80".

Cite? They require foods to be maintained at particular temperatures (and for particular intervals). But, don't mandate how the equipment must operate.

That's not known.

Alarms are reactive solutions. The s*it has already hit the fan. Our freezer alarms when it can no longer decrease the temperature of the internal volume. Whether that is because of compressor or evaporator failure or someone leaving the door open; the controller KNOWS it is failing to meet its intended purpose.

This means the controller can alert before the temperature has changed to an unhealthy/costly level. Waiting for it to get to that point turns the alarm into a "please dispose of food indicator". And, its purpose is to detect equipment failures, not a "patch" for operator f*ckups!

If someone is remotely controlling the setpoint (as a REQUESTED design feature), then reacting to such an alarm may not be timely as you have no idea if the user can access his controls *or* the facility being controlled.

The refrigerators and freezers in that application are subjected to a lot of abuse with people constantly opening and closing the doors, holding the doors open for indefinitely long times or even just leaving them not fully closed. The situation is exacerbated by heat wave conditions with which the store A/C cannot fully keep up. Remotely setting the thermostat lower may slightly improve the situation.

Water condenses out of the air and freezes on the evaporator coil, regardless of whether it is a refrigerator or freezer. The frost impedes heat exchange and, if left in place, eventually accumulates to the point of completely blocking airflow. No airflow= no cooling. Therefore, the frost must be periodically melted off the coil before it gets to this point, and it's done by heating the coil. The cheapest and most common way is to use an electric heater. There are other ways, such as air or hot gas, but nothing that could get the interior space up to 50C. The electric heaters are substantial; even a small one might be 350W, but there could be much larger ones depending on the design. The reason is that the compressor and circulation fans are cut off during the defrost, allowing external heat to migrate into the conditioned space as well. So they want to make the defrost cycle as quick as possible. The hacker/vandals hijacked the local Danfoss case (individual cooling unit) controller, model AK-CC series, into a permanent defrost cycle via the Danfoss AK-SM 800 system controller, and at the same time overwrote the baseline safety limits stored locally in the case controller that would have prevented the fiasco. Wow, what imaginative geniuses they were. Russian fingerprints everywhere.

The problem was not Danfoss so much as the Estonian Kitman Coldtech system and software provider with their lax security features. Danfoss produces famously excellent products. The technology originally developed by Danfoss completely dominates the 12V/24V DC mobile refrigeration market in the U.S., meaning the industry-standard 12V compressors powering premium American marine, RV, and off-grid fridges. Top-dollar too.

....

That probably has a lot to do with it but it's only part of the reason for the problem.

I noticed the same story here:

The same was true more than 20 years ago so it's clear that nothing will change and insecure systems will only get fixed after they're hit.

Without Blaster it's likely that this wouldn't have happened:

So now we have RIIR

It's unlikely that the refrigeration gear in a supermarket frozen-food case is reversable. My fridge certainly will not heat above room temp.

Setting it to 50C just turned off the cooling.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

none of them are bi-directional

I think you'll find they put it into defrost mode which has a heater to remove frost. Whether or not they also overwrote software limits for length of time and maximum temperature I do not know but if you own the controller then you can tell the hardware to do anything you can tell it to do.

Defrost is usually some resistive elements that melt ice on the cooling coils. It doesn't reverse the heat pump and it doesn't heat up the frozen peas.

A reversable heat pump is expensive.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

So, the controller should KNOW not to let this persist.

Hard (application specific) limits should require on-site access, not be "remoteable". They should be one-time limits set at time of deployment, not "tweaked", later.

It can be argued as to the utility of being able to remotely adjust the temperature setpoint *or* invoke a defrost cycle.

I suspect a fair number of people will be rethinking what sorts of remote access are desired and/or tolerated.

Yes

Yes

I'm seeing pictures of many items being thrown out. Why do that if they are still frozen?

I'm not sure their goal *is* to see change. I think htey just want to poke at things that they know they can break.

Malware has been around -- forever!

In the past, the "damage" was magnetic domains on storage media. It was more an exercise in proving what "YOU" could do.

It has increasingly become a financial tool -- locking people out of their computers/systems in exchange for "ransom".

The next step is to weaponize these attacks to cause confusion and/or cripple key systems and infrastructure. Imagine someone attacking the cellular network, power grid, etc.

The reason for it is lack of discipline and testing on the part of developers. You can create buffer overruns, stack overwrites, use-after-free, etc. in lots of different programming environments (esp if you can coax a bit of ASM into your binary!)

If you adopt a policy of authorizing an *agent* to perform specific tasks (instead of a *user*), then you can mitigate these things. E.g., there is no way the security camera that monitors my front door can be coerced into altering the setpoint of the house's thermostat -- even if you had unrestricted ASM access to its hardware platform. Because the software running on/in the security camera (the "agents") have no reason to be accessing the thermostat so any attempts to do so will be fruitless. You can't even *reference* the thermostat (by name, address, function, etc)

OTOH, if you lump everything into acting on behalf of a particular UID, then ANYTHING that UID could do could be done by a malevolent version of your code (or, a corrupted/buggy version).

Another consideration you're not aware of is the international market for these systems. Depending upon the country, and even the locale within a single country, there are public health regulations governing storage temperatures of the various kinds of products being refrigerated. So making everything programmable allows the systems to be adapted any and everywhere. They should be logging the temperature histories too for the same compliance and liability issues.

Regardless, there are still sensible limits that can be extracted from any regulatory documentation. They were just sloppy and didn't install specific limits at time of deployment (why would there even be a 50C setting supported on a controller deployed for a FREEZER??? If you want to turn it OFF, then have an ON/OFF switch!)

They're just simple programmable temperature controllers. You wouldn't expect those to be able to detect that anything is amiss. They should't have been accessible from the general internet, is all.

Jeroen Belleman

Lawyers.