Slashdot Mirror

Oh no, this never happens on OS X.

We have made a bet on Windows, and we believe that customers are getting value from the bet we made,'' said Houston, ``and we're going to continue doing what we've been doing for customers.

Is that so, Mr. Houston?

I despise CDE. Not for its obtuse configuration scheme, but rather for the fact that it has so many security holes. ToolTalk especially is the bane of my existence. Take a look at what CERT has to say about CDE. Whoever coded CDE should be fired.

All ISP's should have access lists on their routers allowing traffic out only if the source address is within their network. Directed Broadcasts should be turned off to limit smurf attacks. This itself would cut the problem ten fold.

When we finally open source these trojans, our software will become more secure because programmers from around the world can work on making the trojans and the programs the effect faster, better, and more secure.

In the same vein, readers might be interested in a presentation we did at RSA 2002; the topic was Downstream Liability for Attack Relay and Amplification

(A two-page summary is available here.)

We described a scenario in which an intruder compromised a system, used it as a jumping-off point, and subsequently caused damages to an individual. The paper focuses on the legal side of things; IANAL but the other two authors - Tim Rosenberg, J.D. and Ron Plesco, J.D. - are.

I also state my opinion, which is that "...patches should be installed no later than ten (10) calendar days after release of the patch by the vendor". Discuss.

I worked at an ISP at the time that this was happening and we were quite well aware of these vulnerabilites. We often referred to CERT when looking for vulnerabilities that may have affected us. It was through sites like those that we found out about the problems with OpenSSL and we made the necessary changes. I'm not sure why it was found that many others didn't do what was necessary. Perhaps there are many admins that don't understand that they need to keep themselves up to date on these matters, and of course, they are often busy with many other tasks. It's not easy being an admin. Maybe that's why there is a System Administrator Appreciation Day.

My understanding is that the article put equal emphasis on education and entertainment. He makes such amusing remarks as "call yourself a computer professional? Congratulations. You are responsible for the imminent collapse of civilization." However, he also gives some information that was certainly not to be taken lightly. Therefore, it should be taken somewhat seriously, and quite a few people who read the article just might do that. And this could be a problem. Why? Because at the end of the article he says "Now that you know better, there is no excuse whatsoever. You cannot claim ignorance. Don't destroy humanity." And the article's title is "The Peon's Guide To Secure System Development." And that article could not have covered every ascpect of developing secure systems.

As I previously mentioned, I don't consider myself an expert in this area, but there are some things that I know that were not mentioned in the article. For example, when building secure systems, security must be kept in mind throughout the entire life cycle of the system. Perhaps his intent was to focus solely on programmers, but if he truly wants to see secure systems, he would focus all all aspects of system development. Those involved in software testing should be able to find pointer-related bugs, and many other memory-related problems that break software. In fact, in a recent issue of 2600, an program with less than 10 lines of code is given that crashes Windows. I'm not saying testers should find all bugs, I'm saying both they and developers have responsibility to be aware of potential security problems.

I also didn't like the remark about C++ being inherently insecure, and the statement supporting use of languages that don't use pointers, such as Java, C#, and Python. I would just like to say that programming languages don't break systems. People break them. Therefore, I would say that people should be made more aware of what security problems they can cause. Also, C/C++ won't go away anytime soon. So much software uses it, so it stands to reason that there will be legacy C/C++ applications for years to come. Therefore, teaching C/C++ shouldn't be a crime. Teaching C/C++ poorly should be a crime.

Well, I must say that I was somewhat disappointed in the way in which the article did not seem to go very far beyond the basics. I'll continue to recieve security information from other sources, namely Counterpane CERT and other websites like those ones.

A case which does not substantiate that the flaw had anything to do with the nature of "closed source" software

With in a few months of the code being open sourced, the back door was found. It stayed in closed source code for six years. Whether or not Borland could have done things to find it is irrelevant - they didn't and I bet many other vendors work the same way.

it was a rumour.

I guess it's easier to accuse me of spreading rumors then to enter "Borland database backdoor" into google and get stuff like a ZDNet article detailing the history of the bug or the CERT vulnerability note.

WarGames was one of the most accurate theatrical portrayals of hacking ever.

I'm not sure whethor to mod this +5 Funny or -1 Clueless. I really hope you were joking.

Why? He didn't fly through a 3d-cyberspace, nor did he jump through 5 layers of military-grade security in a couple minutes. He didn't have access to anything and everything controlled by computer.

He snagged the password to the teacher's computer off a Post-it note, and dug up information on the programmer of WOPR to take guesses at what the password might be, both of which are real hacking tools. He used hardware that existed and that he could realistically own. He wardialed, a habit of real hackers. I can't think of any other movie that comes close.

There are minor plot-neccessary exaggerations -- no, WOPR wouldn't have an outside line to it, and yes, the cops would have been at the door long before he got in -- but they don't mar the fact that it was fundamentally right.

Umm, nope, I would challenge that point. VBS and other scripting stuff is turned off by default. I've never heard of a buffer overflow exploit in OL, but if you have an example somewhere I'd love to read about it. (in other words, I'm not claiming it doesn't exist.)

Well, take for instance the vcard Buffer Overflow vulnerability that was unique to Outlook 2000.

The long GMT date field bug bug caused a buffer overflow which allowed running arbitrary code in all versions of Outlook, as well as in some versions of Outlook Express.

Seeing as Outlook uses Internet Explorer to display HTML content, just like Outlook Express does, it inherits IE's flaws as well, as was demonstrated in the Buffer Overrun in HTML Directive flaw.

As for VB scripting being turned off by default now, that may be the case with Outlook XP (2002) or 2000 with all security patches applied, but I can assure that wasn't the case back in 2001 when the Anna Kournikova Worm and other similar exploits scourged through the Outlook community.

Maybe it is as much of a scam as we think - otherwise, why did Verisign issue "two certificates to an individual fraudulently claiming to be an employee of Microsoft Corporation"? (CERT Advisory CA-2001-04)

I'm kinda pissed that slashdot completely neglected my submission of the same story (I submitted it 3 weeks ago), but I'll reprint what I said here here. Please give your comments, but I still stand by what I said.

8/30/2002 2:49:15 AM

I'm writing this to the people in charge of Resnet policy, but also to people using Resnet. An outright ban on Windows 2000 will prove to be a costly and ineffective policy for increasing the security of Resnet.

1. Software and Bugs

Windows 2000, like any operating system, is a complex bundle of computer code. Like Windows XP, GNU/Linux, or MacOS, people find bugs in the software from time to time. Certain malicious people try to exploit the bugs to damage networks, reputations, etc. Other people develop software patches to fix the bugs.

Oftentimes, bugs are found with application software, like web browsers, web servers, e-mail clients, and the like. The operating system is generally not at fault. In this case, it just so happened that problems with some Microsoft application software were found in 2001 and combined creatively to create a series of rather devastating worldwide attacks.

2. Who is to Blame

It is important to realize that Windows 2000 was not the vulnerable software in these cases. Rather, bugs in Internet Information Server and Internet Explorer were exploited; they were the cause of the widespread effectiveness of the worms called "Code Red" and "Nimda." In other words, there are computers running Windows 2000 that are not and never were susceptible to Code Red, and there are devices not running Windows 2000 that were susceptible. Similarly, there are plenty of computers not running Windows 2000 that helped spread the problem through the Nimda worm.

Thus, these problems cannot be blamed on Windows 2000. Where does the blame lie? Programmers are bound to make mistakes, especially in an environment where a for-profit company is trying to produce and sell a modern operating system. Since few pieces of software are ever bug-free, it is ultimately up to system administrators and everyday users to make sure that their systems are as secure as possible (or practical). One of the ways to help increase the security of a computer is to apply security patches once they are released.

3. Patching Problems

A properly maintained computer is like a properly maintained car. Using a two-year-old unpatched computer on the Internet is like driving a car too fast on a twisting mountain road during an ice storm on bald tires. Using such a system or driving such a car is asking for trouble.

The bug in IIS that made it vulnerable to Code Red was announced two months before Code Red. The bug in Internet Explorer used by the Nimda worm was announced a full 5 months before Nimda. Yet even today, nearly a year after these attacks, thousands of machines worldwide are still unpatched. In other words, they are either infected with Code Red, or vulnerable to it. Unfortunately, many of these machines are likely to remain unpatched forever.

With that in mind, we turn now to the proposed ban of Windows 2000.

4. What problems does it solve?

Windows XP is not vulnerable to Code Red and Nimda. So upgrading to Windows XP does protect against certain problems.

5. What problems doesn't it solve?

It does not change the fact that improperly configured or improperly managed systems are vulnerable. It does not protect against attacks that have yet to be developed. It does not help educate users about ways to make their systems more secure. It does not help users of other operating systems running vulnerable versions of Internet Explorer. It does not protect against the thousands of other vulnerabilities that plague other operating systems. It does not stop denial of service attacks and port scans (that for some reason were blamed on Windows 2000 by the Resnet web page).

6. What problems does it cause?

Bugs that were introduced during the development of Windows XP could conceivably outweigh the bugs that were patched during that time. It would be naive to think that every bug in Windows XP is also present in older Windows operating systems.

The Products Use Rights document for Windows XP now includes a clause saying that Microsoft may access and change the operating system and its components without your agreement, and in fact without your knowledge. Suggesting that users of Resnet upgrade to Windows XP puts them in a position where they agree to relinquish control of their computers. Incidentally, versions of Windows 2000 up to service pack 2 do not contain this clause.

The ban of an operating system creates a dangerous precedent. Nowhere in the Resnet Acceptible Use Policy has there been any mention of the ban of a specific software product. The AUP does state that users cannot interfere with others, or with the proper functioning of the network. However, anyone would be hard put to prove that Windows 2000 was the sole cause of any problems by virtue of any fundamental and uncorrectable security flaws.

7. What are the costs of the upgrades?

As always, these costs are generally borne by the end users. They must acquire and install the software and learn to use it. This costs time and money and doesn't appreciably increase the security of the network.

8. What are the alternatives?

Requiring that users patch Windows 2000 systems would take less time and money. Verifying that a system was patched by probing the computer for the Red Alert vulnerability is no more difficult than fingerprinting the OS and checking that it is not Windows 2000. Certainly, installing a patch is a less intensive operation than upgrading an operating system and dealing with any problems and incompatibilities that may arise, so support problems faced by the RCCs are fewer.

In conclusion, the proposed Windows 2000 ban is both costly and ineffective. It seems as if the Resnet staff has already decided on implementing this "solution," which is lamentable. As there has been no discussion of or opposition to the ban on this forum, I felt it was necessary to provide a different opinion.

9. Resources:

Resnet Policy:
http://www.resnet.ucsb.edu/information/win2k.html
http://www.resnet.ucsb.edu/information/use_policy. htm#policy

Code Red:
http://www.cert.org/advisories/CA-2001-19.html (exploit)
http://www.cert.org/advisories/CA-2001-12.html (bug)

Nimda:
http://www.cert.org/advisories/CA-2001-26.html (exploit)
http://www.cert.org/advisories/CA-2001-06.html (bug)

Windows XP PUR:
http://www.microsoft.com/licensing/resources
http://www.infoworld.com/articles/op/xml/02/02/11/ 020211opfoster.xml

I'm kinda pissed that slashdot completely neglected my submission of the same story (I submitted it 3 weeks ago), but I'll reprint what I said here here. Please give your comments, but I still stand by what I said.

8/30/2002 2:49:15 AM

I'm writing this to the people in charge of Resnet policy, but also to people using Resnet. An outright ban on Windows 2000 will prove to be a costly and ineffective policy for increasing the security of Resnet.

1. Software and Bugs

Windows 2000, like any operating system, is a complex bundle of computer code. Like Windows XP, GNU/Linux, or MacOS, people find bugs in the software from time to time. Certain malicious people try to exploit the bugs to damage networks, reputations, etc. Other people develop software patches to fix the bugs.

Oftentimes, bugs are found with application software, like web browsers, web servers, e-mail clients, and the like. The operating system is generally not at fault. In this case, it just so happened that problems with some Microsoft application software were found in 2001 and combined creatively to create a series of rather devastating worldwide attacks.

2. Who is to Blame

It is important to realize that Windows 2000 was not the vulnerable software in these cases. Rather, bugs in Internet Information Server and Internet Explorer were exploited; they were the cause of the widespread effectiveness of the worms called "Code Red" and "Nimda." In other words, there are computers running Windows 2000 that are not and never were susceptible to Code Red, and there are devices not running Windows 2000 that were susceptible. Similarly, there are plenty of computers not running Windows 2000 that helped spread the problem through the Nimda worm.

Thus, these problems cannot be blamed on Windows 2000. Where does the blame lie? Programmers are bound to make mistakes, especially in an environment where a for-profit company is trying to produce and sell a modern operating system. Since few pieces of software are ever bug-free, it is ultimately up to system administrators and everyday users to make sure that their systems are as secure as possible (or practical). One of the ways to help increase the security of a computer is to apply security patches once they are released.

3. Patching Problems

A properly maintained computer is like a properly maintained car. Using a two-year-old unpatched computer on the Internet is like driving a car too fast on a twisting mountain road during an ice storm on bald tires. Using such a system or driving such a car is asking for trouble.

The bug in IIS that made it vulnerable to Code Red was announced two months before Code Red. The bug in Internet Explorer used by the Nimda worm was announced a full 5 months before Nimda. Yet even today, nearly a year after these attacks, thousands of machines worldwide are still unpatched. In other words, they are either infected with Code Red, or vulnerable to it. Unfortunately, many of these machines are likely to remain unpatched forever.

With that in mind, we turn now to the proposed ban of Windows 2000.

4. What problems does it solve?

Windows XP is not vulnerable to Code Red and Nimda. So upgrading to Windows XP does protect against certain problems.

5. What problems doesn't it solve?

It does not change the fact that improperly configured or improperly managed systems are vulnerable. It does not protect against attacks that have yet to be developed. It does not help educate users about ways to make their systems more secure. It does not help users of other operating systems running vulnerable versions of Internet Explorer. It does not protect against the thousands of other vulnerabilities that plague other operating systems. It does not stop denial of service attacks and port scans (that for some reason were blamed on Windows 2000 by the Resnet web page).

6. What problems does it cause?

Bugs that were introduced during the development of Windows XP could conceivably outweigh the bugs that were patched during that time. It would be naive to think that every bug in Windows XP is also present in older Windows operating systems.

The Products Use Rights document for Windows XP now includes a clause saying that Microsoft may access and change the operating system and its components without your agreement, and in fact without your knowledge. Suggesting that users of Resnet upgrade to Windows XP puts them in a position where they agree to relinquish control of their computers. Incidentally, versions of Windows 2000 up to service pack 2 do not contain this clause.

The ban of an operating system creates a dangerous precedent. Nowhere in the Resnet Acceptible Use Policy has there been any mention of the ban of a specific software product. The AUP does state that users cannot interfere with others, or with the proper functioning of the network. However, anyone would be hard put to prove that Windows 2000 was the sole cause of any problems by virtue of any fundamental and uncorrectable security flaws.

7. What are the costs of the upgrades?

As always, these costs are generally borne by the end users. They must acquire and install the software and learn to use it. This costs time and money and doesn't appreciably increase the security of the network.

8. What are the alternatives?

Requiring that users patch Windows 2000 systems would take less time and money. Verifying that a system was patched by probing the computer for the Red Alert vulnerability is no more difficult than fingerprinting the OS and checking that it is not Windows 2000. Certainly, installing a patch is a less intensive operation than upgrading an operating system and dealing with any problems and incompatibilities that may arise, so support problems faced by the RCCs are fewer.

In conclusion, the proposed Windows 2000 ban is both costly and ineffective. It seems as if the Resnet staff has already decided on implementing this "solution," which is lamentable. As there has been no discussion of or opposition to the ban on this forum, I felt it was necessary to provide a different opinion.

9. Resources:

Resnet Policy:
http://www.resnet.ucsb.edu/information/win2k.html
http://www.resnet.ucsb.edu/information/use_policy. htm#policy

Code Red:
http://www.cert.org/advisories/CA-2001-19.html (exploit)
http://www.cert.org/advisories/CA-2001-12.html (bug)

Nimda:
http://www.cert.org/advisories/CA-2001-26.html (exploit)
http://www.cert.org/advisories/CA-2001-06.html (bug)

Windows XP PUR:
http://www.microsoft.com/licensing/resources
http://www.infoworld.com/articles/op/xml/02/02/11/ 020211opfoster.xml

I'm kinda pissed that slashdot completely neglected my submission of the same story (I submitted it 3 weeks ago), but I'll reprint what I said here here. Please give your comments, but I still stand by what I said.

8/30/2002 2:49:15 AM

I'm writing this to the people in charge of Resnet policy, but also to people using Resnet. An outright ban on Windows 2000 will prove to be a costly and ineffective policy for increasing the security of Resnet.

1. Software and Bugs

Windows 2000, like any operating system, is a complex bundle of computer code. Like Windows XP, GNU/Linux, or MacOS, people find bugs in the software from time to time. Certain malicious people try to exploit the bugs to damage networks, reputations, etc. Other people develop software patches to fix the bugs.

Oftentimes, bugs are found with application software, like web browsers, web servers, e-mail clients, and the like. The operating system is generally not at fault. In this case, it just so happened that problems with some Microsoft application software were found in 2001 and combined creatively to create a series of rather devastating worldwide attacks.

2. Who is to Blame

It is important to realize that Windows 2000 was not the vulnerable software in these cases. Rather, bugs in Internet Information Server and Internet Explorer were exploited; they were the cause of the widespread effectiveness of the worms called "Code Red" and "Nimda." In other words, there are computers running Windows 2000 that are not and never were susceptible to Code Red, and there are devices not running Windows 2000 that were susceptible. Similarly, there are plenty of computers not running Windows 2000 that helped spread the problem through the Nimda worm.

Thus, these problems cannot be blamed on Windows 2000. Where does the blame lie? Programmers are bound to make mistakes, especially in an environment where a for-profit company is trying to produce and sell a modern operating system. Since few pieces of software are ever bug-free, it is ultimately up to system administrators and everyday users to make sure that their systems are as secure as possible (or practical). One of the ways to help increase the security of a computer is to apply security patches once they are released.

3. Patching Problems

A properly maintained computer is like a properly maintained car. Using a two-year-old unpatched computer on the Internet is like driving a car too fast on a twisting mountain road during an ice storm on bald tires. Using such a system or driving such a car is asking for trouble.

The bug in IIS that made it vulnerable to Code Red was announced two months before Code Red. The bug in Internet Explorer used by the Nimda worm was announced a full 5 months before Nimda. Yet even today, nearly a year after these attacks, thousands of machines worldwide are still unpatched. In other words, they are either infected with Code Red, or vulnerable to it. Unfortunately, many of these machines are likely to remain unpatched forever.

With that in mind, we turn now to the proposed ban of Windows 2000.

4. What problems does it solve?

Windows XP is not vulnerable to Code Red and Nimda. So upgrading to Windows XP does protect against certain problems.

5. What problems doesn't it solve?

It does not change the fact that improperly configured or improperly managed systems are vulnerable. It does not protect against attacks that have yet to be developed. It does not help educate users about ways to make their systems more secure. It does not help users of other operating systems running vulnerable versions of Internet Explorer. It does not protect against the thousands of other vulnerabilities that plague other operating systems. It does not stop denial of service attacks and port scans (that for some reason were blamed on Windows 2000 by the Resnet web page).

6. What problems does it cause?

Bugs that were introduced during the development of Windows XP could conceivably outweigh the bugs that were patched during that time. It would be naive to think that every bug in Windows XP is also present in older Windows operating systems.

The Products Use Rights document for Windows XP now includes a clause saying that Microsoft may access and change the operating system and its components without your agreement, and in fact without your knowledge. Suggesting that users of Resnet upgrade to Windows XP puts them in a position where they agree to relinquish control of their computers. Incidentally, versions of Windows 2000 up to service pack 2 do not contain this clause.

The ban of an operating system creates a dangerous precedent. Nowhere in the Resnet Acceptible Use Policy has there been any mention of the ban of a specific software product. The AUP does state that users cannot interfere with others, or with the proper functioning of the network. However, anyone would be hard put to prove that Windows 2000 was the sole cause of any problems by virtue of any fundamental and uncorrectable security flaws.

7. What are the costs of the upgrades?

As always, these costs are generally borne by the end users. They must acquire and install the software and learn to use it. This costs time and money and doesn't appreciably increase the security of the network.

8. What are the alternatives?

Requiring that users patch Windows 2000 systems would take less time and money. Verifying that a system was patched by probing the computer for the Red Alert vulnerability is no more difficult than fingerprinting the OS and checking that it is not Windows 2000. Certainly, installing a patch is a less intensive operation than upgrading an operating system and dealing with any problems and incompatibilities that may arise, so support problems faced by the RCCs are fewer.

In conclusion, the proposed Windows 2000 ban is both costly and ineffective. It seems as if the Resnet staff has already decided on implementing this "solution," which is lamentable. As there has been no discussion of or opposition to the ban on this forum, I felt it was necessary to provide a different opinion.

9. Resources:

Resnet Policy:
http://www.resnet.ucsb.edu/information/win2k.html
http://www.resnet.ucsb.edu/information/use_policy. htm#policy

Code Red:
http://www.cert.org/advisories/CA-2001-19.html (exploit)
http://www.cert.org/advisories/CA-2001-12.html (bug)

Nimda:
http://www.cert.org/advisories/CA-2001-26.html (exploit)
http://www.cert.org/advisories/CA-2001-06.html (bug)

Windows XP PUR:
http://www.microsoft.com/licensing/resources
http://www.infoworld.com/articles/op/xml/02/02/11/ 020211opfoster.xml

I'm kinda pissed that slashdot completely neglected my submission of the same story (I submitted it 3 weeks ago), but I'll reprint what I said here here. Please give your comments, but I still stand by what I said.

8/30/2002 2:49:15 AM

I'm writing this to the people in charge of Resnet policy, but also to people using Resnet. An outright ban on Windows 2000 will prove to be a costly and ineffective policy for increasing the security of Resnet.

1. Software and Bugs

Windows 2000, like any operating system, is a complex bundle of computer code. Like Windows XP, GNU/Linux, or MacOS, people find bugs in the software from time to time. Certain malicious people try to exploit the bugs to damage networks, reputations, etc. Other people develop software patches to fix the bugs.

Oftentimes, bugs are found with application software, like web browsers, web servers, e-mail clients, and the like. The operating system is generally not at fault. In this case, it just so happened that problems with some Microsoft application software were found in 2001 and combined creatively to create a series of rather devastating worldwide attacks.

2. Who is to Blame

It is important to realize that Windows 2000 was not the vulnerable software in these cases. Rather, bugs in Internet Information Server and Internet Explorer were exploited; they were the cause of the widespread effectiveness of the worms called "Code Red" and "Nimda." In other words, there are computers running Windows 2000 that are not and never were susceptible to Code Red, and there are devices not running Windows 2000 that were susceptible. Similarly, there are plenty of computers not running Windows 2000 that helped spread the problem through the Nimda worm.

Thus, these problems cannot be blamed on Windows 2000. Where does the blame lie? Programmers are bound to make mistakes, especially in an environment where a for-profit company is trying to produce and sell a modern operating system. Since few pieces of software are ever bug-free, it is ultimately up to system administrators and everyday users to make sure that their systems are as secure as possible (or practical). One of the ways to help increase the security of a computer is to apply security patches once they are released.

3. Patching Problems

A properly maintained computer is like a properly maintained car. Using a two-year-old unpatched computer on the Internet is like driving a car too fast on a twisting mountain road during an ice storm on bald tires. Using such a system or driving such a car is asking for trouble.

The bug in IIS that made it vulnerable to Code Red was announced two months before Code Red. The bug in Internet Explorer used by the Nimda worm was announced a full 5 months before Nimda. Yet even today, nearly a year after these attacks, thousands of machines worldwide are still unpatched. In other words, they are either infected with Code Red, or vulnerable to it. Unfortunately, many of these machines are likely to remain unpatched forever.

With that in mind, we turn now to the proposed ban of Windows 2000.

4. What problems does it solve?

Windows XP is not vulnerable to Code Red and Nimda. So upgrading to Windows XP does protect against certain problems.

5. What problems doesn't it solve?

It does not change the fact that improperly configured or improperly managed systems are vulnerable. It does not protect against attacks that have yet to be developed. It does not help educate users about ways to make their systems more secure. It does not help users of other operating systems running vulnerable versions of Internet Explorer. It does not protect against the thousands of other vulnerabilities that plague other operating systems. It does not stop denial of service attacks and port scans (that for some reason were blamed on Windows 2000 by the Resnet web page).

6. What problems does it cause?

Bugs that were introduced during the development of Windows XP could conceivably outweigh the bugs that were patched during that time. It would be naive to think that every bug in Windows XP is also present in older Windows operating systems.

The Products Use Rights document for Windows XP now includes a clause saying that Microsoft may access and change the operating system and its components without your agreement, and in fact without your knowledge. Suggesting that users of Resnet upgrade to Windows XP puts them in a position where they agree to relinquish control of their computers. Incidentally, versions of Windows 2000 up to service pack 2 do not contain this clause.

The ban of an operating system creates a dangerous precedent. Nowhere in the Resnet Acceptible Use Policy has there been any mention of the ban of a specific software product. The AUP does state that users cannot interfere with others, or with the proper functioning of the network. However, anyone would be hard put to prove that Windows 2000 was the sole cause of any problems by virtue of any fundamental and uncorrectable security flaws.

7. What are the costs of the upgrades?

As always, these costs are generally borne by the end users. They must acquire and install the software and learn to use it. This costs time and money and doesn't appreciably increase the security of the network.

8. What are the alternatives?

Requiring that users patch Windows 2000 systems would take less time and money. Verifying that a system was patched by probing the computer for the Red Alert vulnerability is no more difficult than fingerprinting the OS and checking that it is not Windows 2000. Certainly, installing a patch is a less intensive operation than upgrading an operating system and dealing with any problems and incompatibilities that may arise, so support problems faced by the RCCs are fewer.

In conclusion, the proposed Windows 2000 ban is both costly and ineffective. It seems as if the Resnet staff has already decided on implementing this "solution," which is lamentable. As there has been no discussion of or opposition to the ban on this forum, I felt it was necessary to provide a different opinion.

9. Resources:

Resnet Policy:
http://www.resnet.ucsb.edu/information/win2k.html
http://www.resnet.ucsb.edu/information/use_policy. htm#policy

Code Red:
http://www.cert.org/advisories/CA-2001-19.html (exploit)
http://www.cert.org/advisories/CA-2001-12.html (bug)

Nimda:
http://www.cert.org/advisories/CA-2001-26.html (exploit)
http://www.cert.org/advisories/CA-2001-06.html (bug)

Windows XP PUR:
http://www.microsoft.com/licensing/resources
http://www.infoworld.com/articles/op/xml/02/02/11/ 020211opfoster.xml

I agree, for instance (from the a CERT advisory

Apple Computer, Inc.
The vulnerability described in this report has been addressed by

* Security Update 2002-08-23 for Mac OS X 10.2 (Jaguar), and by
* Security Update 2002-08-02 for Mac OS X 10.1.5.

According to the previous Dude's URL:
[...]presence of any of the following files on Linux systems running Apache with OpenSSL is indicative of compromise.

Variant "A" /tmp/.uubugtraq /tmp/.bugtraq.c /tmp/.bugtraq
Variant "B" /tmp/.unlock.c /tmp/.update.c
Variant "C" /tmp/.cinik /tmp/.cinik.c /tmp/.cinik.go /tmp/.cinik.goecho /tmp/.cinik.uu

But as:
Systems affected: Linux systems running Apache with mod_ssl accessing SSLv2-enabled OpenSSL 0.9.6d or earlier on Intel x86 architectures

I guess people using genuine Sun Servers should not believe this hype.

BTW, don't mod me up but mod parent down : he's a fucktard (sorry for this but this post has to be seen as flamebait by a moronator).

http://www.cert.org/advisories/CA-2002-27.html

Wrong. Go look at the CERT advisory. It says: "Compromise by the Apache/mod_ssl worm indicates that a remote attacker can execute arbitrary code as the apache user on the victim system."

There are no new lessons here. This is not the first worm for Linux. It is not the first DDoS architecture for Linux. Nor does CNET's estimation of 3,500 infected machines match its Code Red estimations that have floated from "...more than 15,000..." to "...more than 350,000...".

It would seem anybody who is finding something insightful in this story are either a Linux or Windows zealot, brand new to the argument, or very poor students of recent history. Granted - "recent" becomes is somewhat subjective. So let's take a brief look at past DDoS applications and Linux worms.

Distributed Denial of Service (DDoS) architectures began hitting the Industry consciousness late 1999. At that time it was trin00 and TFN. Shortly afterward, new versions showed up in the wild including TFN2K and Stacheldraht. All can be run on Linux. Although they are not, themselves, worms.

Linux worms are not new... nor are they ancient history. There are some excellent examples from a little over a year ago. One of the first worms from 2001 was the Ramen Worm and was reported by CNET January 17, 2001. Of course, CNET's article didn't have impressive numbers to report but it did liken it to the infamous 1998 Morris Worm. The Ramen Worm was followed by a less-famous variation called Adore and it also garnered CNET coverage April 4, 2001. But it wasn't too interesting a worm. It had been overshadowed by a worm reported the previous month dubed Lion. The Lion worm also got its own CNET coverage.

In each case, the worm in question used well-known security flaws with existing patches.

If one wants to point out that any OS is vulnerable if it is not properly maintained, then this latest worm is simply one of a series of worms that have proved this point. And worms have made object lessons of Linux, Windows, and other popular OS variants such as Solaris (sadmind/IIS being my favorite as it propagates on Solaris machines and then attacks and defaces IIS web sites).

I seem to remember code red running around for a good 2 weeks after I heard about it before anything was able to be done about it.

I seem to remember code red running around for a good 2 weeks after I heard about it before anything was able to be done about it.

• OpenSSL prior to 0.9.6e, up to and including pre-release 0.9.7-beta2
• OpenSSL pre-release 0.9.7-beta2 and prior with Kerberos enabled
• SSLeay library

• OpenSSL prior to 0.9.6e, up to and including pre-release 0.9.7-beta2
• OpenSSL pre-release 0.9.7-beta2 and prior with Kerberos enabled
• SSLeay library

The CERT Advisory has information on what to look for in your logs.

Was overseas for several months, and no less than two weeks after I'd arrived at my home away from home, bugtraq had postings related to the wu-ftpd remote root vuln. Since I was on an insecure network (they were blocking port 22), I had to have a friend back home block the port on the router since he didn't know the root password on the ftp server.

However, pureftpd works great! ;)

Seems to me that the really nasty vulns lie in wait while you get yourself into the worst situation possible for handling it. :P

Yes.

Read the CERT Advisory CA-2002-27.

It's available here

9. Notes Notes are stored on the Kolab server inside the user's IMAP sub folder "Notes" (German: "Notizen"). Physically, they are represented as multi-part MIME emails with the actual note being a MIME part. See the appendix for the exact file format.

There's a better article about SNORT and ACID on LinuxWorld. Also, if you want to investigate SNORT, check out the following links:

• CERT's HOWTO on ACID and SNORT
• SNORT's manual on installing SNORT, MySQL, ACID on RedHat
• A variety of deployment guides provided by SNORT
• A collection of various IDS documents and white papers, including a good piece by Marcus Ranum on benchmarking

Funny, I can have my SNORT installation log to Oracle, MSSQL Server, MySQL, PostGreSQL, etc. And I can perform vulnerability assessments, etc. By adding on ACID (from CERT) and logsnorter, I can integrate my firewall logs and view everything through a very nice web UI. Best of all, except for the hardware I run it on, and the work, my IDS and vulnerability assessment platform hasn't cost me a dime.

And your "superior SQL Server 2000" has more holes than swiss cheese, which is why I'm using MySQL in a secured, private network, for my logs.

but whether anybody should trust Verisign's assurance that company X is legit
Good Question

it works like this , a link gets posted on slashdot. every filthy animal here - including me , you look at pictures instead of reading the article. Suck up all the bandwidth of the server and all your bandwidth are belong to us. its a lame way of doing DOS

Another proof of it... Flaw opens door in Windows, Mac, Linux

The MIT Kerberos development team issued a warning and patch on its Web site.

Apple Computer confirmed that its Mac OS X operating system contains the vulnerability, which has been fixed through a recent security advisory, available through the software's automatic update mechanism.

Several sellers of Unix and Unix-like operating systems, including Red Hat, Debian, FreeBSD, Sun and NetBSD, said that their software was affected by the issue, and issued fixes. HP said it was investigating the bug's impact.

Microsoft said it is still investigating how Windows is affected by the problem.

The relevant patches are available from the companies' Web sites, or through the CERT advisory on its Web site.

EVERY Operating System will have exploits. It's all a matter on how it's addressed. M$ Still hasn't learned to patch & go. I use Win 98se, NT4, 2000, & XP (plus Mandrake 8 and SuSE 8) on a daily Basis. And the reboot on every other update (XP has gotten better but I love Linuxes ability to kill a service and restart a service without a reboot).

Security Update 2002-08-02

• This update addresses the following security vulnerabilities which affect current shipping versions of Mac OS X Server. These services are turned off by default in Mac OS X client, however if these services are enabled then the client becomes vulnerable. It is recommended that users of Mac OS X client also apply this update.
• OpenSSL: Fixes security vulnerabilities CAN-2002-0656, CAN-2002-0657, CAN-2002-0655, and CAN-2002-0659. Details are available via: http://www.cert.org/advisories/CA-2002-23.html
  
  
• mod_ssl: Fixes CAN-2002-0653, an off-by-one buffer overflow in mod_ssl Apache module. Details are available via: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2002-0653
  
  
• Sun RPC: Fixes CAN-2002-039, a buffer overflow in the Sun RPC XDR decoder. Details are available via: http://bvlive01.iss.net/issEn/delivery/xforce/aler tdetail.jsp?oid=20823
  
  

Yes, but how long has it been in there? Presumably the entire lifetime of the package on ftp.openbsd.org?

And it is also disturbing that this is happening with the `official' distribution site. Not some rogue mirror. The question has been asked, how can we trust packages from here on?

It is very possible that this is a one time accident and that it will never happen again. According to CA-99-01-Trojan-TCP-Wrappers, similar things have happened before.

I suppose this only enhances the reasoning behind MD5 checksums. I will most definately use them rigorously from here on. And if not, how long before we get too paranoid for the average mirror? Let alone the primary distribution sites? Seems as if checksumming files should ease such paranoia (of course assuming that the .md5 files haven't been tampered with themselves?)

Spaff is pretty well known in the Internet, but I am affraid I can't think of a major contribution to computer security from him since tripwire.

This is the man who, when head of security for MS, gave us the above quote in August 2001 when viruses such as Melissa virus were targeting MS products. If your chief security officer makes such a statement, doesn't it set you wondering about their credibility working in the field of security at all, and the attitude of the company or government that employes them?

here,
here,
and here.

Weird, I found a sadmind/IIS worm infection on Texas Community college website, I sent an email to the administrator but never got a reply back. I checked and its fixed now though.

Another rampant problem with IIS that is still VERY VERY widespread is older Servers IIS 4.0 mainly, and some 5.0, that have FrontPage extensions installed, have botched NTFS permissions on the "Front Page Web".

I don't know if anyone has noticed this, but if you have Microsoft Front Page installed on your browser, a little button shows up on your Internet Explorer toolbar, the default is usually the Word Icon, as in edit this page with Microsoft Word, but if you have Front Page installed on your computer, you can select Edit with FrontPage, and FrontPage will attempt to communicate with the Web Server for remote authoring, now if this web server is an IIS server, and has Front Page Extensions installed for remote authoring, and the NTFS permissions have not been set correctly, it will give you, the IUSR_ (Internet User) account FULL Priveleges to change the "Front Page web".

As of now, I know 3 high profile companies who have this issue with their sites WIDE OPEN. Anyone can waltz in and alter their website, using the IUSR_ account. I would like to let them but how do I know they are not going to accuse me of something I didn't do, and just happened to stumble on.

Oh well.

From the point of view of a machine connected to the Internet by cable modem, in terms of rejected TCP SYN packets, grouped by destination port, over a period of a little over 2 weeks:

1. port 1433 (MS SQL server), with 1325 packets
2. port 27374 (SubSeven, a Windows backdoor program), with 393 packets
3. port 12345 (NetBus, another Windows backdoor program), with 361 packets
4. port 80 (HTTP, of course), with 205 packets. (Since the connections aren't accepted, I have no data on which specific exploits they might be intended for.)
5. port 119 (Usenet NNTP), with a paltry 66 packets
6. port 21 (FTP), with 59 packets.

...the linux boxes haven't had a virulent worm or two, or three, going around and making all the installations with holes sputter all over the network so they get noticed.

But try Google, search for 'White Hat tutorial', or 'Network Security'.

Also, keep up to date on CERT warnings.

Same as everything else though, the best tool is the machine you want to secure.. go play.

-Gih
The number you have dialed 9..1..1.. has been changed to an unlisted number, thank you ........

and to top it off you could analyze its logs with ACID.

I'll bite.

Last night I installed RedHat 7.2 and it had just as much useless, exploitable stuff running.

Please, do tell. I'd like to know what these bugs might be. I'm sure they're much worse than bugs in IIS, IE and MWP.

Note on IE bug: Read: "...special code exploited a vulnerability in [IE] and forced the spyware onto users' computers."

Worst of all, I needed twice as long to uninstall all of their "bonus" crap...

Ever check install options? You can select what to install and what not to install. Don't whine because you didn't look.

...because rpm is a flaming piece of trash.

The dependance system is much more efficient -- windows setups typically include every dependancy a program needs, leading to a lot of redundant data and bulk. Use something like up2date or Red Carpet to handle dependancies.

Never mind some of the fun stories I could tell you about people running older RH or Mandrake releases.

Care for me to elaborate on the bugs in unpatched versions of (*laugh*) early versions of NT? NT 4? 2000? XP? Regardless, please do tell, I'd be interested to know about these stories.

CERT® Advisory CA-2001-09 Statistical Weaknesses in TCP/IP Initial Sequence Numbers

You know, the hole that allows a specially crafted, chunk-encoded HTTP request to execute arbitrary code on the server, and as Microsoft would say, "a malicious user" could exploit this to damage systems, take over a box, or worse.

ftp.openssh.org is getting hammered right now... sigh.

You might want to check out this CERT page...

Remember... all software sucks :)

Duh.
Telnet AYT options overflow:
http://www.cert.org/advisories/CA-2001-21.html
Telnet TERMCAP vulnerability:http://www.linuxsecurity.com/advisor ies/freebsd_advisory-898.html

Personally, I think, for UNIX (maybe not Windoz), it's only a DOS vulnerability, but it wouldn't hurt to upgrade once a STABLE, TESTED fix is out.