As mentioned on the PaX site, Microsoft has DEP (their HW-based PAGEEXEC implementation) and (a weak) version of ASLR. I had remembered reading that Server 2008 would prevent a service from respawning for a period of time if it had crashed multiple times within a short period of time (deterring bruteforcing of ASLR -- something vanilla Linux doesn't have yet) but when I went to look for a link about it last, I couldn't find one.
EULAs don't stop security researchers from doing their work, nor does not having the source. Reverse engineering has advanced quite a bit in the past couple years, as well as the state of art in decompilation. Tools like BinDiff makes vulnerability finding in patches much quicker, while the Hex-Rays decompiler does a decent job of turning x86 assembly into C-like code. The Windows implementations of DEP and ASLR are pretty well documented publicly. Several companies have published papers on them and techniques for defeating the protections (for instance, it took a while for both Microsoft and Linux vendors to figure out that having a make_stack_executable() function without any safeguards wasn't such a good idea).
I sometimes wonder if there's a 'bystander effect' or 'free rider problem' involved with the "many eyes makes bugs shallow" view. There's a lot more people having a feeling of security based on the assumption that other people are reviewing the source instead of them, then there are actually people reviewing the source. The reality is, even though you have the kernel source, I'm pretty sure you don't audit it for security vulnerabilities, and if you did, it'd be impossible for you to audit every single line of it yourself. So in the end, you're putting trust in some entity, whether it's Microsoft or Linux vendors. It's naive to think Linux vendors are somehow unlike Microsoft in that they don't care about their stockholders -- everyone's in it for the money.
I wouldn't bet the farm anytime soon (though you've restated the challenge, which was initially Microsoft employees vs employees of Linux vendors, collectively) -- I know quite a number of people in the security industry. I can name several exceptionally bright security experts working for Microsoft, but can only think of one among the Linux vendors, who works for SuSE. Indeed, there are other bright people in the industry that work on Linux security -- Julien Tinnes and Tavis Ormandy come to mind, but neither of them are employed by a Linux vendor. To me, that says something. After all, security should should be the responsibility of the vendor, not Google; just as it's Microsoft's responsibility, not Mcafee's or Symantec's. Also, as far as the commercial security industry goes, there's far more people looking for vulnerabilities in Microsoft's software than there are looking at Linux -- simply because exploiting Microsoft software is more profitable (the same goes for underground exploit writers).
> That's an unfounded statement. Linus and many Linux developers have
> taken security more seriously than many that will ever pass through
you've apparently missed several past discussions both on here and LKML. It's pretty much agreed upon by the security industry that the official policy of the kernel developers (intentionally covering up security vulnerabilities by fixing the bugs without mentioning security impact that they're aware of) is damaging to users. Linus was nominated last year for the "Lamest vendor response" award: http://pwnie-awards.org/2008/nominees.html#lamestvendor
You mentioned not knowing about what Microsoft ships in their updates -- in fact, the security industry has a pretty good idea about what's being shipped in the updates. A huge number of exploits are written based on diffing an old binary with a newly patched binary. Though silent fixes could easily work their way into a service pack, it's harder to work one into the small patches that go out each month. The patches that are released are marked as security fixes. Sometimes obviously they get their security classification wrong and rightly get called to task for it. Of course, they seem to do a better job of it (again, this goes back to why it's important for the Linux vendors to have security experts on staff) than the tendency to call most vulnerabilities in the Linux kernel just "denial of service", when they're exploitable in reality. This has been commented on several times by several security experts. Three examples: http://kernelbof.blogspot.com http://www.security-express.com/archives/bugtraq/2006-07/... http://securitywatch.eweek.com/exploits_and_attacks/inter...