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?

Comments

Re:Ignorant Question:

[Zathrus]

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.

Ways to avoid the pitfalls

[Ulwarth]

You can't force users to stay up to date with security patches or even know anything at all about security. But there are things that OS and distribution maintainers can do to make their software more secure out of the box. I realize that many Linux distributions already do some of this stuff, but I don't think any do all of it. And, it applies to any OS, including those written by Microsoft.

• By default, don't run any services! Windows 98 is more "secure" than Windows NT because it doesn't run services. A machine that is not explictly set up by the admin to be a server has no business running web, ftp, or ssh access.
• By default, firewall all incoming and outgoing traffic over the public interface. Leave the ports open on private interfaces (192.168.* and 10.0.0.*) so that they can still share files and printers and things on their LAN without frustration. There's no reason to make firewalling an option. If someone wants to run an external server, they need to explicitly punch a hole in the firewall to the outside world. If they want to turn off the firewall completely, they can do so - but doing so should be difficult enough that they have to know what they are doing to do so.
• Get rid of telnet and rsh. Install them, maybe, but never have them run by default. Instead, give them ssh as a remote login option. Make sure ssh is properly configured (no root logins, no blank password logins).
• Encourage users to use blank passwords for desktop use, and then make it possible to login in only from the console when your password is blank. This applies to root, too. Since it's convenient, people will do it - and if it's impossible to log in remotely when a user has a blank password, it's secure, too.
• Authors of server software have to make security a priority from the begining. All user input should be carefully verified with a single, highly paranoid function that clips length and filters out any characters that are not explicitly needed. Keep careful track of "trusted" versus "untrusted" values in the code, possibly going as far to give them special names like untrusted_buf or trusted_url.
• Disitributions should GET RID of old, clunky, insecure programs such as sendmail (replace with postfix), wuftp (replace with proftpd), inetd (replace with xinetd), etc.

Following these steps, I think that distributions will be fairly safe from any discovered server vulnerabilities, and probably most client-side ones, as well.