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

Linux has plenty of marketshare

[EllisDees]

The only thing stopping it these days is Linux's smaller marketshare.

What smaller marketshare? Check out the Netcraft survey if you don't believe me. I think better programming is the reason we aren't seeing any worms targetted at linux web servers.

Re:Linux has plenty of marketshare

[einhverfr]

Last record we have from Netcraft is 07/00:
http://www.netcraft.com/Survey/index-200007.html

Linux has the slightly higher market share.

Learning from Code Red?

[Kaz Kylheku]

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!

Re:Learning from Code Red?

[jd10131]

While *NIX systems are not impervious to various forms of attack, they are less vulnerable for several reasons.

1. People using *NIX systems are usually administering servers, or just love computers. The end result is that they're better (not nessicarily great) at keeping their machines patched.

2. People using NT/2000 often don't even realize they have exposed ports. The worst of the Code Red/Nimda infections are coming from machines on Cable/DSL...home users who probably don't even know their machine is a server.

3. Maturity. Any given piece of software will mature in features and stability/security. Most often, growth in security is sacrificed for features in commercial software. When software is free there tends to be less people trying to add marketing based features to a product. Most features come as modules which you must chose to install. With the focus on security, the number of vulnerabilities shrinks until there are virtually none.

4. Development environment. This may not be immediately obvious as a cause, but it is very relevant. IIS is written in C++, and many people think that C++ is better than C. The real truth is that while C++ provides many benefits, it also can make auditing code more difficlt. The language contains so many features that it becomes very difficult to trace a path of execution just by looking at some code.

I am sad to admit that every day I write code in C++, using MFC. My conclusion is that development is more difficult on Windows in C++ than on any other platform/language I have used. M$ has an idea of how an application should be laid out that very rarely fits my idea of how an application should be laid out.

Compare Apache with IIS. Apache has been around for quite some time now, it aims to be a decent general use webserver with a useful set of features. Things such as dynamic content and indexing are provided by various modules which communicate through a well-defined API. It's written in nice, linear easy-to-read C.

IIS has been around for a while, but the push is on features and integration with Windows. IIS integrates into many aspects of Windows, and it uses COM for it's extensions. Because all COM objects are handled at an OS level, there is much potential for a bad module to blow up the system.

Of course, even the holes in M$ software have patches available long before they become a headline for the day.

something to remember

[CoreyG]

Worms aren't just a Microsoft thing. You should know(remember?) that the first worm ever written infected many *NIX systems (and the net in general) quite badly.

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.

Re:something to remember

[Lxy]

FWIW, the history of worms and such is available here:

http://www.software.com.pl/newarchive/misc/Worm/da rbyt/pages/history.html

Pretty well written article with more detail than the above post (same info though).

Re:something to remember

[American AC in Paris]

FWIW, the history of worms and such is available here:

http://www.software.com.pl/newarchive/misc/Worm/ da rbyt/pages/history.html [software.com.pl]

That site has been updated and now lives at http://www.snowplow.org/tom/worm/worm.html.

The co-author

Holding back the worm

[Heem]

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.

Re:Holding back the worm

[Trepidity]

Perhaps there aren't as many incompetent admins, but there are still a lot of neglected Linux installs out there. A lot of them are just forgotten boxes, or test boxes that are sitting around waiting for a project to complete, or forgotted installs - I can't even count how many default Apache pages I've seen on the internet. Somebody installed Apache and never did anything with it, so if there were a hole in Apache, who knows if they'd even remember they had Apache running, much less to patch it. Sure, worms might spread slower, but I think they'd still spread.

Re:Holding back the worm

[SCHecklerX]

Perhaps people should be required to have a license to use a computer, just as they are required to have a license to operate a motor vehicle.

It is the 'information superhighway' after all.

I've often thought about this, and think it is an awesome solution if it could be enforced. People would actually have to understand the damned tool they are using, and might *gasp* use it properly for a change.

Monoculture

[fractalus]

Even if Linux gained market dominance, it wouldn't quite be the monoculture that Windows is. There are many distributions of Linux, which put important files in different places. This isn't insurmountable but it does make writing a worm capable of running rampant a wee bit harder.

Also, it's my experience that (for now) people who set up Linux to run on the net are a little bit more clueful than NT administrators. NT seems to encourage the idea that any moron can run it because it's point and click. This isn't true; it takes more work to effectively admin an NT box than a Linux box.

There have and will continue to be worms. Worms are most successful at any point of monoculture. (sendmail; bind; IIS) The solution, then, is not dominance... but diversity.

Re:Monoculture

[frankie]

it's my experience that (for now) people who set up Linux to run on the net are a little bit more clueful

That experience is most definitely changing with every passing day. In the first week of September, JHU's whole class B block was placed on ORBL, ORBZ, and RBL. We had a dozen-ish open SMTP relays. It may be perpetual september now, but some months are more september than others.

As expected, our network team tracked them down to the underclass dorms. Students who downloaded ISOs, installed Linux, and turned on everything. Most of them couldn't have secured a server to save their lives. Some of them didn't even know they were running a server. Gee, that situation sounds strangely familiar...

Apt and cron

[Anonymous Coward]

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.

From earlier in the day...

[FortKnox]

Just read this and protect yourself.

This is a pretty pathetic ask/.

I'd like to see 'White Hat' worms...

[ddstreet]

What I think would be interesting, is a Linux worm that used a security hole to get into a box, then closed the security hole, then propagate to other boxes, and finally uninstall itself. Maybe also leave a message or email on the box stating that it's fixed the box's security hole...;-)

Unfortunately, doing constructive work (i.e., fixing the security hole) is always more difficult than doing destructive work (e.g., rm -rf /). But worm/virus writers seem to have plenty of time on their hands...

Re:I'd like to see 'White Hat' worms...

[mandolin]

a Linux worm that used a security hole to get into a box, then closed the security hole, then propagate to other boxes, and finally uninstall itself.

Except for the uninstalling part :-), it's been done. Try a google search for "cheese worm".

Re:I'd like to see 'White Hat' worms...

[wishus]

What I think would be interesting, is a Linux worm that used a security hole to get into a box, then closed the security hole, then propagate to other boxes, and finally uninstall itself.

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.

Re:I'd like to see 'White Hat' worms...

[Accipiter]

Ah, yeah. That'd be the Cheese Worm.

And apparently, this factual informative comment "violated the postercomment compression filter.", whatever the fuck that is.

Re:I'd like to see 'White Hat' worms...

[Rupert]

Just like a real ecosystem, then, which many people have compared the internet to.

I think something like this may be inevitable. You may even get parasites on the worms. So long as they don't turn out like the viruses in Hyperion...

Re:I'd like to see 'White Hat' worms...

[isomeme]

It's much better to fix your own security problems, and not depend on some worm that says it's white.

Of course. However, we all pay the price (direct, in network slowdowns, and indirect, in the threat of government regulation) for sites which do not fix their own security problems. How should we respond?

An instructive analogy: Suppose you notice that your neighbor's house is on fire. This is obviously a big problem for your neighbor, but it's also a big potential problem for you -- left uncontrolled, the fire could easily spread to your house. You try to alert your neighbor, but get no response. Does it make sense for you to call 911? Perhaps even use your own garden hose to try to control the fire? Of course; anyone would do this, and nobody would say you were doing anything wrong.

On an internet thriving with worms of all greyscale values, properly administered sites won't need to worry about them, and improperly administered sites will hopefully get dogpiled so quickly that they'll either be forcibly patched or crash in minutes. When the vast majority of sites are being properly administered, all flavors of worm will starve for lack of prey.

Re:I'd like to see 'White Hat' worms...

[wishus]

These white/black distinctions border on the racist. Can't we use "good" and "evil" instead? We can still use "grey" for the middle.

These color distinctions come not from skin tone, but from the color of hat these hackers wear.

Re:I'd like to see 'White Hat' worms...

[snake_dad]

Eh... and the internet will wake up and call itself "Mike" :-)

Smaller market share?

[rw2]

The only thing stopping it these days is Linux's smaller marketshare.

I thought apache had a majority share of the web server market. One that has been hit by worms, and those worm writers usually choose IIS despite it's smaller market share.

It could be because IIS has more exploits...

Re:Smaller market share?

[mblase]

I believe it's not that IIS has more exploits, but that IIS users aren't as vigilant about patching their exploits.

Think about it. Microsoft's entire appeal is based on ease-of-use; zero administration, wizards, automatically opening your attachments, and so on and so forth. This philosophy sells their servers and server software as well. So people who are used to MS products think they can set up a server, turn it on, and pretty much forget about it.

The MCSE graduates know better, of course, but they're so expensive to hire. Meanwhile, Linux and *nix in general almost always require a degree of problem-solving ability in order to set them up and get them working. This is part of the reason why they have a smaller market share. However, it also means that most people who take the time to install *nix and get it working on a network (not all, but most) are also going to be vigilant about keeping things patched and secure.

Maybe that's the nature of it, maybe not. But I'm convinced that there's something in the culture of *nix that drives its adopters to keep things patched, updated and secure, while the culture of MS users is to buy it, install it and let it do your work for you.

Re:Smaller market share?

[ptomblin]

Apache != Linux

Apache's market share includes the Apache installations running on Solaris, AIX and even Windows, not just Linux.

Re:Smaller market share?

[rw2]

Apache != Linux

Right. And worms, virii and other popular afflictions of NT is wrong to. Most of the worms and virii have been infecting outlook and IIS, not Windows. So to on the unix side. And the vast majority of Apache is running on unix flavors.

My comment is a fair one, even if you do have a lower uid than mine.

Re:Smaller market share?

[4of12]

You are right on and ought to be modded up.

Following your line further, the real danger is that as *nix attempts to become more popular by becoming "easier to use", it will succumb to some of the same pitfalls that plague MS.

I have to hope that we can prove the old adage wrong - you know the one - every programmer does - I forget who said it first

"If you make your program so simple that even a fool can use it, be assured that only fools will use it."

by Robert Morris

[maddogsparky]

Yeah. It was the classic example that we studied in my Computer ethics class. Sounds sort of like the nimd worm in that it had four different methods of spreading. The only thing that stopped it from being even worse than it could have been was a programming error that caused it to fill up memory and eventually cause the infected machine to crash.

Ignorant Question:

[rkent]

Okay, here I go, proving my lack of server programming skilz: is it really so hard to prevent buffer overflows? Why does the length of a URL (for example) ever cause a server to crash?

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"?

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.

Re:Ignorant Question:

[daviddennis]

In the olden days where men were men, women were women, and people generally didn't engage in tiresome obnoxious behaviour, there was really no need to deal with these issues. It's worth noting that the Morris worm used the 'debug' command of sendmail. This command allowed anyone a root shell by just typing 'debug' at the sendmail prompt easily accessible from outside the system. Life went on just fine, because few people knew of the hole, and those who knew about it didn't bother to use it.

Sadly, nowadays things are different and we must deal with tiresome security problems all the time. But it was easy to get into the habit of programming in a non-security conscious way, because for many years it really wasn't a problem at all.

The C programming language was very much a part of that ethos. It was simply not designed to consider the buffer overflow problem. The size of buffers was almost never checked in early C programs.

And there are many cases other than the input of text where buffer overflows can occur. For instance, sprintf is a common function used to build up a string from smaller pieces. You use it by saying:

sprintf(destination_string, format, args);

The format determines the way the arguments are put together to create the string. If you have a destination string of 1,000 characters, and the string being built up contains 1,200 characters, you have an overflow.

The solution is to use snprintf, which is the same but includes a limit on the number of characters that are added to the string. But that means that every time you want to build up a string, you have to remember to use snprintf and add the count. If you've been programming "the old way" for a long period of time, it's easy to forget to do this.

The way I work around this problem is by building my own sprintf(), which automatically uses snprintf to build up a string with the maximum buffer size I normally use. So I can program "carelessly" but be protected at the same time.

As you can see, it's not just the size of the input string, it's how it is combined with other strings using functions like sprintf() that's the problem. And because it's a big pain to calculate all this out, it's no wonder programmers tended not to do it - until they got persuaded by tiresome security issues, that is.

Hope that helps.

D

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:Ignorant Question:

[ZanshinWedge]

This is somewhat offtopic, but I dispute your allegation that Unix assumes that the user cannot be trusted. This is simply not the case. If it had been, unix would not be the security seive that it is (admit it, it is, the only reason it doesn't look so bad at the moment is that in comparison windows is like those dogs that eat their own poo, relatively speaking unix looks like a friggin' fortress). Unix assumes that not all users can be trusted *to the same degree*, but fundamentally, the basic unix structure assumes that all users can be trusted at least partially.

Re:Ignorant Question:

[peccary]

Another thing to do is never ever do copy-type operations into auto variables (on the stack). Auto variables should only be assigned to with the = operator. Makes it awfully hard to stack-smash.

Re:Ignorant Question:

[AT]

Yes, it's trivially simple to protect against buffer overflows.

It may seem trivial problem, but it is actually very hard to solve in practice. The C string API is simply poorly designed -- it is way too easy to mess up. It's not a matter negligence, people are human and make mistakes; thinking good programmers are exempt is pure hubris.

The real solution is to expect, and learn to live with buggy code.

Remotely accessible programs should run in chroot jails with the bare minimum of capabilities.

Languages should make it harder to screw up. Less error prone string handling in languages such as perl, Java and even C++, are helping. Java has even more potential with its untrusted code security model.

And yes, there are probably some Unix programs running around with buffer overrun exploits in them.

Undoubtably. Many more than you'd think. And the vast majority won't every be found or fixed, because the program is not suid or remotely available.

Unix assumes that the user cannot be trusted

This assumption is broken by suid programs. They say a user is trusted to use me, but only to do something safe. It makes the implicit assumption that an suid program will only do what it was written to do. Secure systems must ensure that when these programs are inevitably comprimised, the damage is contained.

Re:Ignorant Question:

[steveha]

Instead of using gets(), you use fgets(). Use strncpy() instead of strcpy(). And so forth.

Yes.

My question: isn't it sort of a bug that gets() and strcpy() are still there in the standard C library? I would like, at a minimum, to see these cause a compile-time warning. It will be a long time before we can expunge all calls to these functions, but it might go quicker if we can get the compilers to complain about them.

Has anyone looked at doing this?

steveha

Re:Ignorant Question:

[Detritus]

Try using an old version of UNIX, like V7. It was still a research operating system and the philosophy was that users were mature and trustworthy enough not to do stupid/hostile things. There were many ways for a user to screw up the system. The program crashes when you feed it an input line of 4096 characters? Well, don't do that! That philosophy becomes untenable you put the system on a public network and give accounts to large numbers of immature college students.

Find a *root* identitied server.

[DunbarTheInept]

To really make a worm mess people up, it needs to get root access. That fact alone is enough to make Apache more secure than IIS, due to the fact that unless you're an idiot you run your Apache servers as a non-root user. And even if you're an idiot there's still a good chance you are running your server as 'nobody' anyway, since that's the default insallation setting. You would have to be a very special sort of idiot, the kind that goes out of his way to do idiotic things on purpose, in order to be running Apache as root.

Now, this doesn't alleviate all the problems of course, because even with "normal user" access a person can still do some damage. The web pages are probably owned by that normal user, so with normal access a person could alter your content. The normal user could set up cron jobs for himself such that he attacks other machines later, and thus you can still get propigation without root. So this still leaves open the possiblity of having DNS attacks (since being a part of the attack doesn't require root privilieges, just any user will do.) But it doesn't really leave any way to mess up the target machine permanently. You couldn't alter the httpd program, for example, since it isn't owned by the same user as the user ID it runs under.

At worst, you lose the web pages themselves, but most likely you have those copied over from some other location as part of your "I'm going to edit in a scratch area and then install these changes for real after I try them out" technique.

Re:Find a *root* identitied server.

[david.johns]

To really make a worm mess people up, it needs to get root access. That fact alone is enough to make Apache more secure than IIS, due to the fact that unless you're an idiot you run your Apache servers as a non-root user.

For a moment, this didn't ring true. Why? Because the capacity of a local user to utilize a local root exploit (and thus render your argument invalid) is high.

But then, I realized something. Open Source software encourages diversity. Apache may be running on Windows, Debian GNU/Linux, Redhat, OpenBSD, FreeBSD, etc... etc... And the root exploits are all different. Who are you going to pick on? All of them?

The worm we're seeing floating around the MS community are exploiting lots of known bugs in one fell swoop. Virtually all Windows installations except those secured by some smart users and some smart admins are vulnerable to one of these attacks. Thus, once again, the Open Source world could have a worm that used a collection of exploits to root many kinds of boxes, right?

Wrong. The memory footprint and coding skill this would take would make the worm look a lot more like "Microsoft Office for Every Platform" than the Morris Worm. That's because the vulnerabilities taken advantage of are most often in a variety of particular programs rather than some standard API or a few known awful (*cough*Outlook*cough) offenders. If a kernel version or the last few X11 versions had some huge flaws, or maybe Gnome or KDE, then we have a chance to worry. But you know what? The only one of those that Apache is involved in at all is the kernel. Server machines s often do not have X11, let alone Gnome, or KDE.. etc.. etc..

So my extremely longwinded point is: We aren't immune, but the kind of attack that we're seeing on Windows right now is hard against Open Source Software. Infinite Diversity in Infinite Combinations.

Re:Find a *root* identitied server.

[ZanshinWedge]

This is fundamentally wrong.

Theoretically, if you're system is ship shape, then only root, or someone with root access, can REALLY fuxor it up. However, there are many levels of fuxored below "REALLY fuxored", and no system is 100.0000% perfect. Unix is a security nightmare. It's security model is decrepit and is only being patched / kludged into anything resembling reasonable security. I fear that it is too established to be replaced with something completely different at this point (i.e. something that was still unix, but fundamentally different in security model).

In general, I don't think it's a good idea to measure security success compared to the gimp of the security world (MS).

Re:Find a *root* identitied server.

[Ami Ganguli]

Unix is a security nightmare.

Why do you say that? Certainly traditional security is simple, so you can't do the fine-grained things that other systems allow (not really true anymore with capabilities, but those aren't widely used or entirely standard). But simple has it's advantages - there are fewer ways to mess things up.

Re:Find a *root* identitied server.

[scrytch]

But simple has it's advantages - there are fewer ways to mess things up.

By this logic, DOS is the most secure OS in existence. Can't mess up what doesn't exist.

Let's begin with the problems of unix security: how about a "god" user that can do absolutely anything and everything, which many critical subsystems require the permissions of to do basic work. Inability to invoke basic simple security mechanisms like chroot or setuid without that user's perms. Requiring an interactive shell with that user's perms for most basic system maintenance -- even most tools for system maintenance have to spend some time as uid 0 or go through something that does. The fact that every piece of executable or interpreted content runs with the full permissions of the executing user and not the owner of the resource or at least a subset of the permissions of the executor according to some kind of mask.

Capabilities are great, but they're sort of the lambda calculus of security -- you can model anything with them, but you wouldn't want a system that used nothing but pure caps any more than you'd want to program in nothing but the lambda calculus.

Re:Find a *root* identitied server.

[ZanshinWedge]

Why do I say unix is a security nightmare? Simple: experience. Unix is a vast, convoluted, complex system with many little cracks just waiting for someone to exploit them. It takes an extraordinary amount of knowledge to configure unix to a basic level of security. It takes a goodly amount of diligence to keep it that way. And even then you are not guaranteed in any reasonable sense to be secure. And it's not like it takes a criminal mastermind to break into your system, all it takes is a bored kid with some automated tools and a little general knowledge. There is an asymetry, it requires less sophistication and less tools to break in than it requires to prevent a break in. That asymetry is due to the security weaknesses in unix.

Re:Find a *root* identitied server.

[Ami Ganguli]

Odd, I've found almost the opposite. Most systems come with configurations that are pretty secure and all you need to do to lock them down is disable services you don't need and install SSH. Maintaining security means watching for security notices (which are widely distributed) and updating every now and then.

In order to break into a Unix system you either need to do a lot of painstaking work to find an exploit, or you need to monitor security lists and create an exploit before your target has updated his software. Either requires considerable effort and luck.

The fact that real Unix exploits are relatively rare lends some empirical support to the notion that hacking into a Unix box isn't that easy.

Re:Find a *root* identitied server.

[Ami Ganguli]

No, I was promoting the idea that a system should be as simple as possible, but no simpler. The original Unix developers managed to create a security system that was much simpler than ACLs, but did most of what was needed. It's held up remarkably well.

That said, you raise some valid critisisms, but they are slowly being addressed. The reason things are changing slowly is that the old system, although lacking for all the reasons you mention, actually works pretty well in practice. Requiring root access is a problem, but not a crippling one (if it were then the whole Internet would have been rooted long ago).

Re:Grammar

[Restil]

Its "relieve."

Its "a need."

ahem....

-Restil

Microsoft vs Linux

[josepha48]

I think the big difference here is that most people at some point in the Linux commuintiy start to look at security as part of the system, not like Microsoft where security is only now being thought of.

Lets face it Linux comes and has come with ipchains and now iptables for firewalling and many other UNIX flavors have similar features. Linux and the UNIX community think about things like proxy firewall combinations, where Windows is only now starting to think about this. It is not until the release of XP (or the anticipated release as it is not out) that windows is by default including a firewall.

People in the unix community also tend to be more aware of what is going on on their system. They have logs and there are tools to view them.

While I do not dismiss the possiblity that if Linux / UNIX got to be as popular as windows then there would be more 'attempts' I think that because of the nature of Linux you would have a much harder time of spreading a worm like code red.

A good UNIX administrator is going to spend time in configuring his web server and securing it. If they do not think about this then they are no good.

If you are wondering how secure your computer is try these two site. They'll help, but don't try this at work or you may piss off your admins. https://grc.com/x/ne.dll?bh0bkyd2 or http://scan.sygatetech.com/

Wha't the next step for UNIX security?

[melquiades]

Certainly the robust UNIX security model is one reason we haven't seen as many worms. The strategy of creating a separate "www" or "http" user to run Apache, a "db" user for the database, etc., is common and very wise. If somebody co-opts your web server, at least it can't wipe your db. It still has weaknesses -- it's sometimes necessary to grant more permission to certain users/processes than you might like, and it requires a lot of vigilance from sysadmins, but it works quite well.

I wonder if there isn't a way of generalizing this to allow more sweeping, more generalized expressions of security rules. A UNIX install has soooo many little apps, and so many points of contact for everything, it's sometimes hard to say "I want all apps that could access X to have permissions Y, or go through acces point Z." TCP wrappers are a good example of the kind of thing I'm talking about -- they provide a single point of access and control for all things TCP, and they make it much easier to set up very broad rules that you know cover all possible cases.

Am I making any sense here? How might an OS take on this issue in the general case? It seems like one next logical step for UNIX security.

Re:Wha't the next step for UNIX security?

[valdis]

The first step is POSIX 1003.1e 'capabilities', and is already partially supported in the current Linux kernel. Basically, it breaks the 'suser()' check for "are we running as root?" into lots of little checks: "are we allowed to open any file?" "are we allowed to use raw sockets?" "are we allowed to kill() other processes?" and so on. So instead of (for example) 'ping' being suid just so it can use a raw socket, it would have CAP_NET_RAW, and if subverted, the only thing the attacker gets is the ability to send raw packets (which may be leveragable, but makes it a LOT harder than just execve'in a root shell on the spot).

The other big move is to support ACLs - access control lists - so you can say "fred, george and harry can write this file, members of group foo are only able to read it, and members of group bar aren't able to do anytying with it".

SELinux, the LSM project, and the like, are the sort of thing we're aiming at....

The real reason.

[TheNecromancer]

Microsoft systems are more susceptable to worms(IMHO) because the level of compter knowledge is way higher for Unix users that it is for Microsoft users. I mean this sincerely, and not just as flamebait.

Consider how many Unix users would actually just open their emails and run attachments blindly. I would venture that there are a ton more Microsoft users that actually do just that!

difficulties?

[friscolr]

Dispite the difficulties in starting a worm on a Unix clone, such a feat is still within the realm of possibility. re there things that the Unix camp can be learning from Code Red and Nimbda?

what difficulties?

whenever an inexperienced user brings up a redhat 7.0 or lower box on our network, it is exploited within 12 hours. within 24 hours i have received email from admins on other networks informing me that the redhat box has been probing their network. 1 minute later i have informed yet another user that it takes more to do my job than booting off of cd and following instructions on the screen.

someone out their has already taken advantage of the various vulnerabilities found in older distros.

lessons learned? i am reminded of something my brother told me:

Having your own box appeals to the pioneer spirit: your own plot of land to develop as you please, fighting off the savages, protecting from the elements.

In other words, every time you run software which other people will somehow have access to (users running desktop software, server software connected to the internet , etc) you will need to constantly monitor and upgrade that software.

The Morris Worm

[Prof_Dagoski]

Let's not forget that what was probably the first worm, the Morris Worm, was released on Unix machines. I don't remember the year, but it was in the early days of the Internet when about all there was out there was Unix and VMS. The lesson that the Unix community took away from this and other incidents was that they needed to secure their machines and tighten up code. The point here is that no system is immune. When I first started out in the Internet field, almost all attacks were launched against Unix and VMS machines because that's about all that was hooked up to the Net on a constant basis. So, don't get smug just because Micrsoft is victimized today. After MS dies a firey death, something else will become the dominant system on the net and that will be the most attacked system.

It could happen...

[Greyfox]

God knows there are enough newbie sysadmins who feel that even though 30 years of sysadmin wisdom says never run as root, they feel they can because they understand the risks involved. They typically also give all their friends accounts on their system (Ooh! I have a multiuser OS! I'll give all my friends accounts!) Usually they stop doing that after the second or third time they get compromised and have their hard drives filled up with goat porn.

Fortunately the default installs of most of the mainstream distributions are getting more secure as time goes by. And while RedHat traditionally isn't quite as easy to set auto-updating up for as Debian is, it's still pretty easy to keep up with the security patches for it. I'd really like to see the package maintainers package at least some of the more traditionally insecure packages (*Cough*Bind*Cough*) in ultra-paranoid configurations, say, statically compiled and chrooted. It hasn't been enough of an irritation for me to go do it myself though.

We all pretty well know, though, that security is more what the user does with the OS rather than how inherently "secure" the OS is out of the box. FreeBSD is by reputation one of the most secure OSes available but I could take that thing and install a bunch of servers with holes in them and be no better off than if I was running Windows 2000 doing the same thing.

Re:It could happen...

[doom]

Finally someone says it:

And while RedHat traditionally isn't quite as easy to set auto-updating up for as Debian is, it's still pretty easy to keep up with the security patches for it.

It seems pretty clear to me that *this* is the real solution. The problem is lazy sysadmins, and you get more lazy sysadmins as you get more popular. So a real "easy to use" linux distribution has got to include a mechanism for automated security updates (and it had better be a *secure* mechanism). It does indeed sound like Debian is better off than RedHat in this respect, but eventually even RedHat will get it's act together...

(How hard can it be to figure out a way to generate some extra revenue from this? "And for only $5/month, we'll set you up with the the Head Patch Automated Reinsecuritator Mechanism.")

Re:It could happen...

[Greyfox]

Well IIRC Microsoft has tried to set up some sort of auto-update feature as well. I don't know how well it works, or if it works, since I don't do Windows.

The problem with using such a feature to generate revenue is that at the very least security patches should fall under warranty coverage and be provided for free. Now if you want to provide something on top of that, say, non-security related kernel patches or something, you might be able to swing that. Making sure security related kernel patches don't rely on non-security kernel patches could be a pain in the ass though.

Re:keep your code clean?

[GregK72]

I think that people could probably find exploits in Apache, Sendmail, etc... probably a lot easier since they can scan the sourcecode. From what I have read though, most of these worms & virii are not very complicated and are using relatively easy to exploit holes in M$ products. Most of these holes exist since M$ is trying to make life easier on the user by doing work behind the scenes (such as automatically calling an IE dll to render an HTML email). As work continues on desktop environments such as GNOME and KDE, I think that it is not unreasonable to expect to see exploits in those products being used. But since M$ products dominate the desktop market, I expect to find most people writing worms&virii for M$ environments.

Bad Comparison

[gad_zuki!]

If someone goes through the trouble of downloading/buying Linux and setting it up as a public server they're probably a lot more computer literate than most windows users. They certainly would understand the need for patches and probably read some kind Linux news site to keep up.

Now if Linux had windows' market share, it would have to come pre-installed with a new PC and not require the user to do much more than just use the GUI. Which is fine as far as I'm concerned, but we can also assume a Linux dominated universe would be full of unpatched servers too.

Maybe untreated Windows exploits are heading toward exinction. Its easy access to the internet that has created such a huge market for anti-virus software. Maybe we'll start seeing Windows shipping with an MS or a third party patch manager in the near future. Or something like NAV with a patch checker. "No viruses found, you are open to these attacks, please goto this URL to download the patches."

Hard to create a Unix worm???

[sterno]

Why do you think it's harder to create a *nix worm? I mean the basic principles of worm propagation work under any platform if there are any security holes. Certainly *nix does occasionally suffer from security vulnerabilites, if perhaps less than Windows. Look at the ramen worm that was going around recently. I STILL get scans on my box for that vulnerability. Certainly the scale is less dramatic because of the fewer *nix systems out there, but it's not like writing a worm for unix is somehow more difficult than for windows.

Subtle bug?

[dschuetz]

Is it that the username might be 8 unicode (or other multi-byte format) characters?

Just a quick hunch...

Re:Subtle bug?

[Sly Mongoose]

More likely that he only declared an 8-byte buffer, with no room for the '\0' string terminator.

You can be lazy on any platform.

[NetJunkie]

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.

Re:You can be lazy on any platform.

[gimpboy]

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.

if they are too lazy to patch their windows systems then they are probably too lazy to install linux. currently *nix attracts a different kind of user. this might change in the future, but right now i think your average linux user is a bit more informed and competent.

Re:You can be lazy on any platform.

[ansible]

I'm sure someone's already come up with a script that can automatically check the GPG signatures of downloaded packages.

Of course, I would never run automatic software updates on a production server. That might be fine for desktop machines though.

Re:You can be lazy on any platform.

[NetJunkie]

You can get a patched WinNT/2K CD. They update the CDs with the service packs all the time. If you don't have a patched CD all you have to do is apply the LATEST service pack and the hotfixes, which they are now rolling in to one big hotfix at times.

You don't have to apply ALL the service packs, just the latest.

*nix Worms? Great Skill == More Maturity

[Lethyos]

Worms are definitely a problem on all platforms. But the *nix world has a bigger advantage over the Windows world. In our world, code is written with lots of thought towards quality and strong design. Windows, well, is questionable. Certainly *nix has exploits, but those that exist require a GREAT deal more skill to exploit than those that exist for Windows. Therein lies our safety net.

Most people who have the skill to code worms for more secure and robust *nix platforms are probably mature/responsible enough through their experience to not do something so utterly foolish. However, if they do decide to do so, they end up trying to do a positive thing for the community! (Anyone remember those Linux worms that FIXED the exploits they took advantage of before moving onto the next box and cleaning themselves up?) Besides, look at the very few malicious worms we have seen for *nix platforms. They didn't last long. The OSS community has a VERY quick response time to big problems and the admins are generally more skilled and knowlagable about applying patches.

I say, let's enjoy this while we can. It's kind of amusing to see MS admins scurry around, trying to stick fingers in all the leaks. It's risky to say "it serves them right", but that's for only weighing mundane factors in deciding what platform to use. And for those companies that reject OSS products, well, they get what they deserve for thinking "stuff that doesn't come from a company mustn't have any quality". Pah. Worms with the scale of NT aren't a concern for us. Let's parade this around as a reason to support and use open software.

Wrong!

[Captain_Frisk]

IIS does have a smaller market share in terms of commercial websites out there. However, there are lots of clowns at home on DSL or cable who are running win2k.

Many people run IIS without knowing it, so i think there are much more vulnerable machines out there than just the webservers.

Granted, IIS probably does have more exploits, but the real problem is that windows users usually aren't on top of patching them up. There are plenty of exploits out there that exploit linux, but there aren't as many issues because admins patch regularly, and the smaller market share.

Captain_Frisk

Re:Wrong!

[Keith Russell]

However, there are lots of clowns at home on DSL or cable who are running win2k. Many people run IIS without knowing it...

We've been over this before. Windows 2000 Professional never installs IIS by default. It must be explicitly installed by the user. And it's not in an obvious place, either. So if the average user doesn't know where to look, it won't happen by accident.

Re:Wrong!

[snake_dad]

"Hey, look, I can install a real honest-to-god webserver-thingy! Wow! Dunno yet what I'll do with it, but it sure is cool to have my own web-thing."

Need I say more?

Why don't people attack UNIX more?

[supabeast!]

Actually, it would probably be easier to attack UNIX with a worm. There are more UNIX machines out there than Windows machines, and most of them are probably just as poorly maintained in regards to security.

So why don't people write more UNIX worms? I think the first big problem with a UNIX worm is the portability problem: getting a worm that runs well on all of the different CPUs, UNIXes, Linux distros, etc. out there would require a pretty basassed coder. Anyone good enough to do so probably wouldn't waste his time on a worm since he could get paid obscene amounts of money for coding something more productive.

On a more positive note, I think worms generally target Windows because computer users in general don't really like Windows. Jokes about Windows being unstable/buggy/insecure/slow have gone from being a subsect of geek culture to a repetitive theme in popular culture. People run Windows mostly out of necessity, because it is the only desktop OS that provides access to a large variety of commercial software, and runs on cheap, non-proprietary hardware. People who use UNIX do so because they want to, and they like doing it; therefore they are less likely to produce something as randon as a worm. (I am leaving crackers/s'kiddies out of this as they have far different motivations.).

Re:keep your code clean?

[daviddennis]

But it's not, in web server market share. Last time I looked, Microsoft had under a third of the market.

The basic problem is that it's a very complex task to make things look and feel simple to the end user. Because of that, the Microsoft server is a great deal more complex than Apache. And it exposes more services, which to an Apache user would be installed on a case by case basis. Note that the problems we've seen in IIS are generally caused by auxillary stuff like the Index Server. That exists to make things easy, yes. But it also increases complexity, and whenever complexity goes up, the possibility of there being holes goes up even more.

Hope that helps.

D

Re:same goes for virii....

[spudnic]

Very good virus protection is already available for Linux. Check out AVP.

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:2 Reason; Not Market Share

[sheldon]

Code Red was also memory resident.

That sure didn't stop it from propogating.

Re:2 Reason; Not Market Share

[imipak]

"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.

...near 60% of the non-SSL server market. Netcraft don't seem to offer the depressing SSL server stats for free; IIS is the market leader and gaining, last time I checked (several months ago, now.)

What I find most astonishing is that so far there's no discernable sign of a move away from IIS at all in the Netcraft numbers. They explain that a couple of major colo hosters have switched thousands of virtual hosts, which results in the last couple of month's big losses for Apache at IIS' expense. But if Code Red and Nimda don't make the PHBs reconsider using IIS, what on earth WILL?

Well..

[mindstrm]

You could call it marketshare.. but the worm problem really isn't about an OS.. it's about individual applications and technologies.. the environments the worm can flourish in. A cross platform worm is entirely possible.

As for our 'goals'.... who's goals are those? Who wants linux everywhere? Use the right tool for the right job. If MS actually made something that was better for a job, I'd use it. (IF.. big IF)

Lesson One

[4of12]

1. Learn from OpenBSD to go over code with a 5 micron comb.
2. Get rid of as many exploits as you can before your market share gets to 90%. (Still have some time here:)

The biggest obstacle, AFAICT, is making solid security Ease-Zee.

Certainly many commercial outfits haven't successfully solved this problem yet and there are still plenty of opportunities for spoofed trojans with fake internal certifications.

I mean, when I download a package, it usually contains its own references to valid signatures, etc. Or, the md5 signature is kept in another file, but on the same ftp server.

Better are package maintainers that digitally sign their products. I'd like to see more of that, maybe in conjunction with multiple certifying authorities that can verify the signator's credentials. I don't need a system that compromises the anonymity of me or the package writer - just something that verifies that a package originated with a consistent unique individual.

Do modern CD distros of GNU/Linux and other OS come with anything like a set of multiple certifying authorities where package writers can register signatures in multiple places to minimize the chances that a fake can be passed off on innocent downloaders?

Rest easy but not blindly

[Felinoid]

Rest easy. Yes Unix can have worms and in fact it has happend.
This worm was fixed about as quickly as possable. The only real problem was getting the fix out as the worm had sereously disrupted the primary means of getting the patch out.
The time delay for Microsoft patches is a great deal longer and is due to develupment delays not distrubution delays.
There is also a delay due to NT admin fears the patch may disrupt the system. I doupt this is a realistic fear but I have heard it once or twice. I think this is more or less the end result of the ignorence Microsoft premotes amoung NT admin. That ignorence is probably responsable for more problems than the software itself.

In short once a worm is created once known it should be a short time before bug fix.

But not blindly....
The reality is worms are a low likelyhood. You should stand ready for a whole range of issues worms are in the bag.
Viruses are even less likely and nearly impossable. However IF we go getting paranoid about worms to the exclusion of all else... Viruses viruses viruses... becouse we are looking the other way.. won't you feel dumb..

Keep an eye do the maintanence, read the logs, read slashdot, bug trap and so on.. keep an eye on the issues related to your system.

Worms aren't the only problem. They are an issue. They aren't the only issue.
Just don't get cought with your shorts down.

And... don't wait for someone to fix it... yeah it'll happen in 10 or 20 minuts (vs the 10 to 20 days for Microsoft) but as we learnned with the last Unix worm..

Min 1. You learn about defect
Min 2. You look for someone fixing it
Min 3. You find someone
Min 4. You wait
Min 5. You wait
Min 6. It's done.. you download
Min 7. Your still downloading
Min 8. Hmm the network seems a bit slow.. your still downloading
Min 9. Why is the network slow?
Min 10. Your crashed... you got the worm before you got the patch... you lose try again..

If someone fixes it first.. horray... if not.. don't wait...

However rember this stuff requires a major deffect in the system to work. It'll only effect one platform and only one version of that platform.
(With Linux it'll hit many distrobutions unless it's a distro screw up and not a real software defect..)

Re:Rest easy but not blindly

[Rupert]

It's not an irrational fear. Service packs for NT (particularly SP6) have been known to do horrible things to third party applications. I had an application that ran just fine on SP3, but when we went to SP5 (might have been SP4) for Y2K, I could not get it to work. Eventually I rewrote it from scratch using a different set of APIs.

Re:IIS doesn't need to run as root

[sammy baby]

I've never seen an Apache server running as root (except for the initial start-up process). Even in my greenest sysadmining days, I never set up Apache to run as root. And believe me, I did some dumb-ass things.

Worms in the Unix world are rare

[jd]

for a reason. There is next to zero similarity between any two installs of even the same kernel, and even less between two different kernels.

With no guarantee of any given system calls, any given system libraries, any given applications, any given directory structure, any given TCP/IP stack, any given version of any given implentation of any given service, any given architecture or any given dialect of any given scripting language, worms have a limited scope to work with.

The "Original" Internet worm was so dangerous, because at that time there was less diversity. Certain standard daemons were virtually guaranteed to be running, for example, built from basically the same source.

Therein lay the danger for Unix - without diversity, a single virus or worm can cause untold damage. If it can affect one machine, it can affect many.

(Biologists have woken up to the same lesson. For years, it was preached that simple systems were more stable than complex ones, but it was learned the hard way that that was not the case. Biodiversity offers protection, because it inhibits the spread of hazards. By making it non-trivial for an infection to pass on, you could guarantee that real-world viruses were self-limiting in scope.)

Linux is relatively safe from virii and worms, for that same reason. There is sufficient diversity to ensure that propogation is non-trivial. The very "irritation" that turns away so many is Linux' greatest shield. With Windows, it's trivial to infect a registry, because there is only one and there's a standard way to access it. Linux has many "registries", and much code that people use won't be registered anywhere at all.

Then, there's libraries. Windows 9x uses certain very standard libraries. If it's a 9x OS, you know what you can expect. For Linux, you've got elf & a.out formats, libc5, glibc 2.0/2.1/2.2, XFree 3/4, Bind 4/8/9 (or any number of alternative resolvers, including the one built-in to glibc), etc. You really don't know what to expect.

Scripting languages? There's no telling WHAT anyone'll have. The only thing you can be sure of is that there will be a /bin/sh, but that might be ASH, BASH 1.x, BASH 2.x, or any other shell that someone decided would be fun to use as standard.

To stay resident, the virii or worm also has to find a place to stay. Not easy to do, with Linux. With Windows, you've a choice of FAT16 or FAT32. Oh, and maybe NTFS, if you're using NT. With Linux, you could be using almost anything. Sure, people will probably use what's installed as standard, as FS migration is non-trivial, but that still leaves ext2, ext3, reiserfs or XFS, all of which one distribution or another uses.

Finally, there's security within Linux. But which security are you using this week? There's GRSecurity, LSM/SELinux, RSBAC, POSIX ACLs, various other ACL implementations, socket ACLs, and any combination of the above.

Oh, and that's not including intrusion detection software, honeypots, firewalls, and all sorts of other similar code.

In short, you can envisage a worm or virus which affects Red Hat 6.2 / Intel distributions that use the standard libraries and kernel. But you can't have a worm or virus which affects ALL running Red Hat Linux boxes - the variation is just too great. It gets much worse when you talk of all Linux boxes, and many many orders of magnitudes of absurdity greater when you talk of all POSIX-compliant UNIX kernels.

To answer the original question of "is the Unix community worried about worms", the answer is "that depends on how homogenious any person's network is". The "worry" level will probably be about the same as the homogeniety level.

As for the community at large, the answer is probably "no". The community at large has such a high level of diversity that there is no single threat which could affect every system (or even a significant fraction of them).

Re:Worms in the Unix world are rare

[WolfWithoutAClause]

I don't know... There have been some very nasty bugs in, for example, TCP-IP protocol stacks. They have been traced back to the same implementation across Windows, Linux, BSD etc.

The one I was thinking of was capable of nuking most operating systems by injecting odd length packets (close to 64K in size).

There's more commonality than you might think in places.

Re:keep your code clean?

[gimpboy]

not to mention that unix operates on a different paradigim than windows. this paradigm operates on all levels from program design (automatic execution of arbitrary code sent to you from an arbitrary source) to genreal security within unix (the concepts of a single user with administrative rights which the user does not always operate as).

Hopefully not

[dead_penguin]

I think that it would be *possible* to write a worm targetting Linux machines right now, but it probably could never spread as quickly as the recent MS-specific worms we've seen. Even though many (most?) Linux distributions come with some relatively serious security flaws out-of-the-box, Linux is still a "geek OS". The average Linux user hopefully knows enough to apply most of the critical security updates, and won't be running too many unneeded services. Add to that the fact that while growing, there still aren't *that* many systems out there running Linux, and I'd say that the density of vulnerable Linux boxes out there is so low that a worm would have a difficult time spreading.

As far as the future goes, though, unless the various distributors become more and more security conscious (I believe that they are doing this), we may be at risk. Doing such things as running potentially vulnerable services as their own userid, turning off unneeded ones, and only opening ports with an actual service that needs it open to the outside may seem like common sense to hopefully all of us, but these are things that distributions should automatically do for the newbie users.

Doesn't anybody remember the Lionshead Worm?

[Craig Maloney]

Linux already has had a worm (or at least Redhat did). It exploited a problem with rpc.lockd. I still get portscans on 111.

How quickly we forget that Linux too is vulnerable.

Re:Doesn't anybody remember the Lionshead Worm?

[Lxy]

How quickly we forget that Linux too is vulnerable

ipchains -A input -i eth0 -p tcp -s any/0 111 -j DENY
Yes, linux is vulnerable. Simple recipe for keeping it safe: if you don't need it, turn it off. If you do need it, study the security history and upgrade the daemon if necessary. If it's sendmail, install postfix or configure it as non-root. If it's WU-ftpd try Pure-FTPD.

On a side note, a default install of most linux distros turns a lot of stuff on that shouldn't be running if it's world accessible. So, like NT admins, linux admins need to study their install and find out what's there that you don't want. Upgrades are sometimes needed, services need to be stopped. The good news is that all linux worms to date are nothing more than automated script kiddies so if you've kiddie-proofed your setup, chances are you're OK.

Worms? No.

[fmaxwell]

I'm much more worried about rabies and distemper.

Re:Can't happen

[Tim C]

No one runs *nix as root.

No, they don't. But many, many daemons and other long-lived processes run as root.

A quick scan of the processes on my machine right now shows kdm, X, kppp, pppd, cupsd and a few others.

On our production servers at work, resin runs as root - I have been reliably informed that it has to (at least, I assume our systems team are reliable - they were rather upset when two of us demonstrated ftping a file onto the server that allowed arbitrary commands to be run :) ).

Just because there's no-one sat at the machine, launnching xterms and applications as root, doesn't mean that there isn't a whole bunch of stuff running as root. A single buffer overrun exploit in a network-aware daemon running as root, and your machine is wide open, if you're not behind a firewall.

Cheers,

Tim

Realm of Possibility?

[Accipiter]

Hello?

Ramen? 1i0n? Adore? Sound familiar? It's far from the "realm of possibility" - they've already been done. And these worms haven't been eliminated, either. I work in network security, and I see SunRPC scans and DNS scans, and a whole slew of different kinds of scans on my network *several times an hour*. Yes folks, *hour*.

The fact is, people are running unpatched systems. And yes, a good majority of these systems are running Linux. The fact that the scans aren't letting up says that administrators:

A) Are too ignorant to know there's a problem
B) Too ignorant to fix the problem
C) Don't give a shit.

The thing is, the Open Source community is quick to act on these security problems and crank out a fix. In the case of Microsoft, the worms are usually a lot more destructive, thus, they receive more attention.

It's quite sad when people can't patch a two-month old exploit, however.

How about a cross-platform worm?

[Sabalon]

Now that would be an achievment. If you found a hole in Linux/BSD and found one in Windows (no biggie), then try for either platform. And have that platform try for either platform. Nimda, from what I understand, took a step in this direction in that it went out with e-mail and http.

About the only worry I have about worms is all the impact on the network as a whole and the PITA my job is whenever one gets out.

I'd be DAMNED worried

[fobbman]

Is the Unix Community Worried About Worms?

If some of you hardcore *nix users would take showers more often than major holidays this wouldn't be an issue.

Those of us who have to sit in stuffy cubicles within a 10' radius of you thank you for your consideration of this matter.

RTM - NOT the first worm...

[Zwack]

Despite having seen it stated several times here, the RTM internet worm of 1988 was NOT the first worm. It wasn't even the first worm to crash machines, or the first network distributed attack...

In 1980 Xerox Parc published a paper called 'Notes on the "Worm" Programs -- Some Early Experience with a Distributed Computation' by John F. Shoch and Jon A. Hupp. This describes some WORM programs that were written at Xerox PARC and used for useful things. Unfortunately an error in one of their programs caused a lot of dead machines.

I think that the BITNET christmas card "virus" of December 1987 predates the Morris Worm of 1988. This was more of a trojan than a worm, but when you ran the "card" it mailed itself to everyone it could.

Neither of these was Unix based.

Z.

A few points:

[larien]

1. Linux has a greater variety of software. Look at mail servers; we have exim, postfix, qmail and sendmail. A vulnerability in one cannot (easily) be exploited in another. The single largest target is Apache, which is by far the most popular web server software (with good reason; it is of very high quality). However, Apache has had almost no serious security flaws that I can think of; most exploits against Apache have exploited password sniff attacks or poorly secured applications hosted on the system, not targets for worms.
2. On similar notes, even if linux/Unix takes over the world, there is likely to be a greater diversity of OS versions. At the current time, I can't see linux wiping out Solaris and AIX for a few years; I can see them coexisting and hopefully taking back ground from Windows, however.
3. Even if linux takes over, wiping out proprietary Unix, there are still likely to be different hardware architectures in use (eg, x86, Itanium, Sledgehammer, SPARC, PPC, S/390) limiting the impact of a worm. By contrast Windows is x86 only (at the current time, although Itanium may come in soonish) which provides easier spreading of worms.
4. While many MS server programs run as system or equivalent "super-user" type user ID's, many linux programs spend most of their time running as a non-privileged user (eg, apache runs as nobody or www, qmail runs as various uid's). Thus, the effect of an exploit is greatly lessened. The use of tools like chroot can also help lessen any impact (although chroot is not a foolproof solution).
5. *nix worms have already hit; Solaris had the sadmind worm, linux had lion. They hit for the same reasons Code Red hit; unpatched systems. These had less impact, but it has to be asked whether that was due to lower market share or better security policies of administrators.

There is the potential for these worms to hit, but I think the general architecture of linux and the diversity in applications should help to lessen the impact of such worms.

Re:A few points:

[Graymalkin]

Are you related to the rest of the retards posting on here today? Your first point is just ludicrous. There is alot of Linux software but there is a ton of Windows software as well. Just like Windows, for every one good program there is a slew of shitty ones. So the number of apps a system has has nothing to do with its quality. Your second point lacks merit because you're comparing an OS originally written for 386 computers to Unicies that are designed to run on massively parallel systems with upwards of 64 processors and countless gigabytes of memory. As for point three, the architecture the system runs has little to do with system specific virii. Linux running on any ISA is going to have the same compiler which compiles and links shit the same way. This says nothing of logic exploits, if the same logic is shared on a bunch of ports the same exploit will exist. As for four, you're just a retard. That's all I can tell you. Windows NT has always had protected memory and support for multiple users. You can run whatever you want as whoever you want. Because you run around as administrator is not anyone else's fault.

Re:A few points:

[markmoss]

Do remember that the first Unix was written for the PDP-11. An original IBM PC (8088 4.7MHz) is a powerhouse next to that. I suspect that the first Unix was security-free. It was written for the computer shared by Bell Labs programmers -- any security you could have implemented on that pitiful machine wouldn't have lasted an hour against one of those guys, so it was better to just trust them not to foul their own nests.

That was in 1971, I think. Unix has come a very long way since then, including many security patches. One advantage it has is that it's 10 years older than DOS/Windows, so more holes have been patched. Another is that it was on multi-user computers from the beginning, while I think MS's first OS for servers (Win NT) first came out in the 90's -- so the unices may have a 20 year lead in thinking about security. And finally, some unices are open sourced, and even the proprietary ones are far more open about the way things work than Windows -- so there have been more friendly eyes looking for holes.

There used to be mainframe OS's that were designed for security from the ground up. I wonder how those would stack up against the unices and Windoze where security was patched in after the original design was set? I think not so good anymore -- they haven't been exposed to decades of probing...

C came out of a similar environment at about the same time. Hence all the standard string functions that simply trust the users not to do something that overflows the buffers. Actually checking for overflow ate up too many cycles, so they trusted the users instead. But why are we still using these unsafe functions?

Re:A few points:

[Graymalkin]

Unix is alot less like a true OS and more like a specification. There's the Bell Labs implimentation of Unix as well as the various schools'. Don't be so sure that lots of eyes works to find lots of holes. Alot of people can look at source code but only a handful of people actually understand what they're looking at. Do you think all of the open source zealots on here can do anything more than compile stuff from source? Not really. Systems are only as secure as you design them to be. Security cannot be added as an afterthough, into any system. As for C libraries with security holes in them, it just goes back to the axiom regarding security. It can't be added as an afterthought. You can't just patch libc and have it be secure, you have to write an entirely new library designed from the getgo for security. Since it has yet to make economic sense to do this and break compatibility with everything no one has gone out and done it.

Re:A few points:

[larien]

Much as I'd rather not rise to this, I think certain points have to be made.

"There is a tons of Windows software as well". How many Windows sites actually run anything other than IIS/Exchange/Outlook? I'm pretty sure it's a minority (<10%?), while there aren't any linux programs with as great a market share under linux (except Apache as I said). In any event, I said nothing about quality; a worm relies on homogeneous systems to operate, so variety lowers the infection rate of the worm.

I wasn't comparing Unix to linux in any way, merely stating that linux is likely to coexist with versions of Unix which increases variety and lowers the impact of a worm.

Architecture: see above. Ok, it's probably possible to write the code so it can operate on multiple ISA's, but that's extra work and in any event, some ISA's handle stacks in different ways, so there's the potential that buffer overflows won't work in the same way. Also, Sparc CPU's (possibly only sun4u) have protected stack; set a kernel parameter and buffer overflows can be limited.

Yes, Windows NT has had protected memory and support for multiple users. However, how many IIS sites run as anything other than system? Does IIS even work as an unprivileged user? Compare this with qmail & apache which by default install as an unprivileged user.

Re:darwinism at work in open source?

[Graymalkin]

Were you dropped when you were little? Your conclusions are pretty ridiculous. You're equating that open source projects must be of higher quality because there are more people working on them. Completely ignoring the fact that not all programmers have the same capabilities. To use your natural selection analogy in a correct fashion, corporate development houses have to operate within margins. This means they have to produce a product garnering so much return for so much effort. Thus the developers they have are very highly skilled because it does not make economic sense to have a bunch of shitty programmers. If good programmers produce bad software it is usually a management issue. Non-professional developers are a much wider swath of skill levels. Most aren't good programmers in any sesne while others are exceptional usually do to professional training and experience. The other aspect anyone has to regard is reliability. Are you going to wager mollions of company dollars on the work of volunteers with schedules that are impacted by their own jobs and even at times school? Well you probably would because you're mentally retarded.

Is the Unix community Worried About Worms?

[totallygeek]

no

hybrid vigor

[hugg]

I think one of the reasons that Linux/BSD/etc are more resiliant than MS OS's is that there is much more diversity in the open-source gene pool. There are so many Linux distros, BSD variants, installation options, etc. that a worm might have a hard time propogating for very long, due to the high variablity among servers.

MS OS's, on the other hand, install to almost exactly the same configuration every time, and users don't usually bother to change many options. And there are only a handful of MS OS's, compared to open-source land.

In the wild, hybrids seem to be more resistant to disease, more adaptable, and generally hardier. Linux/BSD are mutts.

Worm propogation is exponential

[Brighten]

Worm propagation is one of those n squared problems

Actually it's one of those exponential problems. If we start with one infected system and every infected computer infects n more computers in an hour, then on the tth hour, n^t new systems will be infected. For example, if n = 2, then after 24 hours, then 33,554,431 systems will be infected. Of course, in practice, we run out of uninfected vulnerable systems after a while.

Error

[SilentChris]

"Dispite the difficulties in starting a worm on a Unix"

Error: Unjustified statement. Requires backup evidence.

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.

Re:Well...

[Scoria]

How exactly is my reply offtopic? Moderators on crack again, I suppose. My point was this:

Someone will write a worm that attacks not only Windows, but all variants of Unix as well. It will keep a database (or even download the information temporarily from a website) of exploits.

My point was that it would be a big (as in file size) worm, and then I added a little bit of humor at the end.

Never a better time to be a girl

[Graymalkin]

I really love the "my answer to a Linux exploit is apt-get update" posts. Nothing like trusting a completely automated process to solve all of your problems. All it would take is a nice little bit of malicious code in some header to fuck a bunch of people over. If you're not going to review the code before you install it why the fuck are you so anal about using open source software?

Re:Never a better time to be a girl

[Raven667]

Many deb packages, prolly including the ones on security.debian.org are GPG signed. You can get the Debian project's keyring, verify it and then know that the update you are getting is legit.

Re:darwinism at work in open source?

[Graymalkin]

Don't be a fucking moron by insisting that a bunch of developers looking at code is going to default make a better project. You seem to ignore all of the open source software which just sucks fucking dick. All of the core GNU tools were written by professional code writers who knew what they were doing. The more brains on the ball as you say solve no problems if none of the people know what they're doing. Where do you think people who know what they are doing get their experience from? Sorry but school don't teach you shit about real programming.

Tarpit - May not work next time.

[Midnight Ryder]

maybe that should be a standard service? add the ports exploited to tarpit.rc ..

of course that wouldn't solve much but it would be something to start with.

You are right - next time, the worm author might do something different just to make sure LaBrea isn't nearly as effective. For instance, by keeping track of how long it's taken to do it's job, the worm may just abort the thread if it takes, say, 20 seconds to send over part one of the exploit. LaBrea becomes a small slowdown then.

There's not a 'real' answer to stoping worms and the sort, except for administrator vigilance. No matter what OS you use as a server platform (or a mix of things, like my network), ya gotta be quick with the patches and vigilant with security.

As for reversing attacks, etc - there's some severe problems there. You are attacking someone else's hardware - even if the script kiddie may be controling it, they may be on someone else's machine doing it remotely. screw up that person's box, and you might have a problem. (Of course, there's other ethical issues here - I'd really like to just view it all as 'self defense' when you throw an attack back at an attacker online. Unluckly, there's no real presidence for that, I'm not sure there should be!)

Auto-update / auto-patching BAD!!!

[Midnight Ryder]

Or any other form of auto-updater. Remember, Code Red and Nimda used holes that were patched months ago.

No way - this is a very bad solution for security. While at first this would seem to be an absolutely good idea, in reality there's a number of really nasty security problems here.

First, it convinces you to be lax about security. I mean, if the Auto-updater is handling the job, you probably won't check it out too closely since it's not nessisary. But with patches sometimes comes new holes, and new procedures for properly securing a box. These are jobs that require human intervention.

Second, a new class of exploit comes along - using whatever proceedure you can make work, upload a new patch to the ftp server with some less than obvious holes in it. Sure, someone is going to spot it - maybe hours, maybe a couple of days, but it WILL get spotted. As admin, will you know if your box was one that grabbed the bad stuff? (Note, I said upload it to the ftp server, that's not the only exploit - various redirection techniques could be used too.) If tons of people moved to the auto-update idea, there'd be the potential for a lot of exploited boxen quickly.

And third, there's the issue of reviewing patches / updates. Sure, lots of people have viewed them. If it's security related, you should be viewing them too, or at minimum the 'readme' or equivalant.

Fourth, what update time are you planning? Once a month? Once a week? Daily? If it's less than daily, then you've got a problem - of you do grab a buggy version, that gives someone time to attack. And if it's a week before you check again, that means they've got pleanty of time to use your machine as a base to launch more attacks from. Plus, once they have the machine, you may only THINK you are still doing updates ;-) (It's always better from the attacker's standpoint to make things seem just fine and dandy :-P )

I'm sure there's a lot more that could be added to this list - this is just the problems off the top of my head. But those problems alone are enough to really screw things up.

Linux has plenty of resistance

[Philbert Desenex]

I sincerely doubt we'd seem a very infectious worm like NIMDA even if Linux were a very common OS. A NIMDA style worm that propates via email clients and web servers faces a bigger uphill battle in the Linux world than in the IIS world. For starters, there are way more semi-incompatible Linux distributions floating around - it wouldn't be uncommon to find a RH 6.x server would it? There's more variation in web servers, too: Apache, WN, thttpd and others all have a presence. That means that the web server vector has barriers to propagation, one buffer overflow won't cause every web server to become a propagation vector. One IIS buffer overflow cause the Code Red worm. There is more hardware variation: Linux runs on x86, SPARC, Mips and Alpha CPUs. Shellcode to run on all 4 architectures would be difficult if not impossible. There are *vastly* more email clients in common use in the Linux world than in the Windows world: mailx, pine, elm, mutt, Netscape Communicator, balsa (?), etc etc. These various email clients don't share a common scripting language, address book, or even a common format for saved mail. Most if not all of them don't "launch" executable attachments. This would lend resistance to the Linux population.

In short, the monoculture of MSFT products (IIS, Outlook, Win32 and x86) is probably at fault for the Code Red, SirCam and NIMDA problem, not mere popularity.

No.

[ffatTony]

A worm that overpowers apache and executes code on my machine as user 'nobody' (The user my apache runs as) really doesn't concern me. I suppose it could delete most of my /tmp partition.

Re:better packaging = less vulnerability

[SuiteSisterMary]

fictional reprint
A peer of mine is a sys admin for a group of Windows 2002 machines. Once a week AutoWindowsUpdate runs to automatically get all the security updates and install them. This is a check box for him. According to him, it will even download an update to IIS, stop the WebPublishing service, install the update, then restart the service -- all while he twiddles his thumbs and thinks about lunch. With this kind of automation, who knows what kind of holes and backdoors M$ is automatically installing for him, and who knows what data it's sending back? And how does he know that it's not installing a new worm? </fictional reprint> Oh wait, I forgot. It's differnet when Linux does something.

Brought down the entire USA

[peter303]

Most internet connected computers when hosed
in 1988 during the Morris worm. But it was
mostly just universities and few military.

Marketshare doesn't matter

[Philbert Desenex]

That's right: marketshare doesn't matter. And here, I'm taking "marketshare" to mean either (a) the number of servers sold or (b) the number of servers running.

The reason why marketshare doesn't matter: every server connected to a TCP/IP network is "touching" every other server connected to that network. Marketshare has no bearing on which servers can possibly infect which other servers in a population, only connectivity does. Essentially, the "population" of unix servers on the internet all "touch" one another, just like the population of all IIS servers "touch" one another.

That said, it hasn't really been a banner year for Linux/Unix/BSD worms. We've seen adore, l1on, cheese, ramen, sadmind/IIS, lpdw0rm, and x.c. Absolutely none of these worms ripped through the Linux/Unix/Solaris/BSD population. This is indisputable. The question is why does one population have resistance, while the other doesn't? I think the answer is diversity on four levels:

• CPU architecture. Sure, Linux/Unix/etc boxes are far and away x86-based, but having a sprinkling of SPARC, Alpha, Mips and PPC probably makes a difference - no single shellcode or exploit covers all architectures.
• OS architecture. Instruction-level calling sequences probably prevent a "universal" shellcode from working on all OSes that a given CPU architecture runs.
• Web server variety. Sure, Apache dominates, but WN, iPlanet and thttpd have a presence.
• Userland software variety. A huge variety of email clients that don't share a common scripting language or address book format keeps NIMDA and SirCam like things from happening.

Re:Windows update isn't very good.

[Genom]

Heh...leave it alone for a month or so (because it's running so well, you don't bother to think about upgrading), and have that be a month with a lot of changes to GNOME/KDE (assuming you're one of the folks who enjoys one, or both of those) -- THEN you'll see some big download sizes.

BUt you're generally right. Incremental updates to Debian are fairly small - I generally don't see more than 500k-1meg per session - more if I leave it longer (and MUCH larger in the above circumstance of both GNOME and KDE being upgraded!).

Re:Never a better time to be a girl (?)

[dvdeug]

Because somebody can. I can blindly trust some anonymous person somewhere who knows that I can't check him; or I can trust a fellow developer, who will get expelled from Debian if he tried to "fuck a bunch of people over" (i.e. accountability.) At least 3 or 4 people see any change that goes into any major program, and any number of people can look at the code, at any time. If you put a back door in, you will be found out, sooner or later, and people will know who did it.

Re:better packaging = less vulnerability

[SuiteSisterMary]

Yes, I know all of these points. I also know that any sys admin worth his salt would never use one. A real sys admin would have a test box, preferably a test lab, and would test each and every patch before ever DREAMING of putting it in a production envrionment. A real sys admin would also, even after doing said testing, never install off of a third party server. Too untrustworthy. What I was attempting to point out was that if Microsoft did the exact same thing, and I mean EXACTLY, /. would be up in arms. I'll also point out that I highly doubt that even 95 percent of the Linux User community could competently 'check [the source] out if need be.' There's a big leap between hello world, understanding c/c++ and understanding whatever networking protocol is at hand.

Worms ARE a Linux thing, and they're rampant

[Nailer]

Hasn't anyone ever heard of...

l10n

Adore

Ramen

Et al? These things are rampant and generally attack older Bind, lrpng, or wuftpd (Damn those rappers and their shitty FTP server!). Run up2date or whatever your distro uses and you won't get them. Just like running Windows update on an IIS box, really...

Re:Worms ARE a Linux thing, and they're rampant

[Nater]

And don't forget...

Cheese

...the friendly worm.

Marketshare

[Raven667]

The only thing stopping it these days is Linux's smaller marketshare. (Worm propagation is one of those n squared problems).

That doesn't make the slightest bit of sense. Apache has 2 or 3 times the marketshare that IIS (including derivitives like PWS) has. An Apache exploit comperable to the IIS one would rip through the network like fire and could easily take down the majority of servers. One of the reasons that this hasn't happened is that Apache was coded far more carefully than IIS. Annother important reason is that Apache servers are not a monoculture. Apache runs on many different CPU arch's and many different OS's preventing the "One True Shellcode" from working (not that a worm coulnd't have a library of shellcode for many different platforms) Permissions on UNIX hosts tend to be slightly more sane out of the box as well, not great but better than the competition.

There have been several RedHat (not Linux or Unix in general) worms recently, but they just weren't that obnoxious (not that there weren't quite a few fire-and-forget RH6.x boxen around). RedHat isn't making the same mistakes again, RH7.x doens't turn on every installed service by default and optionally can setup firewalling rules that protect your machine from attack. Mandrake has a "make secure" button that does a pretty good job of locking a machine down and distro's like Debian try to err on the side of security whenever possible.

I'm rambling but Unix servser are generally more hostile to attacking worms than other environments. Any monkey can setup an IIS server but the results tend to be slipshod. Any monkey can setup an Apache server as well but the results tend to fair better when exposed to the open cesspool of the Internet.

Blargh

Re:IIS doesn't need to run as root

[NutscrapeSucks]

IIS runs as a user other than the administrator, and scripts under IIS run as yet-another-non-administrator user

This is wrong. IIS runs as LocalSystem, which pretty much has full rights to the local machine, and more privs than Administrator for certain things.

There's a good reason for this -- It needs system access so that it can use security impersonation and run scripts as the local user (IUSR_foo or who ever's logged in). The problem is, if someone finds a bug before the user identity is switched, they've owned the machine.

(I think IIS 5 does support non-System users, but you lose the ability to impersonate someone else.)

Re:better packaging = less vulnerability

[KodaK]

A real sys admin would have a test box, preferably a test lab...

A real sysadmin has to deal with budgets, and can't buy jack. A real sysadmin will then play BOFH and utter the phrases: "Oh, I'm sorry, your files were wiped out, that's too bad. Here, hold this cable, Mr. Boss. Oh, well, I guess had I a couple of test boxes I would have known not to plug a Cat 5 patch directly into 110VAC. Sorry."

Ahem. Sorry for the lapse into fantasy, go on about your business.

Single rock-solid point of failure

[roystgnr]

In any auto-update system, there is a single point of failure... but it is not the server that hosts the update packages, it is the computer that signs the packages! If you compromise the file server, you can destory the signed packages, but you cannot insert your own malicious packages without compromising the computer with your OS provider's public key.

And this signing computer can be ultra secure. It doesn't have to be on the network at all; a CD writer would be sufficient. It doesn't have to be running an architecture or operating system remotely related to anything else, just something capable of running GPG. You could have it loaded to the brim with intrusion detection software, you could have the entire OS on read-only media, you could do all sorts of things that just can't be done on all the random computers out on people's desks.

Auto-updating does introduce the possibility that a malicious employee could introduce trojan packages... but they could be doing that right now, just as easily, just a little more infrequently. "seineew era sreenigne epacsteN", anyone?

Virus/Worm writers are smarter than that...

[sheldon]

Nimda was sort of a best practices of Virus/Worm writing, because it had the behavior of both.

It would infect executables, or web files. It could spread by the infected executables on shares, or by people browsing to infected web servers using old versions of IE. It also tried to scan the network looking for vulnerable IIS servers, as well as trying to email itself the same way Sircam did.(i.e. it included an SMTP piece)

The point is that it was written to try multiple vectors of attack, such that it's chances of finding a vulnerable machine were much higher.

The only thing that slowed it was that the Code Red incident had caused many, if not most, people to install the latest patches on their machines.

Another example, the sadmind worm effected both IIS and Solaris boxes.

I guess the point is, try to build diversity and the world just builds a better worm/virus writer.

P.S. The cluefulness of the general Linux administrator is actually pretty low as it tends to be primarily popular with inexperienced college students.

It also doesn't take much work at all to effectively admin an NT box. But most NT admins also have other priorities put upon them by their corporate bureaucracies.

Uh, there weren't no Windows servers back then

[leonbrooks]

And no MS-DOS to speak of connected to the 'net. One of the few epidemics that Microsoft weren't to blame for. (-:

I guess disconnecting every Unix box from the net would solve the problem in that very few Unix boxes would get worms. Of course, not having a working internet anymore could be a bit of a handicap, sort of takes the sting out of not being able to connect to it...

One-shot self-defense ``worms'' already exist

[leonbrooks]

What I think would be interesting, is a Linux worm that used a security hole to get into a box

I've seen several reactive programs on FreshMeat which respond in various ways to attacks like CodeRed (finding and emailing the administrator is typical), and similar PHP packages released through various sites.

I've also seen several which fight back (note the lack of URLs at this point) and one system which uses spare machines to absorb TCP connects from infected hosts and keep them alive to gobble up sockets on the attacker and lock down the attacking threads.

It wouldn't be a big step from there to send back a payload which locks down the attacker, which then waits to be attacked so it can respond in turn.

Re:better packaging = less vulnerability

[SuiteSisterMary]

Exactly! And through such time-honored methods, a real sysadmin would GET his test boxes! At the very least, a real sysadmin would put all of the pros and cons into an email to somebody with Authorith, and get a cya email back. :-)

Re:darwinism at work in open source?

[Graymalkin]

Tens of thousands of people that work on Linux? Right. You can name lots of shitty closed source programs as well as open source ones. The original contention was that open source is somehow naturally superior to closed source. That's like saying your product is 100% more effective than sugar pill.

Re:darwinism at work in open source?

[Graymalkin]

I wasn't suggesting corporate development schemes were the greatest, just discounting the suggestion that open source is naturally superior to closed source development. Just because it is your personal favourite doesn't mean it's better. By the same token you can compare Japanese and American manufactured cars and spout off that one is inherently better than another. The fact that you and another dude had the same kneejerk reaction just makes me sad. Now I realize how many people sit back and believe the FUD open source developers use against the FUD of closed source developers. Pot, kettle, black.