RE: [Full-disclosure] windows linux final study

From: security curmudgeon (jericho_at_attrition.org)
Date: 03/29/05

  • Next message: ChrisDay_at_HBOSplc.com: "RE: [Full-disclosure] windows linux final study" 
    Date: Tue, 29 Mar 2005 09:18:20 -0500 (EST)
To: ChrisDay@HBOSplc.com

    : Here we go again, so called intelligent people talking utter rot!

    [..]

    : Come on people grow up, put your prejudices aside and look at the
    : information provided, draw conclusions based on that, and be prepared to
    : change that opinion when the information to hand dictates.

    Did you read the report yourself? You sound like a Microsoft cheerleader.

    >From the report:

      Additionally, when examining the days of risk time between when a
      vulnerability is publicly disclosed to when a patch is released by the
      vendor for that vulnerability we found an average of 31.3 days of risk
      per vulnerability for the Windows solution, 69.6 days of risk per
      vulnerability for the minimal Linux solution and 71.4 days of risk for
      the default Linux solution.

    This is from page 2 of the study. Can we agree that if you find a serious
    flaw/error in the paper by page 2 (out of 37) that one might have reason
    to be skeptical?

    Does anyone in the security industry *really* think Windows ever has a
    31.3 day of risk for vulnerabilities? If you are naive enough to believe
    this, dare to visit eEye's page on their advisories where they not only
    disclose wonderful vulnerabilities in the Windows platform, but also track
    how long it took Microsoft to patch them.

    >From a soon to be published article:

      Claims of Microsoft only having a 31 day risk window seem very suspect,
      especially given their current 30 day patch cycle compared to some
      vulnerabilities that were disclosed as many as 208 days [1] before the
      patch. Before you dismiss this as a freak occurance, eEye Digital
      Security has recorded other time frames such as 71 days [2], 188 days
      [3], and 190 days [4]. These figures are right in line with several
      other security companies that have disclosed issues to Microsoft.</p>

    If you think eEye is not the norm for dealing with Microsoft, think back
    to Thor Larholm's excellent (but discontinued) page of unpatched Microsoft
    IE vulnerabilities. Looking at an archived copy of that [5], we see the
    following:

      11 September 2003: There are currently 31 unpatched vulnerabilities.

      [..]

      IE https certificate attack
      Description: Undetected SSL man-in-the-middle attacks, decrypting
      SSL-encrypted traffic in realtime
      Published: June 6 2000 ( ACROS )

    So there we have MSIE vulnerabilites left unpatched for *3 years* and may
    still be unpatched for all we know. If you read several sources of
    vulnerability information, you will consistantly see Microsoft is not that
    quick on patching vulnerabilities.. certainly not 31.3 days quick. If
    these examples aren't enough to make you question the report, ask others
    who have found major vulnerabilities in Windows. I'd love for Marc
    Maiffret or Chris Wysopal or the countless others who have discovered
    Windows vulnerabilities to reply to this with their first hand experience
    in getting a fast turnaround on patches.

    Look beyond that and think out loud about the second part of the original
    paragraph quoted:

      per vulnerability for the Windows solution, 69.6 days of risk per
      vulnerability for the minimal Linux solution and 71.4 days of risk for
      the default Linux solution.

    So now there is a difference in patch cycle between "minimal linux" and
    "default linux"? Can anyone cite a source for any linux vendor that makes
    this distinction between install types AND releases patches on a different
    cycle for them? How far do you have to take word mincing to make this
    statement true?

    jericho

    [1] http://www.eeye.com/html/research/advisories/AD20041012.html
    [2] http://www.eeye.com/html/research/advisories/AD20041012A.html
    [3] http://www.eeye.com/html/research/advisories/AD20040413C.html
    [4] http://www.eeye.com/html/research/advisories/AD20050208.html
    [5] http://attrition.org/security/rant/z/thor_larholm-unpatched_ie.html
    _______________________________________________
    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: ChrisDay_at_HBOSplc.com: "RE: [Full-disclosure] windows linux final study"

    Relevant Pages

    • Re: Vulnerability Assessment
      ... IMHO, therefore, I prefer to list ALL the vulnerabilities but prioritize fixes based on my perception of the risk of that vulnerability being exploited in that environment. ... In terms of analysis, where you need to trust employees or not, I think you ...
      (Pen-Test)
    • RE: Re: Microsot Liability for vulnerabilities
      ... At the risk of taking this off on a tangent and/or getting kicked out of the ... Subject: Microsot Liability for vulnerabilities ... NOT EVEN KNOWN to the public for various reasons (i.e. Microsoft won't ... think that blaming it on the hackers is going to stop all software bugs? ...
      (Security-Basics)
    • RE: assessing IIS 5.0
      ... I thought you were doing a risk evaluation, ... vulnerabilities need to be accounted for ... internal IP address is a "systems configuration information disclosure, ... Without understanding the security policy of the system being evaluated ...
      (Pen-Test)
    • Windows Buffer Overflows
      ... "While many may believe that the risk for these types of vulnerabilities is ... The recent .asp exploits that I have seen all work in a similar way. ... which is a static memory address ...
      (Vuln-Dev)
    • Windows Buffer Overflows
      ... "While many may believe that the risk for these types of vulnerabilities is ... The recent .asp exploits that I have seen all work in a similar way. ... which is a static memory address ...
      (Bugtraq)