Slashdot Mirror
Is the Unix Community Worried About Worms?
jaliathus asks: "While the Microsoft side of the computer world works overtime these days to fight worms, virii and other popular afflictions of NT, we in the Linux camp shouldn't be resting *too* much. After all, the concept of a worm similar to Code Red or Nimda could just as easily strike Linux ... it's as easy as finding a known hole and writing a program that exploits it, scans for more hosts and repeats. The only thing stopping it these days is Linux's smaller marketshare. (Worm propagation is one of those n squared problems). Especially if our goals of taking over the computing world are realized, Linux can and will be a prime target for the worm writers. What are we doing about it? Of course, admins should always keep up on the latest patches, but can we do anything about worms in the abstract sense?" Dispite the difficulties in starting a worm on a Unix clone, such a feat is still within the realm of possibility. Are there things that the Unix camp can be learning from Code Red and Nimbda?
The UNIX world already had a worm that recursively exploited security holes and spread, back in 1988.
THAT was the worm to learn from, not Code Red!
The only thing stopping it these days is Linux's smaller marketshare.
That, and the fact that MOST *nix users/admins tend to be a bunch of computer dorks, like us, and will be sure to stay up to date on security concerns, or at the very least, clean their system of the worm in a timely fashion.
Don't Tread on Me
Or any other form of auto-updater. Remember, Code Red and Nimda used holes that were patched months ago.
Patch the holes that are inevitable. Patch them early.
If someone doesn't patch their Windows systems why would they patch their Linux systems? Doesn't matter if the patch is out 2 seconds after the bug is revealed if the admin doesn't take notice and act.
Yes, it's trivially simple to protect against buffer overflows. But it takes some regimented coding to do it properly instead of taking the easy way out.
Instead of using gets(), you use fgets(). Use strncpy() instead of strcpy(). And so forth. The only real difference between these calls is that the "safer" one lets you specify a maximum number of bytes to copy. So you know you can't copy a string that's larger than your destination buffer (and you use sizeof() or #define's to ensure you have the proper buffer size) and thus start overwriting executable code.
This is all high school level programming. Anyone that does it deserves to be strung up for professional negligence. As many others point out, one of the first large distributed cases of a buffer overrun exploit was 13 years ago. So it's not like this is a new thing.
And yes, there are probably some Unix programs running around with buffer overrun exploits in them. They've been largely weeded out over time though and, to some extent, Unix's permission scheme avoids most serious issues, at least when services are installed properly.
The real key difference between Unix and Windows though is very, very deep assumptions. Unix assumes that the user cannot be trusted (thou shalt not run as root), nor can any external input. Windows assumes that everyone will play nice. Since the reality of the world is that there is a significant fraction of people who will NOT "play nice" it invalidates coding under that assumption. Thus the repeated security exploits using Microsoft tools and services - which weren't designed from the ground up to distrust the input given to them.
The plus side of "play nice" is that it's faster to code and you can put in features which would never, ever fly otherwise, like automagic remote installation of software. Or executing email attachments automatically. All that stuff that users think is "wow cool nifty" until someone does something they don't like.
Then you get black worms that exploit vulnerabilities in white worms, white worms that search for black worms and destroy them, black worms that hunt black-hunting white worms, grey worms that fix your security hole but extract a "payment" in the process, grey worms masquerading as white worms, black worms masquerading as white worms, white worms that inadvertantly do damage while trying to do good, black worms that exploit new holes left by those white worms, and pretty soon you've lost track of what worms you thought you had, what worms the white worms told you you had, what the grey worms have taken, and what the black worms have done.
It's much better to fix your own security problems, and not depend on some worm that says it's white.
While client market share for Windows is undisputed, Apache has close to 60% of the web server market. I haven't received a single readme.exe attachment.
Current Nimda stats are:
26900 attempts on 2 servers.
Apache (on *n*x, anyway) is not vulnerable to worms in the same way IIS is since it runs as notroot.somegroup. The only thing an Apache web server worm (on *n*x) could do is muck up the web server.
*n*x mail clients don't (at least yet) do a
file this_attachment
if file is ELF, or a.out
chmod +x this_attachment
execve this_attachment.
This isn't to say *n*x is immune. Just why Win* is not. Not because of market share.
www.dedserius.com
VB != VisualBasic
Following these steps, I think that distributions will be fairly safe from any discovered server vulnerabilities, and probably most client-side ones, as well.