[Full-disclosure] RE: Why Vulnerability Databases can't do everything

aaron_kempf_at_hotmail.com
Date: 07/15/05

  • Next message: Jerome Athias: "Re: [Full-disclosure] Secunia published adviso withoutrespectingrelease date !"
    To: "'Steven M. Christey'" <coley@mitre.org>, <full-disclosure@lists.grok.org.uk>, <bugtraq@securityfocus.com>
    Date: Fri, 15 Jul 2005 14:00:09 -0700
    
    

    So I think that there should be a government agency that coordinates this
    shit

    I mean.. Microsoft and other companies have proven time and time again that
    they're not capable of taking security, usability, performance or
    compatibility seriously. These cornholers at Microsoft aren't responsible
    enough to tie their own shoes.

    The problem with Microsoft is ATTITUDE.

    When I say 'here is a bug' they have a friggin attitude problem.
    Microsoft is too proud and too successful to be successful in the future.

    I call for federal government intervention. Microsoft has abused all of us
    for the last time.
    I have a list of a dozen bugs in Microsoft Access; and I know of one bug in
    SQL Server that those cornholers just wont fix. I mean-- SQL AUTHENTICATION
    IS IMPOSSIBLE TO SECURE. RIGHT?

    WHY IN THE _HELL_ DO WE PUT UP WITH THIS?
    IT PUTS OUR SOLDIERS AT RISK. IT PUTS OUR NUCLEAR POWER PLANTS AT RISK.

    Microsoft is too busy jerking off with Excel to do anything about it..

    Pisses me off.

    I'm sorry that you guys have sooooooooooooo many bug reports to deal with.

    Microsoft has $60bn in the bank; they should be able to afford to fix a
    couple of bugs here and there. $10m isn't jack shit when you have $60,000m
    in the bank.

    -----Original Message-----
    From: Steven M. Christey [mailto:coley@mitre.org]
    Sent: Friday, July 15, 2005 11:36 AM
    To: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com
    Subject: Why Vulnerability Databases can't do everything

    Regarding a particular vulnerability database, Xavier Beaudouin
    <kiwi@oav.net> said:

    >They push advisory without testing and respect the usual way to inform
    >developper as it should.

    (name omitted simply because it could have been about any vuln
    database.)

    No doubt a lot of what I'm about to say was covered by Brian Martin at
    CanSecWest this year, however...

    Vulnerability databases and notification services have to pore through
    approximately 100 new public vulnerability reports a week.
    Correction: that's HUNDREDS of reports, from diverse and often unproven
    sources, for about 100 unique vulnerabilities per week.

    A LARGE number of vendors and maintainers either:

      (1) are unresponsive to email inquiries (about half my emails go
          unanswered, about 20% of the ones that do answer, don't answer
          my questions)

      (2) make you register or require you to be a customer to access
          their product "support"

      (3) don't have good contact information in the first place

      (4) don't want to tell you anything about whether they've fixed a
          publicly reported vuln or not, for fear of giving out too much
          information.

      (5) sometimes require hand-holding if they don't understand the vuln
          report

    In addition, vulnerability databases and notification services have
    to:

      (1) navigate through large numbers of poorly written researcher
          advisories that are riddled with mistakes, which often were not
          coordinated with the vendor in the first place (possibly due to
          the own researcher's troubles contacting the vendors).

      (2) somehow refine and present this stuff in a usable format for the
          consumer

      (3) where possible, obtain better information either by researching
          the issue themselves or contacting the vendor

    Most advisories, whether they come from researchers, vendors, or third
    parties, suffer from one or more of the "Four I's" problems:

      - Incomplete
      - Inaccurate
      - Inconsistent
      - Incomprehensible

    And think about what would be required for testing every claim - 100
    vulnerabilities per week, many of them in commercial software, across every
    conceivable platform, OS, and execution environment. Who has the labs and
    the resources to cover all that? Nobody. Absolutely nobody.

    You're talking a 10 million dollar investment AT LEAST just for a lab that
    would cover major versions of the most popular software, and that probably
    excludes the labor for coordinating with vendors or performing verification.

    And this is happening in a context where:

      - consumers want perfect information

      - they want it the moment an issue becomes public

      - they don't want to pay a lot for it

    (which makes me think of the sign on my office door: "Vulnerabiltiy
    information: fast, cheap, or good. Pick any two.")

    In other words, it's just not possible to fully evaluate and verify every
    single public vulnerability report. So, you prioritize and do what you can
    with the available information.

    Every VDB and notification service that I'm aware of absolutely HATES having
    bad information. They will GLADLY post corrections when they are notified.
    And, hopefully, they can share this information with other VDB's. OSVDB and
    CVE have begun to do just that, and the result is an improvement in the
    quality of both databases and, consequently, better information for all
    their consumers.

    Despite all the criticism of VDB's and notification services, they do a lot
    of work behind the scenes that few people seem to fully appreciate. By no
    means are they perfect, but you can't create perfection out of chaos.

    - Steve
    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.grok.org.uk/full-disclosure-charter.html
    Hosted and sponsored by Secunia - http://secunia.com/


  • Next message: Jerome Athias: "Re: [Full-disclosure] Secunia published adviso withoutrespectingrelease date !"

    Relevant Pages

    • SecurityFocus Microsoft Newsletter #176
      ... MICROSOFT VULNERABILITY SUMMARY ... Microsoft Windows XP HCP URI Handler Arbitrary Command Execu... ... PHPNuke Category Parameter SQL Injection Vulnerability ... Microsoft Baseline Security Analyzer Vulnerability Identific... ...
      (Focus-Microsoft)
    • SecurityFocus Microsoft Newsletter #83
      ... MICROSOFT VULNERABILITY SUMMARY ... Microsoft IIS CodeBrws.ASP Source Code Disclosure Vulnerability ... Microsoft Internet Explorer History List Script Injection ... Microsoft Windows 2000 Lanman Denial of Service Vulnerability ...
      (Focus-Microsoft)
    • SecurityFocus Microsoft Newsletter #81
      ... MICROSOFT VULNERABILITY SUMMARY ... WWWIsis Remote Command Execution Vulnerability ... Windows NT 4.0 Print Spooler Security ...
      (Focus-Microsoft)
    • SecurityFocus Microsoft Newsletter #185
      ... NEW MICROSOFT VULNERABILITIES - Audit Your Network Security ... SurgeLDAP User.CGI Directory Traversal Vulnerability ... Microsoft Windows H.323 Remote Buffer Overflow Vulnerability ... Microsoft Jet Database Engine Remote Code Execution Vulnerab... ...
      (Focus-Microsoft)
    • SecurityFocus Microsoft Newsletter #336
      ... MICROSOFT VULNERABILITY SUMMARY ... Microsoft Windows Unspecified Remote Code Execution Vulnerability ... Microsoft Windows Explorer BMP Image Denial of Service Vulnerability ... An attacker could leverage this issue to have arbitrary code execute with kernel level privileges. ...
      (Focus-Microsoft)