Slashdot Mirror

• "...keep in mind that anybody can take over your computer, steal sensitive files, destroy your machine, anything..."

You don't have a f*cking clue.

This is from CERT:

• "...Several implementations of login that are derived from System V allow a user to specify arguments such as environment variables to the process. An array of buffers is used to store these arguments. A flaw exists in the checking of the number of arguments accepted. This flaw permits the array of buffers to be overflowed."

That does not at all translate into "anybody can take over your computer, steal sensitive files, destroy your machine, anything"

Go back to Redmond, M$ whore.

t_t_b

If you reads the vulnerability page at http://www.kb.cert.org/vuls/id/569272 you'll see it has taken 7 weeks from the first vendor response to the vulnerability, to the last one (the last being Sun, yesterday).

You will also see the comment: "An exploit exists and may be circulating.". This means that CERT and Sun have sat on this vulnerability for well over a month without telling anyone about the problem, despite an exploit being in use.

The story 2 days ago about Microsoft security was about a problem Microsoft had known about for 4 weeks (reported to them on Nov 19th).

Finally, the patch is available for IBM's AIX 4.3.3 and 5.2, but not as far as I can tell for Solaris 8.

However much you blindly hate Microsoft, they are not as bad as Sun in this particular situation.

Oh, you mean like Code Red? Yep, that issue certainly wasn't serious.

"The worst an Outlook virus could do on Linux is take out the account of the user who clicked on the attachment."

Sure, because there have never been privilege elevation flaws in common unix software, have there?

I just got in from a busy day and what do I find but a little Snort action on ole Slashdot...

So, I've got a few comments about the comments:

Snort signatures and the quality thereof. Anyone who complains about the quality of Snort signatures is a lazy bastard, they're open source and easy to modify, if you find that much wrong with them make the appropriate changes and mail them back to me or Brian Caswell, our own official Snort Rules Nazi. Just because we write Snort sigs doesn't mean you have to use them, the original concept behind Snort and the rules files that came with the distro was that the users could look at examples of how to write them and develop their own set for the site they were protecting. This has gotten way out of hand over the past three years and has blossomed into the approximately 1300 rules we have now. The quality isn't always the best, but we're working on it (and if you've been tracking them over the past 6 months they've gotten much better.

Performance. People from ISS talking about the superior performance of their solution is laughable, it's been shown repeatedly in third party IDS roundups that Snort performs on par with or better than almost all of the other commercially available NIDS solutions out there. In fact, I know of one large entertainment company that sank a decent chunk of money into hardware that's running Snort at OC-12 speeds on their network successfully with no packet loss at all. Moral of the story? IDS performance is tied directly to the configuration and horsepower of the sensor hardware. No big revelations there. The fact of the matter is that's Snort's capabilities and performance keep increasing as we continue to develop it. We're also about to revisit some major architectural components of the system as we begin development on Snort 2.0 this month, but that's a different topic...

Love Snort but need a commercial company to back it? Check out Sourcefire, a company that I founded this year precisely to do that. We are selling network IDS appliances complete with a web-based GUI, data analysis console, and full blown configuration management system built in. We're also working on a Management Console appliance that will allow you to deploy and manage a distributed Snort NIDS infrastructure and manage all the data that comes out of the system and perform multi-sensor correlation.

Rapid response. When the shit hits the fan on the Internet, Snort is usually the leader in getting out new sigs to the user community. Case in point, the W32/Voyager MS SQL worm that recently came out, we were the first with sigs to pick it up.

So in the end, Snort gives you speed and accuracy (in that I mean you can identify specific exploits very precisely), has an active development and user community and is flexible to meet users needs. I think that this is a really good combo for most people's needs. Now that Sourcefire is out there, I think that the needs of "pro" users can be satisfied as well as those of the open source world.

On the other hand I might be biased, as I did write the thing... ;)

-Marty

How about holding various companies whose products are exploited the most (re: MS) liable for their lack of security?

There was a recent security seminar sponsored by the Georgia Tech Information Security Center by Gene Spafford who is the director of the Purdue CERIAS (Center for Education and Research in Information Assurance and Security), where he mentioned the problems with security and the software industry. One of his slides in his presentation showed that Windows NT and Windows 2000 (combined), RedHat Linux and Solaris are respectively the first, second and third on the lists of OSes that have had vulnerabilities discovered in the past five years.

Legislation that aims to punish companies for writing insecure software would harm almost every company that writes any software that is aimed at being used in a server/multi-user environment since security is an absolute that most non-trivial software does not reach.

Secondly, who will be forced to pay when it comes to Open Source vulnerabilities? wu-ftp is notoriously broken , as is telnetd , sendmail, BIND and some would consider recent bugs in the Linux kernel as OS vulnerabilities. Opening the door to lawsuits to software developers for writing software would probably kill a number of projects rather quickly.

I'd rather that we let capitalism take its course. If customers want secure products then they should stop buying insecure products or they should communicate to the vendors that security is of importance to them. As long as consumers (both individuals and corporate entities) continue to accept the status quo then no change will be made but I don't believe that lawsuits will solve anything except make some lawyers rich and significantly increase the cost of software as the effects of the lawsuits are passed on to consumers.

As for significant incidents, RTM's worm of 1988 is one of the most significant, both legally and technically. There really was little to charge Morris with back then. I think he took a plea on wire fraud and served no time. It may have been the driving force behind the revisions to section 1030 of the U.S. Code. It also resulted in the creation of CERT.

For all the noise, Mitnick and Poulsen's adventures haven't really had that much impact on the legal world. (Though one of Poulsen or Peterson have some significant decision on appeal about special skill/abuse of trust.) The Bell 911 document case (forget who that was) was probably more significant in that it really highlighted how flawed damage estimates can be ($1+ million vs. $17). Poulsen's most significant contribution was probably the ban on using computers while he was on probation. Mitnick has similar restrictions (if not more severe). Every computer case that comes up now has to consider that idea. Poulsen and especially Mitnick served relatively long and hard sentences compared to those who came before them. With the state of federal law enforcement and the federal sentencing guidelines, any future hackers can look forward to similar sentences if they cause large amounts of damage.

I'm not sure what spawned the EFF, but the Steve Jackson Games case was pretty significant and probably resulted in a new law. I forget the name of it, but it essentially provides more search & seizure protection for computers owned by publishers.

• Only use HTTPS, never use just plain HTTP.
  
• Use CGI, Java Servlets, or some other server-side program technology to password-protect the site. I will refer to the resulting program(s) as the security program
  
• Never accept a password from a GET request, only accept them from POST requests.
  
• Never make the user list or password list visible from the internet, not even an encrypted password list.
  
• Never place the sensitive information in a directory the web server software knows how to access. Only the security program should know how to find the info.
  
• Review all documentation for your web server software and the platform used for the security program. Pay special attention to seciurity issues, make sure you aren't inadvertently opening up holes. Keep current, do this at minimum four times a year.
  
• Subscribe to any security mailing lists for your web server platform operating system web server software, and for the programing platform you used for the security program. If there is anything else running on this machine, subscribe to their security mailing lists too.
  
• Subscribe to cert-advisory and BugTraq. Read in detail all the messages that are relevant to your setup. Review your setup after each relevant message.
  
• Don't use IIS.
  
• Don't use Windows 95/98/Me. Don't use Windows XP Home Edition.
  
• Don't use any version of MacOS before OS X.
  
• Don't use website hosting services for sensitive information.
  
• Never connect to this webserver using telnet, ftp or FrontPage. SSH is your friend.
  
• Never have Front Page Extensions (or its clones or workalikes) installed on a webserver with sensitive data.
  
• If there is anything above that you don't understand, or if you can't afford the time for any of the above, hire a professional with security experience and recommendations from people you trust who have used his or her services. It's bad enough that amateurs are running webservers, much less running ecommerce sites and other sites with sensitive data.

Never submit a story about a newly descovered security hole in unix/linuxsecurity holes (and here) about linux generally get ignored.

<slashdotgroupthink>Linux is more secure because it just is.</slashdotgroupthink>

A lot of people here have been asking what people should do after they are attacked. Here is an article/guideline for procedures on recovering after an attack. These steps include information on saving logs, documenting everything that you do after the attack, the type of evidence needed to prosecute, and who to contact (FBI, local police, etc) But as always..the best policy is to secure the system so that attacks don't happen.

For anyone (like me) who hasn't heard of the Linux worms here are some links.

Code Red. Windows
Lion. (1i0n) Linux/UNIX
Sadmind. Sun
Ramen. Linux/UNIX
Nimda. Windows

He seems to complain quite a bit, but offer no real solutions. Basically he seems to be trying to create yet another buzzword, "information anarcy". The problem is that it has no real meaning other than things that make his job difficult.

the one good point he had was:

Finally, information anarchy threatens to undo much of the progress made in recent years with regard to encouraging vendors to openly address security vulnerabilities. At the end of the day, a vendor?s paramount responsibility is to its customers, not to a self-described security community. If openly addressing vulnerabilities inevitably leads to those vulnerabilities being exploited, vendors will have no choice but to find other ways to protect their customers.

does anyone know how much info microsoft actuallyshared about their vulnerabilities before the above hacks were made?

For anyone (like me) who hasn't heard of the Linux worms here are some links.

Code Red. Windows
Lion. (1i0n) Linux/UNIX
Sadmind. Sun
Ramen. Linux/UNIX
Nimda. Windows

He seems to complain quite a bit, but offer no real solutions. Basically he seems to be trying to create yet another buzzword, "information anarcy". The problem is that it has no real meaning other than things that make his job difficult.

the one good point he had was:

Finally, information anarchy threatens to undo much of the progress made in recent years with regard to encouraging vendors to openly address security vulnerabilities. At the end of the day, a vendor?s paramount responsibility is to its customers, not to a self-described security community. If openly addressing vulnerabilities inevitably leads to those vulnerabilities being exploited, vendors will have no choice but to find other ways to protect their customers.

does anyone know how much info microsoft actuallyshared about their vulnerabilities before the above hacks were made?

For anyone (like me) who hasn't heard of the Linux worms here are some links.

Code Red. Windows
Lion. (1i0n) Linux/UNIX
Sadmind. Sun
Ramen. Linux/UNIX
Nimda. Windows

He seems to complain quite a bit, but offer no real solutions. Basically he seems to be trying to create yet another buzzword, "information anarcy". The problem is that it has no real meaning other than things that make his job difficult.

the one good point he had was:

Finally, information anarchy threatens to undo much of the progress made in recent years with regard to encouraging vendors to openly address security vulnerabilities. At the end of the day, a vendor?s paramount responsibility is to its customers, not to a self-described security community. If openly addressing vulnerabilities inevitably leads to those vulnerabilities being exploited, vendors will have no choice but to find other ways to protect their customers.

does anyone know how much info microsoft actuallyshared about their vulnerabilities before the above hacks were made?

For anyone (like me) who hasn't heard of the Linux worms here are some links.

Code Red. Windows
Lion. (1i0n) Linux/UNIX
Sadmind. Sun
Ramen. Linux/UNIX
Nimda. Windows

He seems to complain quite a bit, but offer no real solutions. Basically he seems to be trying to create yet another buzzword, "information anarcy". The problem is that it has no real meaning other than things that make his job difficult.

the one good point he had was:

Finally, information anarchy threatens to undo much of the progress made in recent years with regard to encouraging vendors to openly address security vulnerabilities. At the end of the day, a vendor?s paramount responsibility is to its customers, not to a self-described security community. If openly addressing vulnerabilities inevitably leads to those vulnerabilities being exploited, vendors will have no choice but to find other ways to protect their customers.

does anyone know how much info microsoft actuallyshared about their vulnerabilities before the above hacks were made?

A year and a half old advisory, and sites still refuse to fix it. http://www.cert.org/advisories/CA-2000-02.html

Some of you will remember the problems with Hotmail relating to cross site scripting. Newsflash, it affects your site too!

IIS is attacked because it runs on a platform that is more popular in general.

The windows platform is very popular. Most common desktop by far; sheer numbers makes it a target. Add in that the average user has little IT experience and (either because of design or end user maintenance... or both) that a lot of these machines will be full of holes... great target.

Lets say its not IIS that's under scrutiny but Apache. Very popular. Lots of holes. And a large percentage of the user base tends not to patch holes as they're announced. Great target.

Just because Apache tends to be ran on non-Windows hosts does not mean we can't put them togeather. sadmind did just that. It spread on Solaris systems to attack and deface IIS servers. No reason we can't launch a new Nimda-a-like that propogates amoung windows machines and attackes Apache (on whaterver OS its sitting on) hosts.

But, of course, that's not what is going on. IIS is being attacked because of the virtues of IIS, not because its usually sitting on Windows hosts.

On CERT, I can find SIX exploits in IIS in this year alone.

http://www.cert.org/advisories/CA-2001-26.html

http://www.cert.org/advisories/CA-2001-19.html

http://www.cert.org/advisories/CA-2001-13.html

http://www.cert.org/advisories/CA-2001-12.html

http://www.cert.org/advisories/CA-2001-11.html

http://www.cert.org/advisories/CA-2001-10.html

The last Apache exploit mentioned on CERT happened in 1996.

And remember, IIS only accounts for 26% of all web servers on the net (and Apache accounts for 59%) -- so it's NOT just a matter of there being more IIS servers out there to hit.

By in large, Apache will run just fine OOTB. Can you say the same for IIS?

On CERT, I can find SIX exploits in IIS in this year alone.

http://www.cert.org/advisories/CA-2001-26.html

http://www.cert.org/advisories/CA-2001-19.html

http://www.cert.org/advisories/CA-2001-13.html

http://www.cert.org/advisories/CA-2001-12.html

http://www.cert.org/advisories/CA-2001-11.html

http://www.cert.org/advisories/CA-2001-10.html

The last Apache exploit mentioned on CERT happened in 1996.

And remember, IIS only accounts for 26% of all web servers on the net (and Apache accounts for 59%) -- so it's NOT just a matter of there being more IIS servers out there to hit.

By in large, Apache will run just fine OOTB. Can you say the same for IIS?

On CERT, I can find SIX exploits in IIS in this year alone.

http://www.cert.org/advisories/CA-2001-26.html

http://www.cert.org/advisories/CA-2001-19.html

http://www.cert.org/advisories/CA-2001-13.html

http://www.cert.org/advisories/CA-2001-12.html

http://www.cert.org/advisories/CA-2001-11.html

http://www.cert.org/advisories/CA-2001-10.html

The last Apache exploit mentioned on CERT happened in 1996.

And remember, IIS only accounts for 26% of all web servers on the net (and Apache accounts for 59%) -- so it's NOT just a matter of there being more IIS servers out there to hit.

By in large, Apache will run just fine OOTB. Can you say the same for IIS?

On CERT, I can find SIX exploits in IIS in this year alone.

http://www.cert.org/advisories/CA-2001-26.html

http://www.cert.org/advisories/CA-2001-19.html

http://www.cert.org/advisories/CA-2001-13.html

http://www.cert.org/advisories/CA-2001-12.html

http://www.cert.org/advisories/CA-2001-11.html

http://www.cert.org/advisories/CA-2001-10.html

The last Apache exploit mentioned on CERT happened in 1996.

And remember, IIS only accounts for 26% of all web servers on the net (and Apache accounts for 59%) -- so it's NOT just a matter of there being more IIS servers out there to hit.

By in large, Apache will run just fine OOTB. Can you say the same for IIS?

On CERT, I can find SIX exploits in IIS in this year alone.

http://www.cert.org/advisories/CA-2001-26.html

http://www.cert.org/advisories/CA-2001-19.html

http://www.cert.org/advisories/CA-2001-13.html

http://www.cert.org/advisories/CA-2001-12.html

http://www.cert.org/advisories/CA-2001-11.html

http://www.cert.org/advisories/CA-2001-10.html

The last Apache exploit mentioned on CERT happened in 1996.

And remember, IIS only accounts for 26% of all web servers on the net (and Apache accounts for 59%) -- so it's NOT just a matter of there being more IIS servers out there to hit.

By in large, Apache will run just fine OOTB. Can you say the same for IIS?

On CERT, I can find SIX exploits in IIS in this year alone.

http://www.cert.org/advisories/CA-2001-26.html

http://www.cert.org/advisories/CA-2001-19.html

http://www.cert.org/advisories/CA-2001-13.html

http://www.cert.org/advisories/CA-2001-12.html

http://www.cert.org/advisories/CA-2001-11.html

http://www.cert.org/advisories/CA-2001-10.html

The last Apache exploit mentioned on CERT happened in 1996.

And remember, IIS only accounts for 26% of all web servers on the net (and Apache accounts for 59%) -- so it's NOT just a matter of there being more IIS servers out there to hit.

By in large, Apache will run just fine OOTB. Can you say the same for IIS?

On CERT, I can find SIX exploits in IIS in this year alone.

http://www.cert.org/advisories/CA-2001-26.html

http://www.cert.org/advisories/CA-2001-19.html

http://www.cert.org/advisories/CA-2001-13.html

http://www.cert.org/advisories/CA-2001-12.html

http://www.cert.org/advisories/CA-2001-11.html

http://www.cert.org/advisories/CA-2001-10.html

The last Apache exploit mentioned on CERT happened in 1996.

And remember, IIS only accounts for 26% of all web servers on the net (and Apache accounts for 59%) -- so it's NOT just a matter of there being more IIS servers out there to hit.

By in large, Apache will run just fine OOTB. Can you say the same for IIS?

On CERT, I can find SIX exploits in IIS in this year alone.

http://www.cert.org/advisories/CA-2001-26.html

http://www.cert.org/advisories/CA-2001-19.html

http://www.cert.org/advisories/CA-2001-13.html

http://www.cert.org/advisories/CA-2001-12.html

http://www.cert.org/advisories/CA-2001-11.html

http://www.cert.org/advisories/CA-2001-10.html

The last Apache exploit mentioned on CERT happened in 1996.

And remember, IIS only accounts for 26% of all web servers on the net (and Apache accounts for 59%) -- so it's NOT just a matter of there being more IIS servers out there to hit.

By in large, Apache will run just fine OOTB. Can you say the same for IIS?

CERT® Incident Note IN-2001-01

If you look at your firewall logs, you will most certainly see port 111 attempts coming from machines that have been infected. Has been around since last January, and still propagates via unpatched rpc.statd.

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.

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.

When code red hit, I started pulling out home pages. I was hit by three different Cisco Call Mangers playing host to code red. I'm guessing cisco blew their reputation with this product. We were about ready to put in an order to. So much for that crud. Then can call back when they have it running on unix. Till then, well keep using the 3com nbx 100. Its sad because 3com's support of the nbx sucks (look for support online for details) and nbx corp worked with cisco. It would have been nice if cisco had bought out nbx instead of 3com.

Yep, that's Nimda...

You can find a writeup on it here. One of the nastier pieces of work making the rounds.

Microsoft Software is more popular and so it gets hit more. If linux was just as popular you would see the same thing happen.

You wish. The MSFT-toadying media thought that x.c , a FreeBSD and Linux worm, was going to be the "Next Code Red". My machine got more hits from sadmind/IIS worm (Solaris) than x.c. C'mon, shill-boy, why aren't you toeing the Wagg-Ed line? The truth of the matter lies more in the fact that Windows is more-or-less a software and hardware monoculture. Any flaw in IIS affects *all* of the population. The Linux/Unix/BSD/Solaris population has much greater diversity: a flaw in the WN web server isn't going to affect sites using thttpd. Similarly, there are dozens of Linux email clients in use, from mailx to Pine to mh. I don't think there's a common scripting language amongst the diversity of Linux email clients, and I don't think *any* of them are dopey enough to execute "readme.eml" files.

People that dislike windows and love linux are the reason for this attack. Its these people that are writing the viruses and worms. You've got to be kidding, right? Have you got any evidence whatsoever to back that up?

is here:

http://www.cert.org/current/current_activity.html# port80

I wasn't able to get to Security Focus to see what they had on this but I was able to get to CERT. They have this on their current activity page.

As of now there's not much more information there than is in the story already.

Other than the Code Red II backdoor it looks like it's mainly trying to exploit the unicode url hole.

I wasn't able to get to Security Focus to see what they had on this but I was able to get to CERT. They have this on their current activity page.

As of now there's not much more information there than is in the story already.

Other than the Code Red II backdoor it looks like it's mainly trying to exploit the unicode url hole.

CERT has a mention of this under Increased Port scanning activity.

The Computer Emergency Responce Center is in Pittsburgh, but somehow I doubt that it was a target.

Camp David, in Thurmont Md, is a possible location that has been said numerous times. It has a symbolic meaning to the Arab world as the location on the Camp David Accords, a 1978 peace treaty between Egypt and Israel.

I saw Ollie North on CNN, he discounted the Camp David speculation in favor of a military command and control center in Maryland, but I didn't cath the name. Anyone?

Or the plane could have continued onto Washington DC for any number of tagets there.

It's rather interesting watching slashbots make smug comments about "Microsoft worms" and "Outlook viruses" when the two most damaging worms that have occured this year could have appeared on any platform.

Code Red
The Code Red worm is a typical worm that exploits a buffer overflow just like the Morris Internet Worm and the Ramen worm before it. Either of the aformentioned worms could have done what code red did once they had 0wn3d the boxen, they just happened not to.

Heck, I've toyed with writing a proof of concept *nix verison of Code Red using wu-ftp vulnerabilities, rpc.statd vulnerabilities, telnetd vulnerabilities, sendmail vulnerabilities and even BIND vulnerabilities. Of course, I haven't gone much further than deciding what exploits to use and glancing at some source since I'm busy with school at the moment and more importantly I don't want to go to jail.

Sircam
The Sircam worm spread either through social engineering or across unprotected network shares. Neither of these requires Outlook. It didn't grab addresses out of the address book and instead grabbed them from the user's web cache. Sircam also didn't use the client mailer to mail itself out but instead included it's own mail program.
Thus all Sircam needed to spread was clueless users. This only thing Microsoft-y about this worm is that it ran on Windows.

All the above said, it is truly sad that on almost all popular platforms we are stil dealing with a 30 year old security problem whose causes and solutions have been known from probably before a sizable number of the slashdot population was born.

It's rather interesting watching slashbots make smug comments about "Microsoft worms" and "Outlook viruses" when the two most damaging worms that have occured this year could have appeared on any platform.

Code Red
The Code Red worm is a typical worm that exploits a buffer overflow just like the Morris Internet Worm and the Ramen worm before it. Either of the aformentioned worms could have done what code red did once they had 0wn3d the boxen, they just happened not to.

Heck, I've toyed with writing a proof of concept *nix verison of Code Red using wu-ftp vulnerabilities, rpc.statd vulnerabilities, telnetd vulnerabilities, sendmail vulnerabilities and even BIND vulnerabilities. Of course, I haven't gone much further than deciding what exploits to use and glancing at some source since I'm busy with school at the moment and more importantly I don't want to go to jail.

Sircam
The Sircam worm spread either through social engineering or across unprotected network shares. Neither of these requires Outlook. It didn't grab addresses out of the address book and instead grabbed them from the user's web cache. Sircam also didn't use the client mailer to mail itself out but instead included it's own mail program.
Thus all Sircam needed to spread was clueless users. This only thing Microsoft-y about this worm is that it ran on Windows.

All the above said, it is truly sad that on almost all popular platforms we are stil dealing with a 30 year old security problem whose causes and solutions have been known from probably before a sizable number of the slashdot population was born.

It's rather interesting watching slashbots make smug comments about "Microsoft worms" and "Outlook viruses" when the two most damaging worms that have occured this year could have appeared on any platform.

Code Red
The Code Red worm is a typical worm that exploits a buffer overflow just like the Morris Internet Worm and the Ramen worm before it. Either of the aformentioned worms could have done what code red did once they had 0wn3d the boxen, they just happened not to.

Heck, I've toyed with writing a proof of concept *nix verison of Code Red using wu-ftp vulnerabilities, rpc.statd vulnerabilities, telnetd vulnerabilities, sendmail vulnerabilities and even BIND vulnerabilities. Of course, I haven't gone much further than deciding what exploits to use and glancing at some source since I'm busy with school at the moment and more importantly I don't want to go to jail.

Sircam
The Sircam worm spread either through social engineering or across unprotected network shares. Neither of these requires Outlook. It didn't grab addresses out of the address book and instead grabbed them from the user's web cache. Sircam also didn't use the client mailer to mail itself out but instead included it's own mail program.
Thus all Sircam needed to spread was clueless users. This only thing Microsoft-y about this worm is that it ran on Windows.

All the above said, it is truly sad that on almost all popular platforms we are stil dealing with a 30 year old security problem whose causes and solutions have been known from probably before a sizable number of the slashdot population was born.

The exploit that Jeremiah Grossman used to hack Hotmail in 1 line of code is cross-site scripting. Here is an interesting article by John Dvorak, about how it is IN Microsoft's interest to publicise the cross-site scripting vulnerability and try to scare internet users away from "promiscuous browsing"

In order to avoid getting your personal informaiton stolen by Cross-site scripting, CERT Advises:
"Web Users Should Not Engage in Promiscuous Browsing" (see Section III: Solutions)

(insert joke about pr0n here)

That's because the site has been hacked by a worm (similar to, but predating, Code Red). the CERT advisory on this is at http://www.cert.org/advisories/CA-2001-11.html

Maybe now would be a good time to work out emergency infrastructure to deal with an emergency like that instead of waiting until it happens.

Or then again, maybe they did that quite a few years ago!

The real problem is - as always - education. I am not picking on you, but the real problem is that there are so many people thinking the above, who are totally unaware of the Computer Emergency Response Team (CERT)

Cheers!

Zero__Kelvin

Maybe now would be a good time to work out emergency infrastructure to deal with an emergency like that instead of waiting until it happens.

Or then again, maybe they did that quite a few years ago!

The real problem is - as always - education. I am not picking on you, but the real problem is that there are so many people thinking the above, who are totally unaware of the Computer Emergency Response Team (CERT)

Cheers!

Zero__Kelvin

IMO, this isn't a bad thing. It's really a "catch 22" your talking about here, isn't it? MS, over time, churns out an OS that is more secure than the rest and as a result becomes the OS of choice. Not likely.

I don't believe this would lead to a "Monoclonal OS prevalence" on the internet because people do learn from other peoples mistakes. That's what places like this, this and, this are for.

After a short vacation from work, my cubical was decorated with 23 post-it notes. How Fun!!! Each one had a different "Virus" name on it.

Well, I simply went to Cert and Norton's Virus Site to find out what was spoof, and what was true. And the next day, my Supervisor got a treat in his cube, all 23 post-it notes with the url from the respective place declaring it as a hoax. That was fun. And you know what, I have yet to see another post-it note in my cube again.

On another note, I used to work for Office Max. And yes, I did tell people when I thought what they were discribing sounded like a virus. What did I tell them? Pick up a copy of a virus scanner, buy or download off the net, I didn't care. But I told them to do me one favor. Tell me what came of it. If they told me it didn't have a virus, then I told them to send it in. If they did have a virus, I kept a log of what virii were in town. And you know what, people still didn't believe me when I told them I don't have a virus scanner. And I use Win98, Win2k.

(I know it sounds like I'm patting my self on the back, but trust me, there are good salespeople out there who are not just looking to make sales. So listen to what they say, and don't be an idiot. Some know what they are doing. Now that I'm done ranting, and raving, and this is moded down, I might be able to view the story)

I wonder if the symptoms of Code Red 3 is just similar as the one as the second version here or here? Or probably the first version?

I wonder if the symptoms of Code Red 3 is just similar as the one as the second version here or here? Or probably the first version?

The Cheese Worm seems to constitute exactly what you want. Cheese actually sought out Linux hosts infected by the Lion worm and removes any backdoor root shells from /etc/inetd.conf . Some say the Cheese Worm constitutes the first hack-of-a-hack known.

Another first for Linux and Open Source software!

This particular thing, as mentioned by many already, only affects Acrobat, not the Reader. I'd be more worried about this: http://www.kb.cert.org/vuls/id/31554, which has, of course, been patched by Adobe last November already.