Microsoft Microsoft Microsoft

Your day wouldn't be complete without Microsoft news. Ralph Nader has written an open letter to Judge Kollar-Kotelly. Seems he has a few bones to pick with the settlement. MSNBC is running a WSJ article detailing how Microsoft beat down the DOJ in settlement negotiations. Even Israel knows Microsoft is a monopoly. Microsoft reveals its keep-them-in-the-dark plan for Microsoft security vulnerabilities. Amazingly, some security firms seem to be willing to go along with it. I guess they figure setting up a sort of cartel for security flaws is in their best financial interest. SANS is keeping their list of top security vulnerabilities up to date with the latest IIS exploits. And finally, MS wishes their new disclosure rules were used for yet another huge hole in Windows. Microsoft says it's "irresponsible" to expect them to get a patch out for a critical flaw within "a few days". As usual, switch off active scripting, even though that will make essentially every webpage that's designed for IE not work.

Comments

Re:They could learn from Linux...

[toupsie]

Well Linux still hasn't solved the bug that prevents it from being an Operating System you would be comfortable having your parents use. I have no problem putting Mac OS X in front of my technophobe mom.

Re:Corvair all over again?

[Erore]

Sorry, I wrote this rant and just wanted to put it somewhere. Your mention of Unsafe at any Speed made me think of it.It is a response to Culp's comments last month.

Code Red. Lion. Sadmind. Ramen. Nimda. In the past year, computer worms with these names have attacked computer networks around the world, causing billions of dollars of damage. They paralyzed computer networks, destroyed data, and in some cases left infected computers vulnerable to future attacks. The people who wrote them have been rightly condemned as criminals. But they needed help to devastate our networks. And we in the security community gave it to them.

By listing worms that attacked a variety of operating systems Culp makes it appear that the security threat is equal to all the players in the OS space. What he doesn't do is supply a severity to the listed worms that lets us see that the worst and most widespread of these attacks were against Microsoft systems. Microsoft's dominance in the OS space only increases their responsibility for security breaches, it does not justify their targetibility.

It's high time the security community stopped providing blueprints for building these weapons. And it's high time computer users insisted that the security community live up to its obligation to protect them. We can and should discuss security vulnerabilities, but we should be smart, prudent, and responsible in the way we do it.

What it is high time for is Microsoft to take security seriously. Their operating systems have always been about ease of use, not security. Just like passenger and baggage check in US airports are about hasslefree service. We have seen one consequence of the airports security measures, and that terrible act is the only reason airport security is increasing. Numerous reports in the past few years have pointed to the insecurity of passenger air travel, yet the airlines took no notice. Code Red may well be the clarion call to reconsider the importance of security in your operating system. If your current vendor isn't supplying it, perhaps you should look elsewhere.

Arming the Enemy

First, let's state the obvious. All of these worms made use of security flaws in the systems they attacked, and if there hadn't been security vulnerabilities in Windows®, Linux, and Solaris®, none of them could have been written. This is a true statement, but it doesn't bring us any closer to a solution. While the industry can and should deliver more secure products, it's unrealistic to expect that we will ever achieve perfection. All non-trivial software contains bugs, and modern software systems are anything but trivial. Indeed, they are among the most complex things humanity has ever developed. Security vulnerabilities are here to stay.

According to Ralph Nader automobiles in the 60's were unsafe at any speed. He blew the whistle, and the groundswell response led to drastic changes in the manufacturing of automobiles and the responsibility of those manufacturers for the safety of the cars after the sale had occurred. Fastforward 30 years and juxtapose Microsoft for General Motors and you can hear the whistle blowing. Despite Microsofts attempts to hide behind groups such as the DMCA consumers and lawmakers will not continue to put up with the security risks using Microsoft products make them vulnerable to.

If we can't eliminate all security vulnerabilities, then it becomes all the more critical that we handle them carefully and responsibly when they're found. Yet much of the security community handles them in a way that fairly guarantees their use, by following a practice that's best described as information anarchy. This is the practice of deliberately publishing explicit, step-by-step instructions for exploiting security vulnerabilities, without regard for how the information may be used.

Do not fear he who hath power to kill your webserver, fear he who hath the power to crack your server, steal your financial data and destroy your very business. Prior to a security fix or announcement of a vulnerability you aren't even aware that your system is at risk. The sooner information is released to the consumer, the sooner they can make a business decision as to which is the greater cost: the possibility of having their system cracked and data stolen, bearing the cost in dollars and man hours to move to a more secure system, or the business impact of shutting an insecure service down until the security bug is fixed.

The relationship between information anarchy and the recent spate of worms is undeniable. Every one of these worms exploited vulnerabilities for which step-by-step exploit instructions had been widely published. But the evidence is more far conclusive than that. Not only do the worms exploit the same vulnerabilities, they do so using the same techniques as were published - in some cases even going so far as to use the same file names and identical exploit code. This is not a coincidence. Clearly, the publication of exploit details about the vulnerabilities contributed to their use as weapons.

Again, who is it that we fear? The script kiddies who are all bark, but no bite, or the blackhats who have established user accounts on your servers and has your corporate network as their playground?

Good Intentions Gone Awry

Supporters of information anarchy claim that publishing full details on exploiting vulnerabilities actually helps security, by giving system administrators information on how to protect their systems, demonstrating the need for them to take action, and bringing pressure on software vendors to address the vulnerabilities. These may be their intentions, but in practice information anarchy is antithetical to all three goals.

These methods are only antithetical when you have a dominant market position that is dependent upon people perceiving your products as being easy to use, secure, and hassle free to maintain.

Providing a recipe for exploiting a vulnerability doesn't aid administrators in protecting their networks. In the vast majority of cases, the only way to protect against a security vulnerability is to apply a fix that changes the system behavior and eliminates the vulnerability; in other cases, systems can be protected through administrative procedures. But regardless of whether the remediation takes the form of a patch or a workaround, an administrator doesn't need to know how a vulnerability works in order to understand how to protect against it, any more than a person needs to know how to cause a headache in order to take an aspirin.

Wrong. Providing the exact details of an exploit allows competent administrators or programmers to go to the source of a program or operating system and provide their own fix if none is available from the community at large or the creator of that program. Furthermore, a community made aware of an exploit is able to marshall its resources to provide a fix as soon as possible. Culp's position is only true in a closed source environment where the system administrator is nothing more than a mouse monkey whose idea of system administration and security are the point and click wizards provided by the vendor; or where the risk to customers of using vulnerable systems is weighed against marketing and PR concerns or the availability of programming resources and the cost of providing them.

Likewise, if information anarchy is intended to spur users into defending their systems, the worms themselves conclusively show that it fails to do this. Long before the worms were built, vendors had delivered security patches that eliminated the vulnerabilities. In some cases, the fixes were available in multiple forms - singleton patches, cumulative patches, service packs, and so forth - as much as a year in advance. Yet when these worms tore through the user community, it was clear that few people had applied these fixes.

Many people have faulted the patching process itself for the low uptake rate. Fair enough - we do need to make it easier for users to keep their systems secure, and Microsoft acknowledged this very point in a recent major security announcement. But if the current methods for protecting systems are ineffective, it makes it doubly important that we handle potentially destructive information with care.

One of my cars had a factory recall, some sort of problem with the CV boots. The auto manufacturer contacted me, on more than one occasion, to let me know that my car had a potential problem, where I could go to get it fixed, and they said they would bear the cost to fix my car. I'm not certain which one of the myriad of forms I signed when I purchased the car that signed me up for this protection plan, but it sure did work. In my 7 years of administrating Microsoft networks, the hundreds of products I have registered with them and the thousands of times I have visited their website, never once has Microsoft contacted me to let me know about a security vulnerability in the product they sold me. Making the fix available is not the same as notifying people that there is a problem and a fix.

Furthermore, like the boy who cried wolf, Microsoft products have so many vulnerabilities and the methods for keeping your systems patched are so time consuming that it can become a full time job just to keep on top of it. After awhile you just cry, "Enough!," I've got other things to do than babysit the Microsoft website to find out what the latest vulnerability is. I've subscribed to Microsoft Security alerts, and typically I have found them to be late in notifying me of problems and so filled with PR that it was hard for me to asses to true risk to my systems.

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.

A very good point Culp, vendors must find other ways to protect their customers. What Microsoft has been doing is not sufficient. The whistle has been blown, the users hear it, and they know that Microsoft has not had their best interest in mind. If Microsoft had, they would have found ways to contact users of vulnerabilities and given users incentives to patch their systems.

Responsible Handling is Key

This is not a call to stop discussing vulnerabilities. Instead, it is a call for security professionals to draw a line beyond which we recognize that we are simply putting other people at risk. By analogy, this isn't a call for people for give up freedom of speech; only that they stop yelling "fire" in a crowded movie house.

"Fire" is not being called in a crowded movie house, a fire alarm is being pulled and people are making an orderly egress. The egress is to Apache, Linux, Solaris, and FreeBSD. I'm grateful for that fire alarm, without it I would have found myself surrounded in flames created by blackhats while a Microsoft infomercial drones on the screen telling me, "There is no fire." I've got news for you Mr. Gates, this isn't the Matrix, and we are not all plugged into your grand scheme. Some of us see where you are taking us not just today, but tomorrow, and we're going to stop you.

Most of the security community already follows common-sense rules that ensure that security vulnerabilities are handled appropriately. When they find a security vulnerability, they inform the vendor and work with it while the patch is being developed. When the patch is complete, they publish information discussing what products are affected by the vulnerability, what the effect of the vulnerability is - that is, the type and extent of damage that an attacker could cause through it - and what users can do to protect their systems. This type of information protects users by giving them the information they need to decide whether to apply the fix, but it doesn't put them at risk.

Baaahhhh! Sheep, that is what Microsoft wants for customers. Users who blindly follow them to the slaughter house. But, shepard Microsoft can't even protect us that long. The wolves circle and pick off the sheep one by one. Meanwhile, the lead sheep watch what is going on in the slaughterhouse and they are told by the shepard not to tell the other sheep. Such information would cause a panic in the fold and desertions so great that Microsfts stock price would fall into a irretreivable spiral.

Some security professionals go the extra mile and develop tools that assist users in diagnosing their systems and determining whether they are affected by a particular vulnerability. This too can be done responsibly. In many cases, it's possible to build a tool that performs non-destructive testing and can only be used by a legitimate system administrator. In other cases, the specifics of the vulnerability make it impossible to limit how the tool could be used - but in cases like these, a decent regard for the well-being of the user community suggests that it would better to not build the tool than to release it and see it misused.

I repeat, those who use open source can always go the extra mile, and at the least, patch their own systems.

What You Can Do

Ending information anarchy will not end the threat of worms. Ethics and intelligence aren't a package deal, and some of the malicious people who write worms are quite smart. Even in the best of conditions, it will still be possible to write worms. But the state of affairs today allows even relative novices to build highly destructive malware. It's simply indefensible for the security community to continue arming cybercriminals. We can at least raise the bar.

What is indefensible is Microsoft's lax security throughout an entire series of Windows operating systems, office suites, and back office products. I once heard a joke that Microsoft was in a uproar because they found a virus that Outlook was not susceptable to; the company vowed to quickly rememdy that situation. The best jokes are baised upon some truth, and this joke was very, very funny. Security warnings do not arm cybercriminals, security holes do. Once again, do you really think the most malicious of crackers out there don't know and take advantage of security holes before they are announced? Of course those crackers know, and the sooner the user knows the sooner they can do something about it.

This issue is larger than just the security community. All computer users have a stake in this issue, and all of us can help ensure that vulnerabilities are handled responsibly. Companies can adopt corporate policies regarding how their IT departments will handle any security vulnerabilities they find. Customers who are considering hiring security consultants can ask them what their policies are regarding information anarchy, and make an informed buying decision based on the answer. And security professionals only need to exercise some self-restraint.

My company can adopt a corporate policy that only open source software will be used for all mission critical systems because only open source has a proven track record of quick security fixes. Instead of worrying about a security consultants policy on security disclosures, a customer would be better served by keeping security in mind when evaluating software solutions. First avoid the obvious danger.

For its part, Microsoft will be working with other industry leaders over the course of the coming months, to build an industry-wide consensus on this issue. We'll provide additional information as this effort moves forward, and will ask for our customers' support in encouraging its adoption. It's time for the security community to get on the right side of this issue.

The security community has always been on the right side of the issue, it is Microsoft who has not. Even now they are trying to sway others to their position instead of adopting that held by the long standing security community.