Security updates for embedded systems [LWN.net]

Security updates for embedded systems

Posted Sep 6, 2006 16:49 UTC (Wed) by ortalo (subscriber, #4654)
Parent article: Security updates for embedded systems

Security updates, security updates, security updates...
This is an endless race, one you cannot win. Maybe I am getting too old or maybe I am simply getting bored at monitoring updates and their potential failures or even the updates to the previous updates (the last case, admittedly, never for Linux systems...).
However, I am definitely getting bored with security updates. I am a real-life computer security officer so I need to use systems that do not have security faults.
And no, I am not dreaming. This update frenzy started somehow 7-8 years ago.

Before that, everyone in the security field was looking after eliminating security bugs, gathering security assurance, using mandatory access control, extending code audit, using formal methods, discussing law enforcement, modifying contracts to incorporate requirements, educating users, and I certainly forget a lot of other nice and/or tricky ideas.

Nowadays, much of the energy surrounding systems with security requirements is targeted at this useless update race while it could be much more useful elsewhere in the security field. Do you really think patching a (t)ftp server will ever be truly useful for its security if your requirements simply imply that you cannot use the (T)FTP protocol? What about *not* using an application? Oh, btw, anyone has heard about the money problems of the OpenSSH project developpers?

Maybe it is time to face our responsibilities: switch *off* updates, *shutdown* vulnerable systems and go after those that deliberately refuse to introduce security requirements when they were necessary (either to fire them, to ask for reparation or simply to flame them).

You know what? This is one of the main reasons I still think that Linux cannot compete with OpenBSD with respect to security. And, this is not a problem: the reverse is certainly true for other kind of requirements.

You know, I don't ask for any change at all (albeit a minor one). Personnally I really enjoy using and loving 2 very good different systems!
Sometimes, as a computer administrator or developer, it seems to me that anyone needs to learn that he needs to use something *else*.
Oh, and switch off those damn security updates to replace them with software upgrades (cryptographically signed of course).

(Log in to post comments)

Security updates for embedded systems

Posted Sep 6, 2006 17:43 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

So could you please comment on the example I gave above? (DSL router with two issues: (1) bug in the dns proxy server, not security hole, but hurts some of the users, and (2) a silly loophole left intentionally by the system's builder (or not removed unintetionally).

If you start to make too strict requirements for a small gadget, it will fail to work. E.g: you need a simple method for the user to recover the master password (or equivalent) in case it was forgotten.

Nither of those issues have anything to do with the basic OS. Your favourite OS does not seem to share your sentiment: http://openbsd.org/security.html#39

Security updates for embedded systems

Posted Sep 6, 2006 20:18 UTC (Wed) by ortalo (subscriber, #4654) [Link]

Concerning (1), I'd like to know easily if I am one of the users hurted. In fact, I'd like much more information on the risks associated with a security issue than on the administrative actions I "must" do "immediately". (Even my boss does not use these words!) This is of course due to the fact that risk management is essential to decide what to do (either spend time on the administration and patching or elsewhere) and sometimes it depends on the overall architecture - something the distribution maintainer or the developper cannot know in advance.
Note that proposing a good risk evaluation is certainly pretty difficult. Currently, the general attitude (especially outside of open-source software) seems to be: no risk until the bug is fixed ("no disclosure") and maximum risk afterwards ("apply all fixes immediately"). Of course, this is absurd. System administrators are humans, they *can* cope with uncertainty pretty easily.

Concerning (2), this is a clear indication to me that the system builder should be avoided due to unresponsible behavior. You need guarantees and the presence of a loophole is an indication that your guarantees are void because you cannot trust the furnisher. You shouldn't have bought the system in the first place so you probably need to review your purchase procedure too... You can continue to use the device, but maybe not exactly to do all you wanted to do...

I do not really agree with your second paragraph. Requirements should be good or exact (adapted to the covered risk), but they may be very strict without compromising the success. If you look at mobile phones for example: the bluetooth stack security is usually pretty funny (at least, not very strict and not very convenient isn't it?), but the GSM security protocol with the operator is older and very good (and you *can* recover the PIN code). Maybe that's because the monthly billing amount was involved?

Finally, yes, it does not really have something to do with the kernel itself. More with the entire system. Note I do *not* have a favourite OS - I really like both Linux and OpenBSD. (Security requirements are not always in first place for me, of course.)

The OpenBSD "updates" are also pretty interesting in their form don't you think: they are *only* available in source code patch form. It implies a lot of non-obvious things: they are nearly useless on a running system installed only with binaries, they open by default with a text editor (and you can see the extent of the problem and the complexity of the solution, e.g. comparing the impact of 2006-006 with 2006-009: 30s), dependencies with other source code is dealt with on your *own* computer when you rebuild the (entire) system. In fact, much of the security management is left to the end user and he is provided with information more than with replacement programs. Linux systems have much in common with this (a good thing imho) but they tend to "like" binary updates too.

Most other commercial systems only offer binary "patches" and I wonder if anybody really cares about what's inside. Nowadays no one questions anymore the general consensus "it must do more good than harm". My problem is that I question this consensus when I am on my provocative day...

Security updates for embedded systems

Posted Sep 7, 2006 6:04 UTC (Thu) by grahammm (guest, #773) [Link]

For recovering the master password, the solution is relatively simple. You have a hardware way (eg keeping the reset button pressed rather than just press and release) to locally perform a 'reset to factory defaults'. OK, this not only resets the password but also the user has to re-input any configuration etc.