[ISN] Microsoft once again takes the low road...

From: InfoSec News (isnat_private)
Date: Wed Oct 17 2001 - 01:10:50 PDT

  • Next message: InfoSec News: "[ISN] RIAA Information Operations?"

    Forwarded from: "Jay D. Dyson" <jdysonat_private>
    My comments follow:
    > Microsoft Rallies Industry Against Bug Anarchy
    > By Brian McWilliams, Newsbytes
    > 16 Oct 2001, 1:37 PM CST
    > Pushed to the brink by recent Internet worm outbreaks, Microsoft hopes
    > to rally the computer industry against those who improperly publish
    > information about security vulnerabilities. 
    > In an editorial at Microsoft's site, Scott Culp, head of the company's
    > Security Response Center, announced the initiative against what he
    > called "information anarchy." 
    	If anyone wants to talk anarchy, let's talk about the business
    that totally ignores STANDARDS and bends protocols to fit their will.
    Let's talk about a business that continues to reinvent the wheel; only
    their wheel is square.
    > According to Culp, the damage caused by worms such as Code Red and Nimda
    > can be blamed in part on computer security professionals who discovered
    > the software flaws exploited by the malicious, self-propagating
    > programs. 
    	Nonsense.  The blame for Nimda rests largely on those admins who
    didn't patch their systems when there was loads of information on what
    they could do to mitigate the risk.  Sure, there's something to be said
    against the notion of blaming the victim, but let's face it: who among us
    defends the fool who habitually flashes huge wads of money and ends up
    getting mugged?
    > "The people who wrote (the worms) have been rightly condemned as
    > criminals.  But they needed help to devastate our networks ... It's high
    > time the security community stopped providing blueprints for building
    > these weapons,"  he said.
    	And people seriously expect Microsoft to "lead the way" on
    security measures?  Give me a break.  They've gone out of their way to
    downplay genuine security risks for years.  Those who remember the old
    l0pht web site will recall Microsoft's poo-poohing a l0pht advisory as
    "highly theoretical" (to which the l0pht crew had their saying, "Making
    the theoretical practical").
    > According to Culp, recent worms have relied on techniques and even
    > specific software instructions published by security firms in their
    > advisories about software bugs.
    > "Clearly, the publication of exploit details about the vulnerabilities
    > contributed to their use as weapons ... It's simply indefensible for the
    > security community to continue arming cybercriminals," he said.
    > Microsoft's editorial is the latest salvo in the debate between security
    > experts and software vendors over what is called "full disclosure." 
    	Not to mention their open hostility to Open Source.  
    > In Microsoft's view, the only prudent policy is to work with vendors and
    > not disclose vulnerability information to the public until a patch is
    > available - and then only to disclose enough information so that
    > administrators can decide whether to apply the fix without being at risk
    > if they don't. 
    	Thus leaving the regular admin with no way to test the security of
    their networks.  Lovely.  And I'll bet if such a "standard" were adopted,
    Microsoft would soon start *SELLING* "security services."  I can see it
    now...  Why get something for free when Microsoft can line their pockets
    with your money?  Sign up right here!
    > "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," said Culp.
    	How about a call for software manufacturers to stop releasing
    faulty products that put people at risk?  Oh wait, that'd be unreasonable,
    > To exert economic pressure on security consultants to adopt this
    > approach, Microsoft recommends that customers ask consultants for their
    > policy on disclosing information about security bugs they discover. 
    	How about we recommend to our customers that they ask Microsoft
    about its long and crappy record on security instead?
    > "The biggest problem system administrators have is not that people are
    > giving out detailed blueprints on how to attack vulnerabilities; it is
    > that many of the vulnerabilities that come out in IIS and other software
    > are so huge that minimally skilled hackers can exploit them on their
    > own," said Pescatore.
    > Richard Forno, chief technology officer for Shadowlogic, an information
    > assurance firm, said software vendors have a vested interest in keeping
    > vulnerability information private. 
    > "Without such widespread public knowledge and awareness of these
    > problems, vendors can take their time addressing these concerns, if they
    > even address them at all. Microsoft is by far the most notorious in
    > their vulnerability announcements, legalese and cover-their-tail
    > security alerts," said Forno. 
    > Microsoft's editorial is aimed squarely at Eeye Digital Security, the
    > security software firm that discovered the bug in Microsoft's IIS
    > Webserver that was exploited by Code Red a month later.
    	Talk about an about-face.  What happened to the Microsoft that
    publicly *thanked* eEye for their help in the original advisory?
    > "We believe that they provided information in their advisory that was
    > specific enough to help the people who wrote Code Red," said Culp. 
    	And how does Herr Culp explain the vast difference in the attack
    methodology of Code Red and the attack methodology as detailed by eEye?
    > Representatives of Eeye, which never released an exploit for the IDA
    > vulnerability, were not immediately available for comment. 
    	Hopefully consulting their lawyers for a pretty damned serious
    slander suit.
    > Discussions by security professionals of eEye's advisory on security
    > mailing lists such as Bugtraq contained additional information on how to
    > exploit the so-called "IDA" buffer overflow bug, according to Culp, who
    > said editors of such lists should consider blocking messages that
    > contain exploit code. 
    	Censorship is such an ugly thing.  I should be surprised that
    Microsoft is calling for such, but I'm really not.
    > Besides acknowledgments in its security bulletins, Microsoft plans to
    > develop additional means of encouraging security professionals to adopt
    > its limited-disclosure stance. 
    	Count me out.  Full disclosure uber alles.  Anything less is
    reliance on security-through-obscurity.
    > "It's time for the security community to get on the right side of this
    > issue," he said. 
    	Microsoft isn't exactly leading the way.  I encourage them to get
    on the "right side" of the issue and throw support to open source and full
    disclosure.  It's pretty obvious that their closed source and minimal
    disclosure stance hasn't afforded anyone any meaningful security at all.
    > The editorial on responsible disclosure is at
    > http://www.microsoft.com/technet/columns/security/noarch.asp . 
    > Microsoft's policy for acknowledging security professionals in its
    > bulletins is at
    > http://www.microsoft.com/technet/security/bulletin/policy.asp . 
    > Reported by Newsbytes.com, http://www.newsbytes.com . 
    - -Jay
      (    (                                                         _______
      ))   ))   .-"There's always time for a good cup of coffee."-.   >====<--.
    C|~~|C|~~| (>------ Jay D. Dyson - jdysonat_private ------<) |    = |-'
     `--' `--'  `- Peace without justice is life without living. -'  `------'
    Version: 2.6.2
    Comment: See http://www.treachery.net/~jdyson/ for current keys.
    -----END PGP SIGNATURE-----
    ISN is currently hosted by Attrition.org
    To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY
    of the mail.

    This archive was generated by hypermail 2b30 : Wed Oct 17 2001 - 03:04:02 PDT