Slashdot Mirror
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."
I think that the premise that all computers are exploitable is a wrong one to persue. Granted, any idiot that leaves an exploitable machine running on the net gets what he deserves, yet in this age of DDOS viruses/trojans, the damage goes far beyond a single machine. BUT, I dont think FORCING an upgrade is the way to go. If I have a machine on an internal network merrily pluggin away for years, why break it if its working?
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.
Interesting idea, but the assumption that people will only want to run newer software seems a bit flawed to me. To quote the genius Anonymous, "Assumption is the mother of all fuck-ups."
Last night I installed RH 6.2 on an old P75 I picked up somewhere, and ended up installing an old version of openssh on it (along with a bunch of other older stuff) to save disk space. Under this scheme, I wouldn't be able to; despite the fact that the machine is behind a firewall, I'd be bullied into running larger, more secure software.
The computer is mine. The software is mine. And, should there be an issue, the blame is mine. I don't want anyone who thinks they're smarter than me fucking around with my computers. If I did, I'd run Windows, now wouldn't I?
--saint
Wouldn't it make more sense to include something that checked the web for available updates and presented them to a sysadmin as an option or a recommended upgrade. It's silly to have something "expire" when it can just be patched or upgraded.
Just because there's a newer version doesn't mean it's better for an individual's purpose than what is currently being run. It could even break a mission-critical application.
Just what we need -- another group of folks making decisions they have no reason, right or responsibility to make.
Write software, let the users who deploy it take the responsibility for making changes. Or is individual choice and responsibility no longer important?
One ring to rule them all..the O in OpenBSD
I've often thought that expiry times in software would be a good thing. Not nessesarily in Paid for software, but in free software where free updates are readily available. Would be great for the web.... imagine knowing that you will never have a Netscape 3.x or IE 3.x visitor to your site again... or knowing that on such and such a date you wont have to support Netscape 4
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?
I don't think the software should automatically update itself or expire, but rather have some way of communicating with the sysadmin. For example, if you use the CPAN module for perl in shell mode, it'll tell you if there's a new version of itself available, and how to update. Most importantly, it does so unobtrusively (as opposed to some programs that get annoying about it).
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
Gnumeric had something like this.
I was running an old version, the one that comes with a default slackware 8.0 install.
On opening, it popped up an alert saying "This software is old, and has probably been updated by now! Check out gnumeric.org for an update."
No hassle, just a one-off friendly reminder.
Good idea, I thought.
Maybe it's not an idea totally devoid of merit for binary installations, but for installs that included compile steps, it just doesn't seem to make sense.
However, I'm curious what
It'd be difficult to co-ordinate, and would work best in some sort of centralized location (or, at least, in a few locations. maybe by OS (Linux tools) or by application (I'm thinking logical groupings of apps here).
what do ya'll think?
mmm... yeah... You see, we're putting the cover sheets on all TPS reports now before they go out...
I think the biggest problem with such a model is that it places the emphasis on forced compliance to software renewal, rather than on making sure your users are informed and participating in the program's community. Now that might not be happening now, but it doesn't mean it can't or doesn't happen. Free software is based on ideas like that, and by forcing, rather than encouraging, partcipation I think you loose some of the value of a fs/os programming.
Every time medical company (i.e. a drug manufacturer or a medical device manufacturer) implements new software, even if it's just an upgrade to, say, their call handling software for their tech support department, a validation process has to be performed. This includes:
a risk analysis to determine HOW much validation has to be done according to how much harm can be done (and yes, there is harm even in the tech support software)
creating a test plan
testing the software to make sure it works to intended use
completing validation paperwork documenting that the testing was actually done
creating a validation report and test summary detailing your findings
keeping all these records on file for a long time so the FDA does not land on you like a hungry 2-year-old on a twinkie
If you're a medical company and you DON'T plan on doing all this, you can expect a write-up (which must be responded to) at your next FDA audit. If you don't respond to the write-up, hire a lawyer cause the FDA is gonna shut you down. This is a large part of why we've kept around some of the DOS applications we use--no one here has the extra time to do all the validation on new software.
Denver Isuzu Suzuki
I can just see it now ...
Detective: How did he die?
Coroner: Well ... he was running 2.0.3 of UberPace. You know, the Open-Source pacemaker software. Well ... he should have upgraded, but forgot.
Karma? Karma? I don't need no stinkin' karma.
If I'm runing a cacheing DNS server on my loopback address, it's a waste of effort to upgrade it even if it has as many wholes as a wheel of swiss cheeze, or worse yet, a M$ OS. Also, I disagree with the premise that "most sysadmins" tend to neglect security patchs & updates. Besides.... It's like the counterproductive logic involved when M$ releases a patch to protect agains DOS attacks that crashes 25% of the boxes it's installed on. Here your talking about crashing a box semianually to protect the person from getting hacked. Basically, the person was allready hacked when they installed the termlimited software. Trojaned if you will. It really must be a slow news day.
OK, I think we'll all agree that the vast majority of servers that've been exploited and abused for a long period are in the hands of luser admins. Savvy admins get burned all too aften as well, but they usually catch it and patch their systems before too much time has elapsed.
Think about it... how many SMTP open relays are still running that have been spew points for years? How many Code Red hosts *still* probe your hosts, after all the hype and months gone by? How many hosts can you find that are listening on port 12378 (Gibe worm/trojan)?
The "admins" of these systems have *no clue* what's going on and LARTs fall on deaf ears at their luser ISPs!
So. My proposal is this: Include disabling timeouts on *all* net connected ware, enabled by default. Put a nice, little checkbox in an unassuming corner of a/the install screen (or a line in a conf file somewhere) that allows this "feature" to be disabled.
I figure all savvy admins will turn the feature off. Some of the luser admins will turn the feature off. A majority of the lusers won't even know it's there, and won't disable it. To bad for them, but they'll have a cluestick swingin' their way in a year or so.
I still don't think it'll fly (no one's going to build this feature in), but the above is my spin on how it might be made to work, after a fashion.
-
I would have to agree that hiring better sys admins in the first place is a viable solution. However, there are boxes sitting in the basement of some companies that people don't even know about most of the time and paying a sys admin to sit in front of it is a waist. And when the company eventually does realize it exists months or years later, it's only because it stopped working.
If there was some OPTIONAL scheme to give the developers of software a way to update their own software (updates as in fixing buffer overflows, etc) out there without sys admins needed. In other words, leave it up to the developers of the software to EASILY fix their own horrible mistakes. This does not include upgrades - more like fixes.
In a way, giving the software the ability to phone home to its developer for critical updates would be extraordinarily beneficial. Of course, this will easily fail if developers abuse the system and do more than just fix bugs without changing architecture.
I can see a single, open source system that all developers can use as the perfect solution. It saves money, and it gives the developers the ability to compensate for their mistakes.
Agreed, there's plenty of room to criticize this.
...but perhaps network-accessible daemons should check magic hesiod (DNS) records before servicing requests, disabling themselves if the magic hesiod record says "You're insecure. Go away".
I don't want planned obsolescence, independent of whether software is secure or not - that would MASSIVELY increase our workload here. But I wouldn't mind software that automatically turns itself off when the maintainer says "that version's no longer secure".
Sadly, there might be a temptation to use this for forcing upgrades that aren't security-related. That'd be a mistake.
It's possible there should be a config file that specifies how important security is to a site. If the config file says "security is priority 0", anything even slightly insecure is disabled. If it says "security is priority 100", only really critical stuff (like remote root) is disabled automatically. 75 might mean "remote, but not root", 50 might mean "local root", 25 might mean "local but not root". Maybe priority 200 should mean "never turn anything off, ever". Or something like that. Maybe there's no good reason not to use a larger maximum, like 2^31 or something - there may be a desire to squeeze more priorities in there, and it'd be easier to expand at the outset, and there's not much penalty for making it a wide range from the start.
If a service is already internet based, perhaps there isn't that much reason not to depend on the (cached) DNS in this way. If the hesiod records are cached, no big deal - that's still much better than running insecure forever. The maintainer can also control the TTL of his/her security-related hesiod records I suppose.
The config file should probably also say what to do when a yea or nay hesiod record can't be found, because someone could pound the maintainer's DNS servers into oblivion to gain access to your insecure stuff - for some that means "turn it off fast", while for others it means "Eh, it's probably just another machine that fell off the net. Service requests anyway".
This kind of makes a "is this version later than that version" comparison function desirable. Alas, software packages are numbered by many different methods, so there is no one true comparison function for this purpose. However, if a library is developed for this kind of check, it could include comparison functions for the predominant software version schemes.
I suppose the software should mail someone if it turns itself off. This could again be specified in the config file, defaulting to root@localhost, postmaster@localhost, and anyone else who seems distantly relevant. You might even wall the system about it if the admin was too lazy to specify an address for notifications.
There's already been a lot of talk about what a bad idea this would be if every service on your box ups and dies because it thinks it needs to be upgraded, nitification vs. death, etc...
I don't recall anybody talking about what it's like migrating server *admins* though... If I'm coming in on a new admin job, I think I'd like to have some kind of system in place where I could run a check on everything running on my system and have it report version, install time, last modification to the config files, etc, instead of having to hunt everything down manually.
Here's my suggestion: Install a time-based notify bit with each new app or service installed on a machine. Make it part of the RPM manager or something. Make it optional - I don't so much care if there's a new version of Armagetron available, but anything that has to do with a critical security or connectivity service, yes, please. During install, I click a little option box that says "Remind me to look in on this service in a few months."
A few months later, the admin gets a notice - time to look and see if there are any patches to (whatever).
And if the server admin goes on to another job and someone else steps in, he or she can just query the application installer - how long has it been since the last update to the firewall? Or the Virus scanner? or whatever? His transition into the center chair just got that much easier.
I mean, with all the non-admin projects my own poor little admin gets stuck on, it's a wonder he can keep up with security issues at all. It's easy to get distracted from your actual job by orders from the people at the top who forget that you are, in fact, just one person. It's that devilish "other duties as required" clause that gets built into every job description...
Do it at the level of the installer, or the compiler, or whatever you use to turn a downloaded file into an executable thing. This time monitoring code is only relevant when somebody installs it, after all. And if the standards (if any are actually established) change, then every programmer in the world has to keep up on it... Let the programmers program the app. Let the admins admin the app running on their box. This is an admin feature. Let it be so.
GMFTatsujin
Also, what if it's "business critical" and the software decides 'I won't work anymore'? I'd hate to have my iron lung running open source expireware.
That way i'd have to configure each piece of software, or make it all depend on a special configure file. Anyway i don't find it appropriate to patch each app in such a way. It'd be much easier to regularly run an 'expire' job that simply updates a list of expired software (from the net) and compares it against the versions in the rpm-database.
...
Then the user/admin can decide what expire should do: maintain a list of expired software (maybe with different warning levels, from "obsoleted by a new version" to "security hole, patch now"), mail him, shutdown the service, update automatically (shiver), whatever. The admin can also decide how often 'expire' should run, or, in case of a static ip, maybe even allow the 'expire-server' to contact his machine.
The method of comparing against a list on the net (or maybe on some update media) is better than expiring after a preset time. And selferasing software is simply nonsense. imagine software development is discontinued, or you just can't reach the net, and thus not update anyway, or an admin is on holidays. He'd probably prefer the firewall up and running, even if outdated, than having no firewall at all.
Also maybe other projects depend on a certain piece of software. Forcing to switch versions at some preset date isn't helpfull at all in that case. There are so many possible reasons why someone might want to hold onto an old app a little longer, maybe even for 20-30 years. This "force to upgrade" practice could come right out of microsofts book of marketing, but it doesn't make sense for open source software.
Maybe he should've written that piece 2 days ago
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
Windows 95 had to be re-installed about every 6-8 months in a heavily used environment, because it self-destructs and crumbles apart. NT Server 4.0 fares much better, we had one Compaq Proliant that was installed with NT4 in 1997 that did absolutely nothing but serve network printer queues and has not had its configuration altered in years, however it finally came down with the operating system equivalent of Alzheimer's or CJD/BSE last autumn and we had to fdisk/format/reinstall to fix it. The other four NT4 boxes that were installed at the same time and got a lot more varied operations and configuration changes during their lifespan only lasted from 2.5 to 3 years before they suffered nervous breakdown. Now we plan on a re-install every 2 years of continuous operation.
While I agree with the rest of your post, and I think some people are using medication to solve the symptoms of their problems rather than fix the cause, I myself have a mental illness that is almost entirely chemical based, and therefore is impossible to treat with anything other than medication. Sometimes the easiest solution is the right one.
ph33r...
_____
|--` ()_)
| ()__)
| ()___)
|-. ()__)
\ \
|_)
"If he thinks he can hide and run from the United States and our allies, he's sorely mistaken." Bush on bin Laden