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

2 Reason; Not Market Share

[VB]

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.

Re:Ignorant Question:

[Osty]

It seems like every time you get input from the outside, you would only accept it in segments of a known length, and whatever was longer would just wait for the next "get" or whatever. At least this is the case in my (obviously limited) socket programming experience. So when some program is hit with a buffer overflow error, does the team of programmers smack their collective head and say "d'oh"?

The problem lies not in the realm of receiving the information, but actually processing it. What do you think happens after you've received all the necessary data chunks for the requested URL? They're put together and treated like a string, then parsed out for various pieces of data (the path to the file being requested, the type of file based on MIME types, any data parameters (passed from a form, for instance), and any other interesting information your server may be looking for). Now, with insecure coding practices, it's very easy to get a buffer overflow simply by doing something as innocuous as a call to sprintf() (because sprintf doesn't do any bounds checking). The really dangerous part, however, is when the target string is on the stack. Now, when that buffer overflows, a carefully constructed overflow string can easily put executable code into the stack and change the return address on the stack to point to the beginning of that executable code. This is sometimes referred to as "smashing the stack". If instead you're dealing with heap-allocated buffers, it's harder to get code executed, but you can still just as easily cause an access violation and kill the server anyway.

I'm not trying to pick on sprintf directly, because there are a ton of other potentially unsafe (any unbounded string operation, for instance) or always unsafe (gets, fgets, any function that expects a string to be formatted in a certain way, etc) functions that are used commonly. In fact, too many people use these functions without even knowing that they're opening themselves up to major problems.

One way to mitigate the possibility of having a buffer overflow in your application is by always using bounded string ops (snprintf, strncpy, etc) (note that strncat is a special case, in that the 'n' refers to the amount of chars to be appended, not the size of the target buffer). Another way is to simply not use the completely unsafe functions, like *gets(). These won't guarantee that you'll be safe, but it's a start. There are plenty of resources out there, so if you're interested, I suggest you do some reading.

Re:something to remember

[Zwack]

You should know(remember?) that the first worm ever written infected many *NIX systems

The First worm ever written?

Well, let me see, the term worm was invented by John Brunner, in his classic book, "Shockwave Rider"

And the guys at Xerox Parc wrote some network based programs... which they called worms after the John Brunner usage.

And WAY later, Robert Tappan Morris Jr. wrote the Internet worm.

So, No. The first worms didn't run on Unix

Incidentally, at least one of the xerox worms got out of hand and crashed a lot of machines at PARC.

Z.

Lets face it

[Anonymous Coward]

To make it impossible for a worm to infect a system you need an architecture to prevent this. Linux never knew any serious viruses because they were blocked by the rights restrictions of the kernel. The new problem is that a worm doesn't need to care about these restrictions. If we look at code red, it just needs to connect to the target in a standart manner (port 80) and already has full controll over the server.
Lets face it. Linux is as vulnerable as MS products. There is no general way to prevent this. The only way to limit the spreading of worms are more severe rights restrictions. For example only rw rights for the stack(I can`t believe this isn`t possible), restrict the program to modify itself, more options in setting rights...