Slashdot Mirror

I don't intend this to be an "I told you so!"

Good ... because IIS had a more serious problem with chunking

This is true even on Windows where there was no way to read a jpeg file via Win32 until recently.

This is not true at all, Internet Explorer has been able to view jpeg files for as long as it's been around. Outlook Express, an extremely popular e-mail client, uses IE's activex control to display html e-mail's. All it would take is for someone to view an html e-mail with a jpeg image in it.

More information on recent buffer overflows in widely used compression imlementations (all of them can be exploited with a specially constructed file):

MP3 Files can Cause Code Execution under Winamp

Double Free Bug in zlib Compression Library

bzip2 contains multiple security vulnerabilities

Of course, this means that all your desktop icons will have .ink extensions, but so what?

Do any of you remember the double free zlib bug?

Very wicked, but you had to a) know the type of system and b) the viewer the person was using. This sort of technique, using data to act as code is clever and quite real. In fact, there is nothing different between this and those URL hacks for IIS; data appears where it wouldn't normally be expected and it can be leverage into code space and executed.

However, in the case of JPEG, considering its block oriented format it would be quite difficult to engineer a buffer overflow condition.

I'm starting to suspect that Microsoft releases these .htr holes on purpose. I mean, nobody in their right mind uses it. So I think they just cook up a vulnerability, and let the word out. Then, up in Redmond, they must all sit around and have a good laugh at the flurry of indignant outrage that inevitably appears on /.

After all, everybody knows that Apache has no vulnerabilities in the default installation.

I'm starting to suspect that Microsoft releases these .htr holes on purpose. I mean, nobody in their right mind uses it. So I think they just cook up a vulnerability, and let the word out. Then, up in Redmond, they must all sit around and have a good laugh at the flurry of indignant outrage that inevitably appears on /.

After all, everybody knows that Apache has no vulnerabilities in the default installation.

I'm starting to suspect that Microsoft releases these .htr holes on purpose. I mean, nobody in their right mind uses it. So I think they just cook up a vulnerability, and let the word out. Then, up in Redmond, they must all sit around and have a good laugh at the flurry of indignant outrage that inevitably appears on /.

After all, everybody knows that Apache has no vulnerabilities in the default installation.

I'm starting to suspect that Microsoft releases these .htr holes on purpose. I mean, nobody in their right mind uses it. So I think they just cook up a vulnerability, and let the word out. Then, up in Redmond, they must all sit around and have a good laugh at the flurry of indignant outrage that inevitably appears on /.

After all, everybody knows that Apache has no vulnerabilities in the default installation.

I'm starting to suspect that Microsoft releases these .htr holes on purpose. I mean, nobody in their right mind uses it. So I think they just cook up a vulnerability, and let the word out. Then, up in Redmond, they must all sit around and have a good laugh at the flurry of indignant outrage that inevitably appears on /.

After all, everybody knows that Apache has no vulnerabilities in the default installation.

&nbsp&nbsp&nbsp&nbspIf you want to compare Linux to Windows, I'd be willing to bet my life that Windows has more security holes. There's only a limited number of people that review Windows' code. GNU/Linux, however is made up of many different smaller components that have the love and affection of their programmers. Linux is made from love. Windows is made from corporate greed. The programmers that make Windows have deadlines and upper management telling them to stop working on one project so they can put resources into creating new features. This is all my opinion, of course, but it's a very logical conclusion.

&nbsp&nbsp&nbsp&nbspThere will probably never be a truly secure operating system as long as humans are involved in making it. We make mistakes. It only takes one overlooked mistake in a protocol or the code for a system to be compromised. A good example is the recent SNMP exploit. The protocol itself was not created with security in mind, so many vendors were vulnerable. The best chance we have at a human created, secure OS is one that focuses on security, such as OpenBSD.

&nbsp&nbsp&nbspIf our government (I'm speaking of my country, the USA) adopted OpenBSD and threw enough resources behind it, other governments would have to throw a whole lot of money and effort into finding something our efforts failed to see. The way things stand though, it wouldn't be terribly difficult to bring our systems crawling to their knees.

&nbsp&nbsp&nbspFor instance, lets say one of the employees at eEye was hired by Cuba to find exploits in NT and remain silent to everyone else, it would cost them very little to hack into our systems. The guys at eEye and other security firms find exploits such as buffer overflows all the time, and I'm sure enough money could convince one employee to commit treason. Heck, they could just use the unpatched exploits already out there and do it for free!

&nbsp&nbsp&nbspThe point is that all we can do as system and network admins is to keep up to date on known exploits. We patch our systems and networks and make it so that only a true hacker could bypass our efforts. Script kiddies would be stopped dead in their tracks and 99.9% of the time, that's all the defense we require. In this respect, the amount of patched exploits should have very little effect on the decision making process. However, keep those unpatched exploits in mind.

&nbsp&nbsp&nbspWelcome to the real world!

The same day I post this they find a buffer overflow in BIND 9...

Why further the problem.

Check out this link to begin learning about denial-of-service attacks. Here's another if your appetite for self-education has been whet.

5 or 6 years in LinuxLand is a LONG time. Check out a current Linux distro and then post back.

Well, I do use current Linux distros, I just don't pay much attention to security, because I'm no longer an admin. However, looking at recent CERT advisories, looks like not much has changed. The only difference is they report many more Windows vulnerabilities than before.

Who is going to decide what is appropriate for kids.us? Would it be appropriate for CERT (as in www.cert.org) to have cert.kids.us? It doesn't really look very kids oriented to me, but some kids might be better prepared for their future careers if they can visit. And what about sites that provide information about issues kids might have to deal with, such as suicide and sexuality? If kids.us becomes the norm for all parents to restrict their children to, then it does become defacto censorship. And what's to prevent the next step in a couple years where parents and/or ISPs are required to deploy the restriction under legal threats? Would you or I as parents even be allowed then to let our children access a site some other parent would not?

...they are supposed to go into similar actions to verify the authentity of the registrant...

"Supposed to" is right, but it's not like their track record is spotless.

Although I couldn't find a definition for the term trojan horse on CERT's website, a link was provided to the comp.virus FAQ. According to it, a trojan horse is:

A TROJAN HORSE is a program that does something undocumented that the programmer intended, but that some users would not approve of if they knew about it.

What RadWare's software is doing makes it perfectly clear that spyware should be treated as a trojan horse (with legal implications where applicable), beacause that's what it is.

External audits are good because they bring in experts who focus on finding vulnerabilities in your network. These experts will come armed with a variety of vulnerability assessment tools to perform their audit. The only problem is that it will almost always happen less frequently than vulnerabilities are discovered, so this should only be 1 part of the overall solution.

You should adopt this practice internally, because if the tools are set up to check for vulnerabilities, you can be much more proactive about finding them than simply by scheduling consultants to come every few weeks, months, year. There are a variety of tools available, both freely and commercially.

A good tool will be updated frequently, check a lot of bugs, including the most critical (SANS Top 20, BugTraq, CERT.

Free Tools
SATAN -- Security Administrator Tool for Analyzing Networks
SAINT -- Security Administrator's Integrated Network Tool -- based on SATAN, GNU
SARA -- Security Auditor's Research Assistant -- similar to SATAN/SAINT check the Freshmeat page
NESSUS -- another free tool

Commercial Tools
ISS has a variety of tools avaiable depending on your needs
NeXpose -- try the free demo, great ui, demo only lets you assess 1 IP at a time though :( Here is a review
A Networking Computing article on Vulnerability Assessment tools. Reviews many of the major vendors (so I won't list them all). Includes some of the free tools.
Here is another overview of security tools to get you started.

I wrote a paper last year on Code Red and the whole hacking culture, which won its category in my employer's "papers program". Unfortunately the paper isnt available publicly yet, though Im hoping to have it published soon.

Anyway, the conclusion was basically this:

There have been several worms in recent times, CodeRed, CodeRed v2, CodeRed II, and Nimda to name the more obvious ones. All of these exploited bugs in IIS that Microsoft knew about in June 1999 but other than a few knowledge base articles with attached patches, they did nothing about it. The same bug was even reported in beta versions of XP, so they didnt even fix their own development code.

We were lucky in that these worms were mostly an annoyance which did little more than deface a web site, and/or replicate themselves. They could have done a lot more damage, as many /.ers have pointed out.

What they achieved though is an almost global awareness of the dangers, and potential damage that worms like these can do if they wanted to, while reminding system admins that software should be patched/upgraded regularly - particularly when the bug being exploited had been known about and reported by cert 2 years prior to the worms being created! In this regard, they did us a great service. The media hype and predictions of doom got peoples attention in a way that had not been achieved before.

Microsoft, with its marketing machine, got loads of publicity. I remember seeing Bill Gates on the news, standing at a podium with the FBI at his side saying how Microsoft had reacted quickly and provided patches to defeat the evil hackers (remember that these patches had been available for 2 years - what Microsoft was providing was simply a cumulative bundle of these). The publicity was priceless, touting Microsoft as our saviour, yet I believe it was Microsofts lack of action in fixing the problem and making people aware of it that allowed the worms to be created in the first place.

Its not good enough to simply know about a problem and passively make a patch available for download. Its difficult to keep track of all customers, but I would have thought that if you have a large number of very large corporate customers, you should pro-actively send them updates and advisories, and make it widely known that there is a problem which needs attention. Whatever Microsoft did or didnt do, it wasnt enough (obviously).

I said it so much better in the paper, but basically I believe that the guys that wrote these worms did us a service, and although CNN might think it was a big fuss over nothing, I would disagree. It was certainly the bigest event of its kind in the internets history so far.

What's interesting and revealing about Gator's approach is that the well-known Nimda worm spread by injecting popup download code into IIS-served web pages, exploiting a vulnerability in Internet Explorer that caused the user NOT to be prompted before the dowloaded program executed.

Reading the article I was struck that I'd seen Bruce Schneier denigrating the 'passive defence' fortress security model in the past, and a quick search found the article - What Military History can Teach Network Security.

I'm not going to completely denigrate Roger Sessions here. At some point in a system components have to trust each other. However that point is not actually the firewall, which was Schneiers point - you need application level security. And Roger explicitly mentions firewalls as a fortress implementation technology (yes they may well be the walls but I wouldnt want them implementing the door as well).

A second problem with his model is the fact that he lets anyone at all through the door, after the guard ok's them. This is the kind of thing that led to problems in the early days of the web. Perl's taint model is better, and in Roger's world represents every messenger from the outside being followed round the fortress by a guard, or better still, sending someone out on a horse to parley instead of letting the messenger in in the first place.

To sum up, anyone implementing the security model as described in that article would actually be repeating an old set of mistakes (which curiously went by the same name, and Roger hasn't noticed). It does not describe an 'improved' level of security, rather it describes pretty much what is on the ground in most places. That may well have been his intent, though, time will tell.

-Baz

I've been holding off grabbing any of the release
candiates hoping the zlib, OpenSSH and other
recent security fixes would be incorporated.

I can't find mention of these updates for 8.2 on
the Mandrake announcement site, or forums.

Anyone know if zlib and the gang have been fixed?

My query about this on the Mdk forums was
immediately marked as "-1: Offtopic" suggesting
to me the fixes are not there. :/

It seems like if there isn't a mailing list for every single library's security issues, then closed source vendors will become second-class citizens when it comes to getting forewarning about a big security announcement like this.

I don't believe this is true. Look at this list. Many vendors were contacted in advance, vendors of proprietary and free software. However, CERT/CC probably assumed that this is a pure UNIX vulnerability, and did not contact all vendors. (In fact, they should have contacted Microsoft nevertheless, because of Interix.)

However, we can clearly see one thing (if you look at the find-zlib output): Most proprietary vendors do not update their copies of zlib at all. Previous versions of zlib had their problems, too, and yet the vendors didn't care, even though the software was still maintained. Probably they had already forgotten that the code came from an external source. Free Software projects are different here, I guess: New upstream sources are merged in a rather timely fashion.

CMU's cert organization can help with certain falvours of Unix (maybe windows) with an emphasis on data center computers (e.g. ftp or web servers) as opposed to command and control computing (like ships at sea). www.cert.org.

Also of use to Windows admins and similar folk is bugtraq at apparently a new URL. Ahoy and good luck.

I've never heard of PINE-CERT either. I smell something fishy.

There are plenty of viruses that require positive action by the victim. For example, you might take a look at the Melissa virus.

-- Brian

1) Hypocrisy. Everyone screeches as loudly as possible because the big, closed source vendors like Sun and Microsoft want you to report security problems privately. Well, okay, let's look at Apache. Now, let's look at their policy regarding reporting security issues.

"We strongly encourage folks to report such problems to our private security mailing list first, before disclosing them in a public forum."

Sounds like the same thing as Sun or MS. Why aren't we bashing Apache?

2) The recent SNMP vulnerability. Wow, many eyes have gone over the SNMP code. Check out the CERT list of vendors on this puppy. Those many eyes should have been going over RedHat, over FreeBSD (okay, in their ports), over Netscape's products (too bad they don't tell you which ones). No word on the CERT site about SuSE, Mandrake, et al.

How much you want to bet that it's one old hunk of code to do SNMP that has been ported from one platform to another over many years? Even if it isn't ... wow, don't millions of eyes look at Linux? Some might look ... few look very hard.

And I now proceed to duck and cover for the nuclear blast.

RedHat has released a security advisory at

http://www.redhat.com/support/errata/RHSA-2001-1 63 .html

with updated versions of the ucd-snmp package for all supported releases and architectures. For more information or to download the update please visit this page.

I've noticed there's a lot of secrecy in this code. How do I, as an adminstrator who uses SNMP confirm any of this? All of these descriptions are about as vague as saying "We have a secret exploit that will kill any machine using the ICMP protocol, not exactly sure but it exists!". Does anyone have any more information as to what exactly this exploit does in order to crash. This is just not enough information:

Numerous vulnerabilities have been reported in multiple vendors' SNMP implementations. These vulnerabilities may allow unauthorized privileged access, denial-of-service attacks, or cause unstable behavior. If your site uses SNMP in any capacity, the CERT/CC encourages you to read this advisory and follow the advice provided in the Solution section below.

you know, for a while I was with most of you, ready to take up the chant at the slightest hint of security through obscurity:

"Release information about security flaws immediately, you corporate hoodlums!"

But then came the sshd exploit. I run a small-time server on a DSL connection, and before the announcement I got zero exploit attempts. Since the announcement, I get 4 to 5 attempts per day.

What does this tell me? Keeping vulnerabilities secret for a while, while not the final answer, can save headaches, money & time by not having to clean up after every last idiot with a root kit. The serious crackers are always going to have the latest exploits, but keeping them out of the hands of script monkeys might just be worthwhile.

I don't mean this to sound as confrontational as it will, but before y'all get up on your soapboxes, take a look at your server logs and see what's really going on.

Please try linking...
http://www.kb.cert.org/vuls/id/107186

http://www.kb.cert.org/vuls/id/854306

Please try linking...
http://www.kb.cert.org/vuls/id/107186

http://www.kb.cert.org/vuls/id/854306

There is a gross difference between Javascript and Java; Javascript is an in-brower scripting language with a rather vague specification. Java is a different beast entirely.

Java applets are actually different from Java applications; they don't have the ability to interact directly with the contents of the hard drive, in addition to all of the other limitations running in the JVM. The most malicious things that a Java applet can do are make lots of windows (not a problem on a Unix box), or present false information to the user -- essentially, Java applets are no more harmful than HTML.

I direct you to a pertinent section of the CERT/CC Malicious Web Scripts FAQ:

Should I disable Java applets?

The risk associated with Java applets is significantly different
from some of the other technologies. Java has a robust security
mechanism designed to deal with situations like these that prevents
sensitive information from being disclosed or client information from
being damaged.

However, Java applets written by an attacker can still be loaded
while your are viewing a legitimate web page. The problems that can
arise are similar to those involving the and other HTML
tags. For example, an attacker could develop a "Trojan Horse" program
that presented misleading information and prompted you for a password.
If you failed to recognize the malicious applet for what it was, you
could accidentally disclose sensitive information.

You must make your own determination about disabling Java applets,
based on your tolerance for these risks. If you choose to disable
Java, please see the detailed instructions below.

Why isn't this happening on linux boxes? IT IS! *ANY* operating system that is hooked up 24/7 to an internet connection is a target, INCLUDING linux. The fact that it CAN be secured doesn't mean it WILL be.. the number of people who don't patch their OS when ssh, bind, wu-ftpd, ptrace expoits, etc are discovered is probably around 99%.

DDOS attacks originating from cracked linux boxes are going on already, there really are just fewer of these in use in the DSL/Cable Modem scenario compared to Microsoft machines running IIs.

If you think *you* are safe, go check out CERT for exploits on any outside-facing services you are running. The older SSH protocol has a widely publicized flaw that results in many machines being rooted. You can only keep yourself safe through constant maintenance & vigilance.

Did Linux have anything on this scale?

Yes actually, if you're running an unpatched older distribution that had either the bind, wu-ftpd, ssh, lpr, or a couple other bugs, I bet you'll find some odd net connections and irc bots on your system.. the activity level of probes looking for linux holes (just like the automated IIs worms) is increasing dramatically. Check CERT for the details

OpenBSD's just got good marketing... as you say, their security's on par with the other *BSDs and the better Linux distros.

ERT Advisory CA-2002-01 Exploitation of Vulnerability in CDE Subprocess Control Service

Original release date: January 14, 2002 Last revised: -- Source: CERT/CC

A complete revision history can be found at the end of this file.

Systems Affected

* Systems running CDE

Overview

The CERT/CC has received credible reports of scanning and exploitation of Solaris systems running the CDE Subprocess Control Service buffer overflow vulnerability identified in CA-2001-31 and discussed in VU#172583.

Read More...

Reports from places like cert and bugtraq show that there are just as many exploits out there for *nix based systems.

Network security of this nature is clearly not working when being applied at the OS or software levels, and a more flexible solution than the standard firewall is needed.

What would your opinion be of a 'mini-firewall' included as standard on all new network cards. The firewall would have packet filtering rules filtering out 'generic suspicious traffic' (such as bar an IP address for a day if something containing default.ida and a hell of a lot of 'N's comes through). The rules would be held on a flash ROM, which could be updated when necessary with software from a trusted source such as CERT and digitally signed by a non-trusted one such as Verisign.

Software could also be written to instruct the card to open certain ports and update the rules so that safe traffic for that software can pass through.

Unfortunately, the extra $20-30(?) would probably sink it dead in the water, not to mention the hassle of having to reprogram all network software to work with it. How does the idea stand in theory, though?

ERT Advisory CA-2002-01 Exploitation of Vulnerability in CDE Subprocess Control Service

Original release date: January 14, 2002 Last revised: -- Source: CERT/CC

A complete revision history can be found at the end of this file.

Systems Affected

* Systems running CDE

Overview

The CERT/CC has received credible reports of scanning and exploitation of Solaris systems running the CDE Subprocess Control Service buffer overflow vulnerability identified in CA-2001-31 and discussed in VU#172583.

Read More...

Reports from places like cert and bugtraq show that there are just as many exploits out there for *nix based systems.

Network security of this nature is clearly not working when being applied at the OS or software levels, and a more flexible solution than the standard firewall is needed.

What would your opinion be of a 'mini-firewall' included as standard on all new network cards. The firewall would have packet filtering rules filtering out 'generic suspicious traffic' (such as bar an IP address for a day if something containing default.ida and a hell of a lot of 'N's comes through). The rules would be held on a flash ROM, which could be updated when necessary with software from a trusted source such as CERT and digitally signed by a non-trusted one such as Verisign.

Software could also be written to instruct the card to open certain ports and update the rules so that safe traffic for that software can pass through.

Unfortunately, the extra $20-30(?) would probably sink it dead in the water, not to mention the hassle of having to reprogram all network software to work with it. How does the idea stand in theory, though?

ERT Advisory CA-2002-01 Exploitation of Vulnerability in CDE Subprocess Control Service

Original release date: January 14, 2002 Last revised: -- Source: CERT/CC

A complete revision history can be found at the end of this file.

Systems Affected

* Systems running CDE

Overview

The CERT/CC has received credible reports of scanning and exploitation of Solaris systems running the CDE Subprocess Control Service buffer overflow vulnerability identified in CA-2001-31 and discussed in VU#172583.

Read More...

Reports from places like cert and bugtraq show that there are just as many exploits out there for *nix based systems.

Network security of this nature is clearly not working when being applied at the OS or software levels, and a more flexible solution than the standard firewall is needed.

What would your opinion be of a 'mini-firewall' included as standard on all new network cards. The firewall would have packet filtering rules filtering out 'generic suspicious traffic' (such as bar an IP address for a day if something containing default.ida and a hell of a lot of 'N's comes through). The rules would be held on a flash ROM, which could be updated when necessary with software from a trusted source such as CERT and digitally signed by a non-trusted one such as Verisign.

Software could also be written to instruct the card to open certain ports and update the rules so that safe traffic for that software can pass through.

Unfortunately, the extra $20-30(?) would probably sink it dead in the water, not to mention the hassle of having to reprogram all network software to work with it. How does the idea stand in theory, though?

A reminder is perhaps due here that the first internet worm program to cause significant damage (the Morris worm) was released in the 1988 and infected UNIX systems through a well known vulnerability (yep, good ole gets(3)) in the fingerd daemon.

And waddaya know,UNIX application programmers are _still_ using the occasional gets(3) call in setuid root programs, more than a decade later...

The Morris worm is a nice spectre to pull out of the Unix closet and remind everyone that Unix is not infallable. Just look at all the damage done in the early internet days! Spooky.

However, this is history - ancient by Interent standards. Since then, there have been other Unix-based worms to hit the net at large. I can name three more recent examples off-hand. Sadmind spread amoung Solaris hosts to deface IIS sites. The ramen worm attacked Linux (specifically RedHat) hosts. And there were reports of ramen code being modified and sent on its way. And then there was another Linux worm called li0n.

In each case the worm hit the wild, was discovered and reported, had a brief life as appropriate counter measures were taken, then faded out. Missing was the media frenzy one would expect with something as damaging as the Morris worm. That came later on a different platform with a different worm: Code Red.

Once again - Unix is not infalliable. But various generations have been in the trenches dealing with infosec issues for years. Recent incidents have began to show off its experience, versitility, and resiliance. It is small wonder the Unix crowd tends to look at virus issues with almost a disinterest compared to their Windows counterparts who are burned either more often or more severely by such a threat.

What is it that caused this surge in Microsoft web servers? And what is it that causes these clueless dweebs to ignore the substantial risks of employing Microsoft web servers?

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase

What is it that caused this surge in Microsoft web servers? And what is it that causes these clueless dweebs to ignore the substantial risks of employing Microsoft web servers?

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase

While it is not uncommon for the extreme left or right to be thrown out of a debate, the extreme points of view will allow a better understanding of the big picture.

Being "closed minded" and throwing out thoughts and opinions before the entire message is understood is quite childish.

The higher echelon of management will take everything into account, deliberate the possible outcome and post a concise response. Throwing out the idea of being a target website defacement, worm injections or other malware infiltrations will only lead to heartache down the road.

So what if the owners of the infected server won't do anything about it and their servers are used to infiltrate another, owned by someone else? What if the second set of servers, their admins and management want to press charges? If you didn't save the logs, how will they know who did the defacement? How can you back track the information? What if it wasn't as simple as a defacement? What if it was seen as a defacement, when in reality, they used your server to hack into the Federal Reserve? Who knows.

Do it right. Go by the guidelines set forth by Cert. Save the logs, mirror the drive. Do it the right way or don't do it at all.

I think the author was dead on with the political points of view and the ideas concerning management. Everything is "political" these days, whether computer related or not, you gotta play the game to play the game.

Internet security isn't as "new" as everybody wants you to believe. CERT has had a reporting hotline for many years now, as well as guidelines on how to make a report.

To me, the amazing fact is that judging by the comments folks are making, Most slashdotters don't even know about CERT. How do we expect the guy off the street (aka IIS administrator) to know?

Internet security isn't as "new" as everybody wants you to believe. CERT has had a reporting hotline for many years now, as well as guidelines on how to make a report.

To me, the amazing fact is that judging by the comments folks are making, Most slashdotters don't even know about CERT. How do we expect the guy off the street (aka IIS administrator) to know?

To me, the real problem is that every couple of months folks come along like internet security is something new, when in fact the exploits and vulnerabilities of today are very much like the same problems from a decade ago.

To me, the real problem is that every couple of months folks come along like internet security is something new, when in fact the exploits and vulnerabilities of today are very much like the same problems from a decade ago.

To me, the real problem is that every couple of months folks come along like internet security is something new, when in fact the exploits and vulnerabilities of today are very much like the same problems from a decade ago.

To me, the real problem is that every couple of months folks come along like internet security is something new, when in fact the exploits and vulnerabilities of today are very much like the same problems from a decade ago.

To me, the real problem is that every couple of months folks come along like internet security is something new, when in fact the exploits and vulnerabilities of today are very much like the same problems from a decade ago.

hehe, good one. An operating system as big as Windows XP that is vulerable out of the box with the default setup is unacceptable to me. Many people that have already purchased this operating system will not patch this hole. We'll be seeing Code Red II pretty soon.

Is RH 7 vulnerable OOTB with the default installation, no. Some services such as wuftpd are vulnerable to a remote exploit, but the user must turn those on manually. It is then assumed that the user knows what he or she is doing and then secures the service by updating the RPMs. In the XP case, the user just has to take the computer home from Best Buy and plug the thing into the cable modem and it's vulnerable.