Digg this story   Add to del.icio.us  
Death to Old Software
Jon Lasser, 2002-04-03

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.

Report for Lastday
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


SecurityFocus columnist Jon Lasser is the author of Think Unix (2000, Que), an introduction to Linux and Unix for power users. Jon has been involved with Linux and Unix since 1993 and is project coordinator for Bastille Linux, a security hardening package for various Linux distributions. He is a computer security consultant in Baltimore, MD.
    Digg this story   Add to del.icio.us  
Comments Mode:
I don't like it. 2002-04-03
Anonymous
You are right. 2002-04-03
J. J. Horner
Death to Old Software 2002-04-03
Not Really Anonymous
Death to Old Software 2002-04-03
Reaten
Death to Old Software 2002-04-03
Steve (1 replies)
Death to Old Software 2002-04-03
Anonymous (1 replies)
I have a better solution 2002-04-04
A Debian User (1 replies)
I have a better solution 2002-04-11
Anonymous
Counting the cost 2002-04-03
Working poor
Death to Old Software 2002-04-03
Anonymous
Good idea 2002-04-03
Anonymous (1 replies)
Re: Good idea 2005-10-29
Anonymous
Death to Old Software 2002-04-03
Anonymous
Death to Old Software 2002-04-03
Paul Wouters
Death to Old Software 2002-04-03
CodePunk
a sane suggestion 2002-04-03
Anonymous
Very stupid, here's why 2002-04-03
Anonymous
What a horrible idea. 2002-04-03
Steve Briggs
Is it a bug or has it expired 2002-04-03
Anonymous
You have got to me kidding me. 2002-04-03
Anonymous
What about incompatibilities 2002-04-03
Anonymous
Death to Old Software 2002-04-04
Anonymous
Death to Old Software 2002-04-04
Anonymous
Death to Old Software 2002-04-04
Anonymous
Death to Old Software 2002-04-04
Anonymous
Monumentally *BAD* Idea 2002-04-04
Arne Flones
If it aint broke don;t fix it 2002-04-04
Anonymous
other options? 2002-04-04
Mac guy
Moronic iin the extreme... 2002-04-04
Anonymous
Death to Old Software - What a Crock 2002-04-04
Paul Mauriks
Death to Old Software 2002-04-04
Anonymous
Death to Old Software 2002-04-04
Chicken
Death to Old Software 2002-04-04
Anonymous
Death to Old Software... not in my organization 2002-04-04
Steven C. Buttgereit (sf@buttgereit.net)
Death to Old Software? 2002-04-04
Anonymous
Death to Old Software 2002-04-04
Anonymous
A really, really stupid idea 2002-04-04
Anonymous
Death to Old Software, you NUTS 2002-04-04
Anonymous
Death to Old Software 2002-04-04
Elf Qrin
Death to Old Software 2002-04-04
Anonymous
Interesting, but No. 2002-04-04
Chris Fairbairn
Horrible Idea !!! 2002-04-04
Anonymous
Bad Idea! 2002-04-04
Anonymous
Death to Old Software 2002-04-04
Paul
Death to Old Software 2002-04-04
Anon.
A Deepness in the Sky 2002-04-05
Adrian Close <adrian@close.wattle.id.au>
Death to Old Software 2002-04-05
wwb
Death to Old Software 2002-04-06
Grant Bayley
DJB does it right 2002-04-07
Anonymous
Extremely bad idea: here's why... 2002-04-07
Anonymous
Death to Old Software 2002-04-08
Anonymous
Availability, mate... 2002-04-09
Anonymous
Death to Old Software 2002-04-11
Stephen
This already has a name! 2002-04-11
AnonymousG
Death to Old Software -- Not 2002-04-11
Anonymous
What we REALLY need... 2002-04-12
BAShMaster
Death to Old Software...HUH? 2002-04-12
Anonymous
Print an expiration message 2002-04-17
Computer Science Tory
Pathetic 2002-04-19
dw
Death to Old Software 2002-04-20
Anonymous
Death to Old Software 2002-04-20
Anonymous
Death to Old Software 2002-04-21
InterWN Labs <interwn@interwn.nl>
Death to Old Software 2002-04-22
Greg


 

Privacy Statement
Copyright 2010, SecurityFocus