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."
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.
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...!
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.
Why not just have it a feature of your package management system? IE. the not yet finnished, PKGtool 2.0 system
Need help finding the flow? http://www.myspace.com/naturalismandbalance
it might work for beta and test versions that aren't designed to be used in place of the final version.
when it expires? pay someone to generate a new code to extend it's functionality?
... guess what, tons of exploits, but the boxes haven't been 0wn3d yet.
... i thought expiring software was called trialware ... i don't intend to 'trial' software on a production machine, only to have it stop functioning christmas day
sorry, but some companies purposely continue to use old software. shit, we have a lot of solaris 2.5.1 boxen around here
besides
I have no problem with it. Anyone who has the brains to hunt through the source and remove the time limit should also be smart enough to understand the consequences of such an action. People who are not smart enough to do it themselves (or hire someone who is) should be grateful for whatever they get. If they whine about it, you can always offer to refund the purchase price.
Assume a worst-case scenario: would you want the software (some of it critical) on your machine to expire if we end up living in a law-induced dark age?
Personally, I want my 60MHz Pentium server to run for as long as *I* want it to... not as long as some third party (whether that be a hardware developer, a software developer, or the government) wants it to run.
Of course the nice thing about OSS is that you'd be able to remove the code that expired it.
MJC.
The computer is mine. The software is mine. And, should there be an issue, the blame is mine.
*BUT*, think CodeRed/Nimda-like - your problem could also become mine and I sure as hell don't want that!
---
Information wants...you to shut your pie hole.
There's some cases where there's no need for the program to be updated, no matter what securiy risk it might pose.
If it's sitting in a lan that has no acess to the internet, or if it's being used in a case where space is limited... there's probably other reasons that software shouldn't expire.
How would you like if your computer decided that it wasn't going to run a critical (to you) program and you have to stat reinstalling it while a deadline creeps closer.
Maybe a reminder service would be the best way, after so many days/months/years it makes a reminder to check for updates. That, or educate people that upgrades for securty are a good thing in some cases.
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.
This seems to be a better idea...what would happen if the sysadmin "expires" prior to the software? Company shuts down? These things must be able to carry on without us...
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!"
int func(int a);
func((b += 3, b));
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.
Why not just have it a feature of your package management system?
Because it would be foolish for a SysAdmin to load fixes/patches without testing them first. There have been occasions in which a patch will break something else that the application does. (Checkpoint FW-1 patches are notorious for this) There have been patches that are issued and then recalled because of problems with the patch itself. Who would want to put production systems at risk by having critical code installed automatically before the SysAdmin would have the chance to test it.
If someone wants to implement something like this, all I can say is that I hope you take regular back-ups and validate your tapes.
You will need them.
*** Where are we going? And what's with this handbasket?
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:
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
Hell no. If a system administrator is too stupid to upgrade buggy software like bind and wu-ftp for security reasons, he's definately too stupid to realize his dns servers stopped working because bind expired.
Common sense is not so common.
It seems to me that there are a few needs here:
1) Having an upgrade system that's easy enough that sysadmins won't dread it and put it off till it's too late. (I run dselect on my machines on a regular basis, and ... at least once you've slogged through the package list and gotten just what you want on your machine ... I think it's a great sytem)
2) Getting sysadmins in the habit of using the system regularly.
Perhaps a good solution for number 2 would be to have a standardized system (which is installed and set running by default) for alerting the sysadmin if they've gone too long without checking for an upgraded version of a piece of software. Once a day, a cron job checks to see if it's been more than a week or whatever since the packaging system was run to check for updates, and if it has been that long, the admin gets an email every day reminding tehm to get on the stick.
Better yet, a cron job could run once a day to check whether any upgrades were available, and if so, send an email to the sysadmin to tell them to upgrade. (I wouldn't advocate automatic upgrades, because you never know when something requiring a little human intelligence is going to happen--rare but not unheard of).
The remaining issue would be custom-compiled software that you can't just grab using the packaging system. For example, I've got a custom Apache installation with PHP, mod_ssl, etc. built into it with all the options set the way I want them. I've built my own compile and install script to automate rebuilds whenever I notice that one of the components has an upgrade available. If the OS could provide some standardized service for each of the components to check for updates and email me when one is available, the process would be almost 100% painless.
Convert RSS to HTML - integrate webfeeds into your website
You are assuming that everyone has internet access - don't!
If this ever hits the world in any form it will be patched out of existing before the first user download.
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
Rather than having it expire, why not have it query the "parent" server where the project is maintained. If there is an update, the software could automagically generate an email or equivalent for the local admin saying that a new version is available. The admin isn't forced to update it but does receive new version notices. The package should probably also generate a message for the admin if it can no longer contact the parent server (i.e. libET can't call home.. sorry, couldn't resist..)
All of these would need to be configurable but that's for the individual admin to determine.
Planetes
"One World, One Web, One Program" - Microsoft Promo Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitl
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.
"And like that
is find the code that implements the expiration system and remove or disable it.
Anyway, even if you could do that, how long do you make the current version last. There have been way too many times when code is released and within the next couple of days and major bug is found. Using a time based expiration system would simply not work.
We have an employee flying to Tallahassee as I write this because a version of RH6.0 had an old version of ssh on it, which was perfectly safe because it was behind a firewall. Until, of course, the firewall is changed to allow ssh... and someone needs to relay the OS because the machine was hacked.
Seriously, how much space did using a version of ssh with security holes save you? Was it significant, or are you rationalizing your negligence?
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.
Instead of expiring, how about building into all
network code the capability to check for upgrades based on security holes. On a daily, weekly, or so basis, the program itself could check an internet database to see if there are security upgrades available and if so, NOTIFY THE SYSADMIN, and continue to notify the sysadmin until the problem is fixed, or the warning disabled.
I always check on my programs to see if they're up to date, but I miss some every once in a while. Its a pain to constantly keep track of everything all the time. If the programs themselves did this work, it would be a little less hassle.
And if the programs are unable to access those databases due to a lack of internet access, then it doesn't really matter anyways.
I'm all for bugging the crap out of sysadmins who are running exploitable programs. In fact, I'd imagine most of them would upgrade to fix their problems if only they were aware of them. Some won't obviously, but at least this is a saner solution than to have perfectly working code suddenly stop working just because there MIGHT be a problem with it.
-Restil
Play with my webcams and lights here
If the user only knows how to handle binaries, then they have proven that some hand-holding is necessary and thus the software will do some of the 'work' in keeping the user up to date.
So as long as the user is knowledgeble enough about the ways of advanced computer useage, they will have the ability to do anything they want with Free software. If they need hand-holding, they will get it whether or not they want it (until someone recompiles it without the timeout.) This also might encourage them to educate themselves in the ways of coding, thus making them more knowledgeable overall.
I too use the same security philosophy (as the post to which you responded), that anyone who can get by my firewall basically has the run of my LAN. I don't excactly open up all my internal machines, but I don't lock them down to unuseability, either.
/.'ers
fall into this same category.
Some people consider this a Very Bad Idea. I understand the down side (namely, if someone gets past the firewall, game over), but look at it this way - Literally every day, someone discovers a new security vulnerability. Now, I can either spend a few hours every day researching these and deciding if they apply to any of my machines, or I can just skim for the really bad ones and those affecting the very few programs my firewall runs (Basically just a 2.4.x Linux kernel and an sshd... Fairly easy to watch for updates).
Also, you may want to consider the type of network involved... I refer to a home LAN consisting of a few Linux boxen, a W2K box (face it, through no fault of open source, many webpages have far too many IE-isms to work properly in Mozilla/Konqueror/Opera/whatever), and a networked printer. My only "users", (aside from myself, the SO and a few friends), only surf the web, check email,and occasionally ask me to install a game for them. Aside from my file server, I could completely reinstall any box I have in an hour. I suspect many
Incidentally, I do recommend (and use) *one* internal security measure, more of a CYA than actual "security"... I keep *everything* beyond base OS installations in a mirrored encrypted filesystem my file server. If ever Big Bro comes knocking and rounds up my PCs, they can ask nicely for the passwords I just happen to have forgotten, but good luck otherwise.
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.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Not that I'm the only one, mind you ... but if anyone's counting ...
Yeah, its a bad idea. Stinko! An idea about as prone to the law of unintended consequences as I've ever seen anybody from the open source crowd make. And that's just for starters.
You can't force anyone to change anything. You can't force anyone to change anything! You can't force anyone to change anything!!
You have to make them WANT to change. But don't think they're going to do it next week. That's just not the way people are. STOP fighting their natural flow (or lack thereof). Be a bit more mindful of the Tao.
"Grasshopper, if user sits like a lump - then you must find a way to use this inertia to your advantage. Your life will go much better that way. "
What am I saying? Its this, don't depend so much on upgrades.
Your (Open Source) software should check a website every month or so, to see if there are still no vulnerabilities discovered for it.
:P) should be optional both during compile time and during the actual use of the program. OS programs that don't have the option to have this module switched off would probably be forked.
If there is a known vulnerability for that program, the website will put that info on as content that is readable for that program, this is Also known as XML web services. The program can look for a certain XML tag to see if there is a vulnerability discovered for itself.
The content of the XML tag should be: "yes there is a hack" in addition to: "the hack is possible on versions x.xx - x.xx"
This method of providing a service would be the 2nd great way to make money off of Open Source software, because you don't have to make that XML tag viewable for free. You can ask for a fee to let people use your web service.
In fact, it's easier to provide this service to OS software because you can view and edit the source without having to contact a company for permission/negotiations first.
Ofcourse this "Vulnerability Info Module" (let history show that I coined the phrase
The possibility of forking OS programs would also be the mechanism that prevents a "Vulnerability Webservice Website" from hijacking the code written by others (making it only work with a paid-for module inside the program).
Because this service is easiest to implement for Open Source programs, it would mean that Open Source programs would be even more safer than Closed Source programs.
How about giving money for bugs found to programmers? The webservice company may be willing to pay money for that, to supply it's business with a steady stream of valuable info. That would creat a 3rd way to profit from Open Source programs.
Yes yes, *smug* I know I'm giving this splendid idea away for free, you may praise me now.
- -- Truth addict for life.
How about instead of stopping it working, just put in a warning like many virus scanners do.
;)
e.g. "Your copy of BIND is 6 months old. It is recommended that you upgrade to the latest version in order to prevent security holes."
You could either email it to root (maybe a bit annoying) or you could display it on startup (less likely to be seen on low-reboot or physically inaccessible machines). You could also be really radical and make it *beep*!
It'd have to be pretty visible, as the sort of people that are being targetted here are admins who don't really care about updates. Any sensible sysadmin will have updated their servers long before the 6 month timeout. I reckon emailing root *and* putting up the startup warning would be best. And of course there'd have to be an (compile time?) option to disable it too.
' Ore stabit fortis a fine placet ore stat '
- found on a park bench