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]

Date: Tue Oct  4 12:49:39 2005
From: jericho at attrition.org (security curmudgeon)
Subject: Bigger burger roll needed

: 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.

Fine, it isn't PR spin. But, compare this to Unix. How many times do you 
run user-land, 3rd party applications, that cause a kernel panic?

Why does Windows *let* third party applications BSOD the core operating 
system? Fine, Microsoft didn't code the application causing it, but they 
sure coded the operating system that doesn't know how to handle malformed 
input.

And the first few years of Windows 95 saw many, *many* BSODs that were due 
to Microsoft code. That lead to the general impression and sentiment you 
see today.