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
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
Uh, they DIED when they expired. Probably not a good thing to let your web server die over a long holiday weekend.
(Insert "Tears in the Rain" speech here.)
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
Hey... how else are the young techies of the world supposed to get the plum jobs and read /. all day? =)
How about instead putting a little bug in the code that contacts the author every time the software is run? It could also send some basic marketing information as well, such as the names of every DVD watched, or MP3 played, or every website visited.
What a great feature!
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.
You can't pick an arbitrary point in time when software is ... "known to have security holes!"
Sure I can. How about "right now."
Why not try something a little more reasonable, such as SecurityFocus Pager 3.0? And I blockquote:
Of course, there are other tools available that do the same thing (or something similar). The point is tools like this allow admins to stay up on security issues, but let them upgrade immediately or as soon as practicable.Or you can just do an apt-get update; apt-get upgrade; once in a while like I do. ;)
-- null
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.
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.
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
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 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
howzabout if it sits around to long, it sends a message to your boss to replace you, the lazy admin, you frickin' slacker!
that'd be preferable.
thelocust[dot]org
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
[root@owl.tyrell.com] /usr/local/apache/bin/apachectl start
Starting httpd - please wait...
How old am I?
^C
My birthday's April 10 2017 - how long do I live?
^C^C^C^C
Nothing is worse than having an itch you can never scratch!
^C^C^ZC^Z^C^Z^CZ^C^C^C^C^Z^C^C^C
Wake up! Time to die!
Starting httpd... [FAILED]
mod_leon died prematurely...
[root@owl.tyrell.com]#
--- Hot Shot City is particularly good.
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.
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/