As a sysadmin who actually does update software, this strikes me as a really bad idea.

There's two ways of enforcing expiration (that I can think of, in any case). The first is to make it completely impossible to use the software after an expiration date. The second is to inform the software user or sysadmin about the expiration, and possibly make it slightly less convenient (i.e. messages on startup that must have input before starting the program).

The first possibility solves for the stated problem (sysadmins and users who continue running outdated software, esspecially software that may contain security holes) but removes the choice of using that software from the sysadmin/user. There are good reasons why a sysadmin or user may choose to use an older version of a program. Backward compatibility, removal of necessary or preferred features from newer versions, hardware or other system limitations and/or the total lack of a newer version of software (granted, many open source projects are very stable, but there have been plenty of exceptions) are a few possible reasons for this. A responsible sysadmin or user will educate themselves on the risks of doing so and take measures to prevent this. Unofficial patches, protecting the machine at the network level, and similar measures *other* than upgrading can often migitate or eliminate security risks.

No programmer can possibly forsee *every* way their code will be used, and my experience has been that programmers are generally unlikely to think of a lot of the circumstances code will be used by sysadmins in particular, simply because the two jobs are very different. This is not a criticism of programmers. Sysadmins don't often think like programmers, either!

Thus a piece of software that permanantly expires either becomes useless to the sysadmin or user, and the responsible sysadmin or user will either avoid the software completely from the beginning or find an alternative that does not expire. Alternatively, they may either remove the expiration code from an open source software package, or have someone else do it for them, completely negating the expiration in the first place. This still is inconvenient, and makes the software less useful than an otherwise identical package that does not contain the expiration in the first place.

The second option, warning the user or sysadmin and/or requiring input or otherwise making it annoying but not impossible to use the software, doesn't solve for the problem. The responsible user and sysadmin will only find option annoying if they must use the software past the expiration date (for the reasons outlined above) and the irresponsible user or sysadmin will simply work around the problem (hey, if security holes don't scare you, having to use expect in a startup script probably won't, either) completely negating this 'solution'.

I wish there were an easy solution to the problem of sysadmins (esspecially) and users who run software in an insecure manner. The only solutions that I see are partial and, taken together, complex. Educating users and sysadmins in as many ways as possible, ISP involvement to prevent customers from acting in ways that harm other folks networks (both dealing with people who are actively trying to break into servers or networks not their own and in dealing with customers who, through ignorance or laziness, are allowing things like Nimda to chew up other people's bandwidth) and holding sysadmins and users reasonably accountable for security at the institutional level without expecting the impossible does a great deal for general security.

Easy solutions are always tempting, but in this case I do not believe there is one, and if there is, making software expire like last week's spoiled milk isn't it.

Vinnie



[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/72/11667#11667