Microsoft Blames the Messengers
Roger writes: "In an essay published on microsoft.com, Scott Culp, Manager of the Microsoft Security Response Center, calls on security experts to "end information anarchy" and stop releasing sample code that exploits security holes in Windows and other operating systems. "It's high time the security community stopped providing the blueprints for building these weapons," Culp writes in the essay. "And it's high time that computer users insisted that the security community live up to its obligation to protect them." See the story on Cnet News.com."
Much better that the "black-hats" "secretly" circulate the information.
</sarcasm>
If the security experts didn't find and pubilsh the holes, good luck on Microsoft making the fixes a "priority".
Yes, just like keeping Cryptography code secret improves the algorithm. I agree that the company should be notified before the flaw is announced, but seriously, the entire point of a security response center is to inform users as to vulnerabilities...
here we go:
"It's high time the security community stopped providing the blueprints for building these weapons..."
How about providing the blueprints to your code, so we can secure the systems you release broken to begin with?
I'm not anti-Microsoft (although I'm getting there, definitely getting there...), I do Windows development also in Visual Studio. I'm near the point of stopping that altogether though. My company is already using Linux for damn near everything (including desktops, not just hosting) anyhow.
This is more than just your average case of idiocy from MS. If I ran a pharmaceutical company, and a drug we produced killed 500 people, do you think the public would accept some excuse like this? "No, really, it's all the fault of the doctors who showed their patients how to take the pills..."
Maybe not a perfect analogy, but equally stupid. When will they learn? Probably when Joe Customer starts realizing how indecent their blame machine really is. Apache isn't perfect, Linux isn't perfect... but we admit this and work toward solutions. Average Joe won't stay completely blind forever; most people aren't stupid (my faith in humanity talking here), and you can't fool anyone indefinitely.
Damn, and I was cutting down on my smoking...
This argument that Microsoft is making is the same stupid argument that was made by Richard M. Smith on Friday Aug 10, 2001 shortly after Code Red.
d =1&mid=203550
The short story is that eEye's announcement had absolutely nothing to do with Code Red. The person(s) who developed Code Red figured out the exploit on their own. For more details check out Marc Maiffret's (of eEye) email to the Bugtraq list: http://www.securityfocus.com/cgi-bin/archive.pl?i
People who argue that full disclosure is harmful just fail to realize the facts of the matter- people who write these attacks all aren't script kiddies and they're quite capable of developing attacks on their own. And the reality is that most vendors only respond to full disclosure to actually fix bugs (and even then it takes too long).
Nuff said.
Back when I did audits in my spare time I followed a specific set of guidelines.
1. always notify the vendor first.
2. always wait 2 weeks for a patch.
3. don't release on weekends or very late at night (sorry, other side of the globe.. i'm in the US)
4. always supply an exploit, if one is possible.
And even with all this in place sysadmins still wouldn't patch the problem until they got hacked. If someone doesn't patch their system after all of these steps nothing can make them.
Scott Culp seems to think that the number of hacks will go down solely by eliminating #4, while in actuality the other 3 steps are the ones which get more boxes hacked. With you average buffer overflow thousands of hackers could write an exploit within maybe two or three hours of seeing a bugtraq post. Not notifying the vendor can cause havoc for weeks before a patch is issued.
From the bugtraq FAQ (securityfocus.com):
0.1.8 What is the proper protocol to report a security vulnerability?
A sensible protocol to follow while reporting a security vulnerability is as follows:
When is it advisable to post to the list without contacting the vendor?
What gains are there to be had by having the source displayed all over the web?
1) The source display should allow any administrator to verify if he is vulnerable, and, after patching, that he is no longer vulnerable.
2) The source code should demonstrate the exact nature of the problem for the coders who wish to fix it. They would otherwise need to write their own exploit to test their fixes.
3) The source code should apply pressure to the software maker. It is akin to being flogged in public. The whole world knows you are vulnerable, and you ought to fix it.
4) The source code of the exploit should make the exploit obvious but not damage the system.
Source code exploits will ALWAYS be published in places where some crackers can get them. The challenge is designing an updating system that allows all users to apply patches in a timely fashion. I think Debian is actually closest on this one.
Microsoft is really going to get nowhere on this one. I've read accounts of people who send exploits to Microsoft in secrecy, and then HAVE to publish the code so that Microsoft is forced to fix the problem. If it doesn't impact Microsoft's marketing, Microsoft doesn't care.
The other issue that relates to this one is secure as possible by default. This principle applies to all Internet usage of computers. Yet Microsoft blatantly violated it in the following: Office Macros, email attachments, NT/Windows 2000 Server config (running IIS by default), Hotmail...
Speaking as an IIS admin, I get really pissed when I can't find sample code for an exploit. I need to be able to test my systems against a newly published exploit. If I don't have a way to do this all I can do is apply the hotfix and hope it works. What if I want to set up some stateful inspection on my firewall just in case, how do I test that? Without sample code I have no way to really know if I am vulnerable or not. IMHO not testing these things would be a pretty irresposible aproach to managing a datacenter.
Except that that was tried. What happened was that the vendors responded with "We can't reproduce that, you must be mistaken, there's no hole in our product.". After a while, the security community came to the conclusion that the only way to get vendors to wake up and actually fix their products was to release enough details that, if there was any question whether the hole existed, the skeptic could recreate the exploit and try it and see for himself. Which leaves the vendor with no way to spin the story, which is what Microsoft's really pissed off about.
'An adminstrator doesn't need to understand the problem in order to fix it'
This is pure bullshit. It is *extremely* important to understand how these worms and viruses work in order to respond effectively to such threats.
If I, as a programmer, was writing a web application in C that could potentially be remotely exploited via buffer overflow, such information is *absolutely fucking critical* to me, so that i can write safe code.
M$ seem to suffer from the delusion that they are the only people in the world actually writing computer programs.
This unbelievable arrogance is getting pretty tired, and i imagine that we'll be seeing some pretty big anti-M$ stances being taken by previously devout believers in the near future.
If you can't put up, M$, then for christs sake shut up.
I gots ta ding a ding dang my dang a long ling long
i meen the whole buffer overflow thing codered exploited, that is something that you can't just have happen accedently..that had to be codded into it.
No, actually, it's a direct side effect of the C standard libraries. Things like strcpy, strcat, sprintf... all of these are buffer overflows waiting to happen.
For example, there's a buffer overflow (probably unintentional... unless you're a conspiracy theorist like yourself) just waiting for someone to exploit it in the Mozilla image handling code. Just imagine; a linux virus that spreads by someone sending a carefully crafted image file to your system. Everything would look fine on the surface; but that image file contains compressed code that expands in such a way that it causes a buffer overflow.
... or are you saying that the Mozilla coders intended it to be a security hole?
Simon
Coming soon - pyrogyra