full-disclosure - Bigger burger roll needed

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <43453D17.4010703@sdf.lonestar.org>
Date: Thu Oct  6 16:05:07 2005
From: bkfsec at sdf.lonestar.org (bkfsec)
Subject: Bigger burger roll needed

Micheal Espinola Jr wrote:

>Bruce, I don't think you are going to find hard "evidence" for either
>conclusion.  But Bruce's conclusion is consistent with my own
>experiences, and that of many other Administrators that I discuss
>issues like this with.
>
>Since its inception, supporting NT 3.0 beta and onward, I have been
>dealing with BSOD's.  In total, there have been comparatively very few
>times were it was a direct fault of MS code.  It has very commonly
>been in relation to 3rd party drivers that needed reworking or
>updating by the 3rd-party manufacturer.
>
>This is not PR spin (of which I don't think you could find any
>published PR spin for either side of this argument either).  This is
>real world experience with the NT+ products across i386 and Alpha
>hardware platforms using peripheral devices from many different major
>manufactures.  There are admins on both sides of the anti-MS fence
>that I communicate with that would agree with this conclusion.
>
>  
>
I agree, in general, that the vast majority of the BSODs I've seen on 
the NT line have been caused by bad drivers.  On occassion, though, I 
have seen poorly written software that has BSOD'ed NT 4.0 before.

However, the original topic was about users and their exposure to 
Microsoft products.  User exposure to the NT line really began with 
Windows XP (aside from a smattering of Win2k installed desktops)... so 
the real initial exposure that users have had to Microsoft products is 
actually the DOS/Win9x line and those most certainly crashed frequently 
in situations where a driver wasn't necessarily the culprit.

Not to mention the fact that a Windows XP or 2000 system can still crash 
without getting a BSOD, and that crashes of either the OS or 
applications can and do regularly occur.  Further, the argument that 
third party drivers are always the cause and that merging code bases is 
not Microsoft's problem completely and totally ignores the fact that 
other OS' don't have the frequency of crashes experienced while using 
third party code that MS does.

So, whether it be the shoddy coding that causes BSOD's in the 
DOS-dependant line of MS apps, or the shoddy coding that causes IE to 
freeze on Windows XP... or the shoddy coding that third parties carry 
out and that Microsoft allows to affect the system in such a way... 
nonetheless the net result is the same... the user's expectation has 
been lowered.

                   -bkfsec