Slashdot Mirror

The worm's main code wasn't BSD-specific. It could infect 4BSD systems on DEC VAX machines, and Sun 3 systems. These systems bear no similarity to todays OSes

The worm's infection vector was a portable C stub though "11.c", and was OS-agnostic. It could "hurt" systems running other OSes, even though the main code would not run.

It exploited vulnerabilities in rsh, fingerd, sendmail, and attempted to crack weak passwords. Facilitated by the fact that "encrypted" passwords were publicly visible in /etc/passwd and valid usernames on one machine are likely valid usernames on other machines.

It was not a trojan.

Link: Although sendmail was the Worm's least favored attack method (it was only tried after all other attempts had failed), it too was a powerful method of intrusion. At one site in Utah, nearly 150 sendmail attacks were logged on November 2 alone.

The Worm takes advantage of a flaw in the TCP networks for Berkeley UNIX systems (used in sending e-mail). When the program was being designed, a DEBUG flag was included with it in order to facilitate testing of the program. One of the capabilities of this flag was that it allowed someone to send mail to a process, rather than a user account. Unfortunately, when the program was finished and compiled for distribution, this feature was never removed. ...

The worm's main code wasn't BSD-specific. It could infect 4BSD systems on DEC VAX machines, and Sun 3 systems. These systems bear no similarity to todays OSes

The worm's infection vector was a portable C stub though "11.c", and was OS-agnostic. It could "hurt" systems running other OSes, even though the main code would not run.

It exploited vulnerabilities in rsh, fingerd, sendmail, and attempted to crack weak passwords. Facilitated by the fact that "encrypted" passwords were publicly visible in /etc/passwd and valid usernames on one machine are likely valid usernames on other machines.

It was not a trojan.

Link: Although sendmail was the Worm's least favored attack method (it was only tried after all other attempts had failed), it too was a powerful method of intrusion. At one site in Utah, nearly 150 sendmail attacks were logged on November 2 alone.

The Worm takes advantage of a flaw in the TCP networks for Berkeley UNIX systems (used in sending e-mail). When the program was being designed, a DEBUG flag was included with it in order to facilitate testing of the program. One of the capabilities of this flag was that it allowed someone to send mail to a process, rather than a user account. Unfortunately, when the program was finished and compiled for distribution, this feature was never removed. ...

The worm's main code wasn't BSD-specific. It could infect 4BSD systems on DEC VAX machines, and Sun 3 systems. These systems bear no similarity to todays OSes

The worm's infection vector was a portable C stub though "11.c", and was OS-agnostic. It could "hurt" systems running other OSes, even though the main code would not run.

It exploited vulnerabilities in rsh, fingerd, sendmail, and attempted to crack weak passwords. Facilitated by the fact that "encrypted" passwords were publicly visible in /etc/passwd and valid usernames on one machine are likely valid usernames on other machines.

It was not a trojan.

Link: Although sendmail was the Worm's least favored attack method (it was only tried after all other attempts had failed), it too was a powerful method of intrusion. At one site in Utah, nearly 150 sendmail attacks were logged on November 2 alone.

The Worm takes advantage of a flaw in the TCP networks for Berkeley UNIX systems (used in sending e-mail). When the program was being designed, a DEBUG flag was included with it in order to facilitate testing of the program. One of the capabilities of this flag was that it allowed someone to send mail to a process, rather than a user account. Unfortunately, when the program was finished and compiled for distribution, this feature was never removed. ...

http://snowplow.org/ has an online Diplomacy implementation.

...people who cause massive damage on an any scale - economic, physical, emotional - are sociopaths.

I would ammend that to say that people who intentionally cause massive damage are possibly sociopaths.

The history of our discipline is replete with examples of people accidently causing such mayhem.

The "first ever" internet worm, the 1988 internet worm, written by Robert Tappan Morris, brought the internet to a standstill, but was intended to be benign. There was a defect in the worm which caused it to replicate out of control, and eat up all the PIDs on the unix machines it infected (it was actually designed specifically NOT to do this; only one instance should have been running on the infected machine at a time, but software bugs are everywhere).

More recently, a worm intended to patch machines against Code Red had a defect in it that caused some machines to be rebooted without being patched. The "fix" worm was more annoying for many people than the original Code Red was. I had one friend who was unable to patch his system on his dial-up connection, as his machine would be rebooted by the "fix" worm long before he had time to download the microsoft patch.

As they say, the road to hell is paved with good intentions. A university ethics course would force most people to consider the problems with writing a "good worm", but most of the authors involved aren't in university yet.

Although, people who accidently unleash terrible worms are unlikely to be deterred by the death penalty, either.

Okay, so basically this is the problem: when Google encounters a status 302 redirection (as opposed to the status 301 redirection) it then indexes the content as belonging to the initial URL, not the URL at the end result of the 302 redirection. Other things happen later because of google's design.

302 redirections are temporary redirections - the idea is that a 302 is supposed to be used when someone needs to be redirected to a new page, but should still use the original URL if they want to come back later. As an example, the page http://purl.oclc.org/OCLC/PURL/CONTRIBUTORS performs a 302 redirect to http://purl.oclc.org/docs/contributors.html. This means that although your web browser needs to go to some other URL for the content at the moment, they really should remember the first url as the permanent one.

Contrast this with what happens when your browser visits http://snowplow.org/martin - you get sent a 301 redirect to http://snowplow.org/martin/. (Note the extra slash) In this case, the server is saying "the url with the slash on the end is the real location, and you should not try to come back here without the final slash in the future."

Ideally, if every web browser behaved according to spec., bookmarks (remember bookmarks?) would get automatically updated to the new URL when you selected them and the redirect was a 301 redirect. However, for a 302 redirect, the bookmark would stay as is.

302 redirects can be very useful when you want to set up a hierarchy of "logical" URLs that will permanently point to the correct location. 301 redirects are useful when you're obsoleting an old URL and wish people to go and use the new URL from now on.

Okay, so how does this relate to google? Well, let's suppose that you have a great site on fruitbats. I can set up http://www.example.com/topics/fruitbats to be a 302-style redirect to your site, essentially saying "The information at http://www.example.com/topics/fruitbats is temporarily being hosted by http://www.yoursite.com/". Now, google when it spiders pages will see that, will go retrieve the text from your page and will then index it under http://www.example.com/topics/fruitbat, since after all I just gave a temporary (302) redirect.

But it gets worse, because a final part of google's indexing process is to compare pages for identical text, and throw out all but one of the URLs. Apparently this stage has nothing to go on other than the text and the recorded URLs, and so your URL stands a fifty-fifty chance of being thrown out.

Except that I've not just redirected http://www.example.com/topics/fruitbats to your site, but also http://www.example.com/topics/fruitbat, http://www.example.com/topics/fruit_bat, and http://www.example.com/topics/fruit_bats. Now your lone URL doesn't stand much of a chance of being the one kept by the "throw out duplicates" processor, does it?

In a sense, of course, there's little google can do to prevent this, because even if they weighted 302-redirects lower in their "throw out duplicates" stage, I could always just go snag a copy of your website each time googlebot visits, in essence doing the redirection myself. (How? Just search the apache mod_rewrite guide for "Dynamic Mirror") However, doing it through 302 redircts means that google pays for the bandwidth to go get your page, not me. (Not that this is necessarily a signficant amount of bandwidth, since we're only talking about basic google here and not images. Depending on the revenue you get by misdirecting google queries it might be economical)

Of course, for this to really work, I'd need a list of websites sorted by category to build up my redirect db. But wait! The ODP feed provides exactly that.

I am a little bit wary of doi

Okay, so basically this is the problem: when Google encounters a status 302 redirection (as opposed to the status 301 redirection) it then indexes the content as belonging to the initial URL, not the URL at the end result of the 302 redirection. Other things happen later because of google's design.

302 redirections are temporary redirections - the idea is that a 302 is supposed to be used when someone needs to be redirected to a new page, but should still use the original URL if they want to come back later. As an example, the page http://purl.oclc.org/OCLC/PURL/CONTRIBUTORS performs a 302 redirect to http://purl.oclc.org/docs/contributors.html. This means that although your web browser needs to go to some other URL for the content at the moment, they really should remember the first url as the permanent one.

Contrast this with what happens when your browser visits http://snowplow.org/martin - you get sent a 301 redirect to http://snowplow.org/martin/. (Note the extra slash) In this case, the server is saying "the url with the slash on the end is the real location, and you should not try to come back here without the final slash in the future."

Ideally, if every web browser behaved according to spec., bookmarks (remember bookmarks?) would get automatically updated to the new URL when you selected them and the redirect was a 301 redirect. However, for a 302 redirect, the bookmark would stay as is.

302 redirects can be very useful when you want to set up a hierarchy of "logical" URLs that will permanently point to the correct location. 301 redirects are useful when you're obsoleting an old URL and wish people to go and use the new URL from now on.

Okay, so how does this relate to google? Well, let's suppose that you have a great site on fruitbats. I can set up http://www.example.com/topics/fruitbats to be a 302-style redirect to your site, essentially saying "The information at http://www.example.com/topics/fruitbats is temporarily being hosted by http://www.yoursite.com/". Now, google when it spiders pages will see that, will go retrieve the text from your page and will then index it under http://www.example.com/topics/fruitbat, since after all I just gave a temporary (302) redirect.

But it gets worse, because a final part of google's indexing process is to compare pages for identical text, and throw out all but one of the URLs. Apparently this stage has nothing to go on other than the text and the recorded URLs, and so your URL stands a fifty-fifty chance of being thrown out.

Except that I've not just redirected http://www.example.com/topics/fruitbats to your site, but also http://www.example.com/topics/fruitbat, http://www.example.com/topics/fruit_bat, and http://www.example.com/topics/fruit_bats. Now your lone URL doesn't stand much of a chance of being the one kept by the "throw out duplicates" processor, does it?

In a sense, of course, there's little google can do to prevent this, because even if they weighted 302-redirects lower in their "throw out duplicates" stage, I could always just go snag a copy of your website each time googlebot visits, in essence doing the redirection myself. (How? Just search the apache mod_rewrite guide for "Dynamic Mirror") However, doing it through 302 redircts means that google pays for the bandwidth to go get your page, not me. (Not that this is necessarily a signficant amount of bandwidth, since we're only talking about basic google here and not images. Depending on the revenue you get by misdirecting google queries it might be economical)

Of course, for this to really work, I'd need a list of websites sorted by category to build up my redirect db. But wait! The ODP feed provides exactly that.

I am a little bit wary of doi

There have been several Linux worms as well, like the Lion worm. BTW: very interesting story about the origins of that one! Some even stay only in memory after infection, so that you can remove them by a simple reboot (and get re-infected 2 minutes later). Not changing any system files makes them harder to detect.

Usually these don't have as big an impact as their Windows counterparts, I suspect this has a lot to do with the way the average *nix system is managed in comparison to the average Windoze box. Decent built-in security, and software distributed in source form, makes life a lot harder for worms, spyware and shit like that.

...and the likes that bother the end-user directly...

It doesn't really matter if it's a browser-only or other type of exploit. Malware like worms, virusses, spyware, whatever, eat CPU time, memory, can cause unexpected crashes, leak private information, loads of network traffic, or weird/annoying behaviour of your system. In short: they cost you (time and/or money). And what they do (infect other systems, send spam, ...), causes cost on others as well.

No, that's inaccurate.

Worms can spread to other machines on their own. Viruses require some external intervention (such as file sharing or e-mail) to spread to other machines. See this entry in the Jargon File for a more verbose answer.

Now, many of the latest e-mail "worms" would be better classified as viruses or trojan horses, as they are incapable of infecting other hosts without direct user intervention (i.e., opening an attachment.) They've been (IMHO) mis-labeled as worms because they display worm-like behavior once they've infected a machine--that is, they mail copies of themselves as trojan-style attachments to other users.

So yes, the Sasser worm is a bona-fide worm. It transmits itself to other systems without any external help.

Kiddies these days. On one had, Kazaa claims "no disruptive effect" while eDonkey complains about two web sites temporarily knocked out.

Hey, you young punks, in my day we had guys like Robert Morris who was stud enough to make it work on Sun 3's and VAX systems.

Oh and hey, they're still trying to figure out what went down at AT&T on Martin Luther King's b'day back on 1990.

I mean, c'mon, attacking a p2p via Windows that barely crashes 2 websites?

Also, I don't know if you've ever looked at the reversed engineered code the the 1988 Morris Internet Worm source code. Sure it's small compared to an operating system, but it's an amazing testament to the power of good reverse engineers.

A worm is a program that propagates itself over a network, reproducing itself as it goes. While this worm may require user intervention, there exist plenty of worms that do not (the most infamous being the Morris Worm.) A malicious program that masquerades as a legitimate application is a Trojan horse.

SoBig.F appears to be a Trojan with some worm-like qualities. Of course, in the world of Microsoft mail exploits, the lines are blurred, but a worm is generally not a user-launched process.

Pedantic, I know, but worms are a special interest of mine, and they generally take a fair bit more skill to create than your average Trojan horse.

American AC in Paris writes "In this thread, we will describe some very cool features in Mozilla which will enable you to quickly find the maximum load of your web site and applications."

My guess? They'll blame Robert Morris. That's just wild conjecture, though...

(Yes, yes, shameless self-linking. So sue me.)

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

(It's a link to information on RTM's worm, for those who don't feel like clicking the link.)

That's the original version; I've got an updated version (lighter bandwidth, typo fixes, etc.) available at http://www.snowplow.org/tom/worm/. I'm going to be quite hard to get in touch with for the next two months, but if you have any questions, feel free to ask and I'll get back to them as soon as I can.

Tom Darby

Assuming, of course, it becomes even remotely feasible to do either one within the next few decades...heh. What's next?

Maybe this...