,
We all know that outdated network software is security hazard. The solution: hard-wired expiration codes that self-destruct an old program when it's past its prime.
Software lives forever. This is its blessing and its curse.It's a blessing, of course, because it's what separates software from automobiles, houses, electron microscopes, and other marvels of engineering: no wind and rain to make code rust, and software has no moving parts to wear out.
But it's a curse because its perpetual readiness frequently entombs the user in an ages-old software package. If nothing else, the whole Y2K bug experience reminds us how long code lives when left unchecked.
Which is why I think it's time we consider what may seem on the surface a radical idea: building time codes into all open source networking and security software that causes it to "expire" like a Blade Runner replicant when it reaches a certain age.
This idea has been used before, but primarily in software licensed on an annual basis, or shareware that expires after a given time period has passed. Appropriating it for open source software would solve a number of security and reliability problems.
One of the big problems with open source software is that, without a base of registered users, it's difficult to ensure that users have actually patched their software for the latest security holes. Unlike Novell, who can find all licensed users of their server products and impress upon them the importance of a security patch, you can't even tell who's running any particular open source package.
The lag between discovery of a serious hole and the time that script kiddies can use an automated exploit to root systems is sometimes substantial: in the case of one bug, the rpc.statd format string vulnerability, the lag was two to three months.
While it is unlikely that an exploited package will expire in precisely this time period, the rpc.statd hole is still being exploited on the Internet today, more than a year and a half after the hole was first exploited. My home systems are typically probed for this vulnerability at least once a week, and sometimes several times a day. As I write this, it's been less than twenty-five hours since the last attempt.
Crackers wouldn't still be attempting to exploit the hole if systems weren't still finding vulnerable systems. But if network daemons such as rpc.statd were "renewed" on a yearly basis, crackers could stop wasting network bandwidth and security professionals' time with these outdated attacks.
Interoperability is another critical issue that would be well-served by expiring old software. Code simplicity could be enhanced by requiring a much more limited degree of backwards compatibility than is typical today.
To illustrate this, I have a user whose tools of choice are PGP 2.6.3i and Commercial SSH 2.3, because he feels that these have the best interoperability with other tools.
In the case of PGP, most users of other PGP versions can read his messages. However, rare is the conversation where this user fails to complain about his inability to read other peoples' PGP messages --- because the packet formats used by PGP 7.x and Gnu Privacy Guard differ substantially from those used by the older versions of this software.
In the case of SSH, the installed base for OpenSSH has increased so enormously that he faces persistent difficulties interoperating between his version of SSH and those typically encountered in the field.
My feeling is that this user should take on the one-time difficulty of replacing his keys if necessary to help the cause of compatibility. An expiration date would make that happen.
Open source being what it is, nothing can stop dedicated users from removing the expiration code from their packages. In the case of stalled development, this may even be necessary, and it can serve as a safety valve to help offset the dangers of software expiration. This makes it fundamentally different than licensing schemes that permit automated remote disabling of software packages.
With software patching in its current state, this might sound like the System Administrators Full Employment Act of 2002. But surely if this scheme was widely adopted, software update techniques would improve quite quickly. Imagine Debian's apt-get tool, but with automated verification of GPG signatures on the packages.
One downside of the software expiration scheme is that it would discourage mature and responsible software development techniques: developers' attitudes might always be, "I'll fix that in the next release."
Then again, maybe things wouldn't be so different.
'Don't Call Me Jon Boy': Lasser responds to CISSP criticism