Should Open Source Software Expire?

Daffy writes "Jon Lasser at SecurityFocus has an idea for combating the tendancy most sysadmins have to leave old versions of software running long after they're known to have security holes. He proposes implanting time codes into all open source networking and security software that cause it to "expire" like a Blade Runner replicant when it reaches a certain age, forcing an update."

Comments

Bad idea

[drodver]

Open Source is about not forcing you to do anything. Besides the code could just be removed. Who is a developer to say how I should administer my box.

Re:Bad idea

[Galen Wolffit]

Oi, I agree, but for different reasons. Yes, the code could be commented out - so what? Any code that secures an existing hole can be commented out, thus re-opening the hole.

I think it's a bad idea to actually _disable_ a running program, because doing so can cause problems that are not necessarily immediately traceable back to the disabled program. Instead, the program should raise some sort of persistent alert, via email, logfiles, or whatever, at some interval, alerting the administrator that there is an out of date program running.

Oh yea, THAT'S a great idea...

[xyzzy]

As if being kept on the upgrade treadmill by Microsoft isn't bad enough!

You can't pick an arbitrary point in time when software is "too old", or "known to have security holes!" If you could do the latter, you'd just fix the security holes...!

Erm, no

[adamwright]

I have old internal boxes that are way way out of date, but safely firewalled away doing just what I want them to do. Rebuilding those every few months/years (or having to remove timebombs from software before I install it) == Bad idea.

I agree that software should assist admins in keeping it uptodate, but honestly, legitimate users shouldn't be affected if an admin is incompetant or lazy.

Re:Erm, no

[swb]

Not to deflect the conversation too far away from the original, but that is why good security practices are more than just about code. Where do you keep your servers, and who has physical access to them is an equally valid concern.

So are things like maintainability, usability and so on.

Security is a kind of risk, and everyone accepts a certain amount of risk. I *could* insure my car to a $50 deductable and let the insurance co. take all the risk beyond that, but that would cost me $500/month. Instead I assume $500 worth of risk and I pay only $100 month.

You're absolutely right that there are other concerns, but in some organizations the costs associated with a specially locked room, time/money/effort maintaining boxes is more cost than percieved risk that some internal user in a 50 person company may decide to try to hack sendmail 8.9.

Or not

[klosskorban]

Why not just have it a feature of your package management system? IE. the not yet finnished, PKGtool 2.0 system

Great Idea

[dgb2n]

This is great.

I have a similar idea for my car. You could design an oil system so that once the car had been driven more than 3000 miles, the car automatically drained all the oil from the drain pan and left the engine without oil.

This would prevent a careless driver from driving with oil that no longer provided sufficient viscocity.

Your kidding

[lkaos]

So, you want me to tell my boss that our web server is free software and has expired because the people writing the software figured by now it would have a bunch of security holes?

That's gonna be easy to sell. I can just imagine it.

Boss: "Why did our server go down last night!?!?!"

Me: "Well, it expired."

Boss: "It free for Christs sake! How does the d*mn thing expire if we're not paying for it!"

Me: "Well, the authors figured that by now, there would be a bunch of problems in the software so they want us to upgrade it, it's really a good thing."

Boss: "I thought this free stuff was supposed to work, not be full of security holes! We're switching to IIS!"

Log It Instead Of Expire It

[Samarkind]

What if the system were to log the last update for all packages to a central file that could be polled by the admin? Or email the admin once the software reaches a certain age? I doubt many security patches are deliberatly not applied, but most admins are probably overworked as-is and would appreciate a gentle nudge to check for security updates on a piece of code that they normally don't look at too often because it just works.

Sounds nice. Has problems

[pete-classic]

I understand that you have good intentions with this idea. Unfortunately there are more problems with this than you can shake a stick at.

First, there is a name for software that is going to be deprecated in a foreseeable time frame. That name is "beta." If you are writing software with the belief that "in x months people will be better off not running this" you are doing something wrong.

Second, what if you write a really great program, and you put this "feature" in it. The program is great. People love it. They depend on it. And it doesn't have security problems. Meanwhile you get married, have triplets and move to the Amazon. Then your little "time bomb" goes off. Thanks a bunch. Now it falls on "someone" to rip the thing out. Not good.

There are any number of other problems like:

• People's clocks don't all agree
• What bugs might you be adding by putting this code in there that doesn't enhance the program's operation?
• Sometimes people need older versions to meet more important dependencies
• Who knows what else?

This is all outside of the fact that I (like many others) don't care for software that thinks it is smarter than I am. That's why I run *NIX in general and Free Software in particular in the first place.

Bottom line: Sounds nice. Makes more problems than it solves.

-Peter

how about we let admins do their job

[moore234]

I am sick to death of folks using technology to try to solve people problems. All this indicates is a flawed understanding of the problem.

For example, the issue here is not binary. Security is not the end all and be all--folks should have the freedom to make informed rational decisions to make their systems less secure. Perhaps it's just a web server and not mission critical? Perhaps they need an older version of java to run an older program that they need. Knowledgeable admins should have the freedom to make that choice. Don't force policy via technology.

But this is indicative of a larger trend to look at technology to solve all our problems. Have sex offenders in the neighborhood? Make them wear beepers so that decent folk can know where they are! Have mental health problems? Take a pill! Folks speeding? Put up those goddamn speed cameras!

Rather than dealing with people on a personal level, we use technology to dehumanize interactions. I think it's because technology is easier to understand. It's not as complex as humans are. Technology also scales better than personal interactions do. It lets us do things more efficiently, but, mon dieu, what kind of world are we creating?

Dan

Re:Absolutely

[tswinzig]

The only downside I can see is what happens when you've using some software and the developer stops developing it....your software passes its expiry date...no updates are available... what then?

What then is that you realize what a horrible fucking idea this is in the first place.

To drive a car, you need a driving license...

[DocSnyder]

...to run a publicly accessible Internet server, no proof of qualification is required at all. In my experience, the worst security threats are neither open-source nor closed-source software, but the people who run it. Open email relays on Sendmail 8.8 (open source) oder Exchange 5.0 (closed source) with non-working postmaster recipients and dozens of open TCP/UDP ports show that their admins don't care at all about their system, they even seem to forget that it is connected to and reachable from the Internet. They will find it slow and unreactive, but they don't even have the slightest idea what could be wrong. Out-of-the-box systems which don't require even basic network knowledge are even worsening this problem - so if at all, include expire-features into these systems.

If providers of hosting and connectivity services require their customers to prove their knowledge with a standardized certification, the Internet would miss thousands of unsafe and dangerous systems, and upgrading server software will be one of the basic tasks of a qualified administrator.

AFAIR on the former FidoNet a few years ago my uplink really wanted to know if I was competent enough to run an official node, and FidoNet wasn't too easy to understand either.

Bad security too

[Zeinfeld]

The assumption that newer versions of programs are more secure is simply wrong. I have had several systems break after someone replaced a verified secure piece of code with an unverified insecure one.

Case in point was when someone decided to install the latest version of sendmail with the usual horde of bugs over a version of QMail.

The biggest problem when someone downloads new versions of software however is that they are typically installed with the wrong defaults or insecure defaults, or they blow away parts of the security profile to allow them to be installed.

The type of system build I would typically use probably has less than 10% of the typical Linux distribution. The eliminated portions are gone for good reason - if the feature isn't needed it goes. So having someone reinstall the components I have removed is a major problem.

The other issue to beware of is any form of automated update that does not have very stringent controls to validate the authenticity of the replacement code. Otherwise the update mechanism becomes a potential backdoor. Don't believe that downloading the latest source via FTP is the solution either. All I need to do is poinson your DNS and you are downloading the version with my trojan.

What is needed is some form of software resource database that keeps track of the version of each software package installed, differences between that and the standard installation etc etc. Ideally there would be integration with something like tripwire. The ideal would be to have the type of mechanism that the .NET security framework has in which you can require software components to be signed by an authorised source in order to run.

Building and maintaing such a system would be very tedious and expensive to do well however, if it isn't done well it is no good.

The sell by date proposal is simply clueless, the guy does not appear to have much real security experience, he is just repeating the dogma.