Schneier on embedded: "no more binary blobs!"

While I generally agree that security needs improved, the "automatic update mechanisms" part fills me with dread.  I've watched various vendors struggle to get that concept right, most often leading to that very mechanism having to be treated as the biggest threat and specific controls and safeguards put in place to prevent it running amok.

You're spot on with the observation that these networked embedded systems are increasingly in control of physical systems where the implications are potentially huge, I suspect that's an iceberg where we don't yet fully see the extent of the problem.  I'm quite sure I don't trust a vendors automatic update with a physical system without guarantees that it's safe.

The flip side, for linux based embedded systems, is that the vendors really need to get their acts together and get their code into the mainline kernel. Simply put, a years out of date vendor kernel will never have as many eyes looking at it or have the same fixes applied as the mainline devs will do to all the code in the current kernel.  Stuff that's in mainline also tends to live on with active support long after the manufacturer has either abandoned it or gone out of business.

Personally, I've already come to the conclusion that I don't want to use boards that are not supported by mainline, if there's obvious and active efforts to push it to mainline that's fine.  Those that are not doing so will be getting a negative recommendation from me.

From the perspective of a corporation, you can understand that they think it's in their interests to sell insecure crap. They know you'll have to buy a new one once the vulnerabilities are exposed. It becomes difficult for us to simply boycott the offenders - since they're all just as bad as each other!

selsinork wrote:

 

While I generally agree that security needs improved, the "automatic update mechanisms" part fills me with dread.

As I was pasting in Schneier's paragraph, I initially considered leaving off his final sentence "We need automatic update mechanisms to ensure they get installed", as it opened up a sub-topic that I knew would raise eyebrows --- indeed I felt the same way on first reading.  Then I realized two things:

1. Automatic updates don't have to be implemented in the most obvious way, namely a manufacturer doing it for you directly.  Indeed, that is a major threat vector as you point out --- it's trading one major risk for another, and it's uncertain which is worse, the cure or the disease.  Are more secure ways available?  Of course!  Just a few minutes thought makes several possible alternatives pop up.
2. Once the point about security in a massively connected embedded world really registers, it becomes clear that automatic updates are unavoidable --- there simply aren't enough hours in the day for this to be done manually (only those in denial that there will be widespread object connectivity are likely to question this).   But time is the least of the problems --- the really big one is that beyond just a handful of manual updates, humans end up applying updates without much attention anyway, so the benefits of manual update evaporate.

Those two points made me realize that the topic of automatic updates has to be addressed, despite our aversion to having them done the traditional way.  The question then becomes how to do them automatically but more securely,  That's not easy, but the only problems worth solving are hard ones.   So, onto alternatives.

First of all, let's note that Schneier hints at a solution by recommending "no more binary blobs!".  He said it mainly in the context of providing security updates long after the product is not longer receiving manufacturer support, but it also has an architectural consequence --- updates would no longer come from the manufacturers!  That's beyond awesome, because whereas we can't control internal company code, we can vet our own to any degree we like.  If we can make "no more binary blobs!" take hold as a way of doing business, then manufacturers would have their blob sources in a public SCM, and we could construct automatic update systems that take output from known sources and don't kick in until there has been some degree of community vetting.  It would be up to us to determine the degree required, and the security arrangements in place.

Companies cannot be trusted to do this for our benefit --- it conflicts with their prime directive under the profit motive to screw everyone except themselves.   It also conflicts with hiring practices --- people who know what they're talking about are generally on the high end of the pay scale.  And doing good costs money --- total anathema for companies.

So there are ways forward, quite big ones.  But unless we take Schneier's message to heart, it's going nowhere.

Morgaine.

Morgaine Dinova wrote:

1. Once the point about security in a massively connected embedded world really registers, it becomes clear that automatic updates are unavoidable --- there simply aren't enough hours in the day for this to be done manually (only those in denial that there will be widespread object connectivity are likely to question this).   But time is the least of the problems --- the really big one is that beyond just a handful of manual updates, humans end up applying updates without much attention anyway, so the benefits of manual update evaporate.

 

Absolutely agreed, with the proliferation of devices there's no way I'd want to be doing every single one manually. But when you're dealing with physical systems that leads you to a couple of considerations that are much less important for most of the auto update features in common software today.

1. The device absolutely must not be able to be bricked by an update. Ever.
2. A failure in an update must fail back to the previous state. It should never leave you in a worse position than you were.
3. Updates to certain systems should not be able to be done without someone being physically present to verify the physical thing being controlled still works.

So while you might not want to have to manually upgrade 200 devices, it's quite possible that one of the requirements needs to be that a real person physically pushes a button on a controller located in the same building to initiate the process.

Then you need to consider fallback plans. Something like a traditional heating thermostat will usually have an easy way to override it if it ever fails. The connected version has many more ways to fail, whether that's by an external attackers action or by a manufacturer update. New ways of doing things will often mean you need to look at the contingency plans again to determine if they're still sufficient, or need replaced.

Security needs to be taken a lot more seriously, as things become more connected and as more physical things start to rely on that connection then the scope of the security requirement changes. It's no longer a case of just not being able to get to facebook and so a minor inconvenience. Things that we take for granted today like the physical security given by a physical lock on your door need to be revisited once that lock is a networked device, we can't blindly assume the same level of security when the threats come from very non-traditional attack vectors.

Very interesting discussion (much better than the 'upgrade').

We have a number of systems at work that are on seperate networks that don't connect to the world, or each other.

They generally don't get updated because a/ there isn't a reason to and b/ there is no connection to the world (and won't ever be)

So if this approach was to be employed, there would need to be some mechanism for updating of certain functions to be available.

I also start to wonder though, what is the life expectancy of these embedded systems.

The internal ram/memory must have a limited life, and if its not that then the passive components around them (ie capacitors) have a limited life.

So while it is nice to think that the embedded system that was installed 10 years ago is now supported by the Open Source area, is there any point (commercially).?

Mark

element14 leaks wrote:

So while it is nice to think that the embedded system that was installed 10 years ago is now supported by the Open Source area, is there any point (commercially).?

I worked for a PC manufacturer where, in the mid 90's, the manufacturing lifetime ranged from 3-6 months. That was a function of rapid change in specs and general improvement, but it does show that while a manufacturer may have obsoleted a particular model and moved on to the next thing those systems probably had a useful working lifetime of 3-5 years in spite of being largely unsupported within a couple of months of being built.

I can see many IoT style devices being replaced on the same sort of frequency as iPhones as fads come and go. Others like a heating controller might have a useful lifetime of 20+ years and only be considered for replacement when the whole heating system has reached the end of it's life.

For me, that's where the problem lies. At some point after manufacturing of that particular model stops, the manufacturer is going to drop support. Five minutes after the warranty expires seems normal    So what happens for the remaining 19 years ?  Not really a concern if the device is isolated...

There's currently no commercial reason for manufacturers to support devices beyond the warranty. So it's another place where the scope of the security implications has to be reconsidered, an unsupported device may be a big liability when it's visible to the rest of the internet.

thanks for pointing out this post by Schneier!

Drew Fustini wrote:

 

thanks for pointing out this post by Schneier!

It's interesting that Schneier's article mainly provides very strong reasons for moving entirely to open source software, but in so doing, it also backs open documentation because without it the software cannot be programmed securely.  And in turn, when everything is documented to reduce the likelihood of cuckoos in the nest, that makes OSHW more easily achieved as well.

Maybe NSA and CGHQ have done the world a favour, highlighting even more of the serious pitfalls of closed source.

Morgaine.