lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue Mar 29 15:46:19 2005
From: mlachniet at sequoianet.com (Lachniet, Mark)
Subject: windows linux final study

Curmudgeon,

Yes, but did you actually verify their research using their methodology
to see if they screwed up?

As in any study, the methodology and assumptions control the result.
You can either poke holes in their methodology (for example by pointing
out that the use of only published results is not a true indication of
their security, in which case the eEye list of purported flaws is
relevant) or you can use their exact methodology to recreate the work
and prove that their data collection was wrong.

My guess is that if they published it, regardless of who funds it, they
probably are pretty sure that you will get the same results using their
methdology.

That's not to say that the assumptions of the study aren't problematic.
There are plenty of things to complain about such as this - on (pg14) it
is assumed that "Red Hat customers only install patches released by Red
Hat ... Windows customers only utilize fixes released by microsoft."
PROBLEM:  there may have been any number of much faster fixes, e.g.
Patching and recompiling, downloading tarballs from Apache, etc.  It is
assumed in the study that users are not advanced, and can only install
official patches.  While, in the real world, most UNIX users are a
little more able to do low level work.  At least in the UNIX world, you
probably CAN patch your server in a day or two, whereas with Microsoft
there is usually no workaround until the official patch comes.  They
explicitly admit this in item vii, pg. 15.  Thus, if the UNIX system is
truly mission-critical, the support will be top tier and probably able
to patch the bugs much faster than waiting for Microsoft.

I guess what I'm saying is that you can't say the study is wrong if they
release and follow their own methodology, but you CAN say its just plain
not relevant due to the assumptions and methodology.  And, lets not
forget, the person who FUNDS the study probably CONTROLS the
assumptions!  

Personally, I'm willing to go out on a limb and say that the study
probably *IS* irrelevant to intelligent, technical users, but it may not
be far off for the masses of putzes out there who only know how to "auto
update" their systems.

Mark Lachniet
 
> 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/
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ