Slashdot Mirror


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."

11 of 731 comments (clear)

  1. Right by IsleOfView · · Score: 5, Informative


    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".

  2. history by Telastyn · · Score: 5, Informative

    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...

  3. Okay, by trilucid · · Score: 4, Informative


    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...

  4. Rehash of same stupid argument on BugTraq by adturner · · Score: 4, Informative

    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.

    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?id =1&mid=203550

    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.

  5. Re:Well, it IS a two way street. by btellier · · Score: 4, Informative

    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.

  6. Re:We've seen what they propose by uhmmmm · · Score: 5, Informative
    Perhaps out of courtesy the security community could give the company with the bug a week's notice.

    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:
    1. Contact the product's vendor or maintainer and give them a one week period to respond. If they don't respond post to the list.
    2. If you do hear from the vendor give them what you consider appropriate time to fix the vulnerability. This will depend on the vulnerability and the product. It's up to you to make and estimate. If they don't respond in time post to the list.
    3. If they contact you asking for more time consider extending the deadline in good faith. If they continually fail to meet the deadline post to the list.

    When is it advisable to post to the list without contacting the vendor?
    1. When the product is no longer actively supported.
    2. When you believe the vulnerability to be actively exploited and not informing the community as soon as possible would cause more harm then good.
  7. Re:They Have a Point by blakestah · · Score: 5, Informative

    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...

  8. Re:RTFA by 0xA · · Score: 5, Informative
    For the closed-source world, I believe that it is better that if you discover an exploit, to send full details to the vendor ASAP, and to release a general statement of a potental vunerability in the software to the general public, but with just info for the end-user to determine severity and criticalness of the bug.

    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.

  9. Re:RTFA by Todd+Knarr · · Score: 5, Informative

    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.

  10. This guy thinks admins are idiots by ikekrull · · Score: 5, Informative

    '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
  11. Re:Some other choice quotes : by spectecjr · · Score: 4, Informative

    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