bugtraq - RE: Re: "Which is more secure? Oracle vs. Microsoft" (is it a fair comparison?)

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

Message-Id: <4D3265DC-5FA1-459B-A618-FEB135B6640A@gmail.com>
Date: Tue, 28 Nov 2006 19:41:59 -0800
From: Shawn Fitzgerald <sargon97@...il.com>
To: bugtraq@...urityfocus.com
Subject: RE: Re: "Which is more secure? Oracle vs. Microsoft" (is it a fair comparison?)

Not that I disagree (or know for that matter) but at blogs.oracle.com/ 
security/ they state that they, "Disclose the existence of  
vulnerabilities once cured, even if they are discovered internally."

Maybe someone should leave a comment correcting them or better yet  
invite them to discuss some of the issues brought up on this list.

Cheers, Shawn


-----Original Message-----

From: David Litchfield [

mailto:davidl@...software.com]
Sent: Tuesday, November 28, 2006 9:01 AM
To: Steven M. Christey; bugtraq@...urityfocus.com
Subject: Re: Re: "Which is more secure? Oracle vs. Microsoft" (is it  
a fair comparison?)
Hi Steven,
 > For example, there appears to be distinct difference in editorial
 > policy between Oracle and Microsoft in terms of publishing
 > vulnerabilities that the vendors discovered themselves, instead of
 > third parties. This might produce larger numbers for Oracle, which
 > appears to include internally discovered vulnerabilities in their
 > advisories, whereas this is not necessarily the case for Microsoft
 > [2], [3].
Oracle do not report issues they've found internally in their alerts.  
Every DBn in their alerts marries up to "public" flaws.
 > In both cases, the lack of details can mean that multiple issues wind
 > up with one public identifier; for example, Oracle Vuln#
 > DB01 from CPU Jul 2006 (CVE-2006-3698) might involve 10 different
 > issues, and this is not an isolated case. This can further muddy the
 > waters.
...which is why I broke every actual flaw down in the document. For  
example the following flaws are all covered by CVE-2002-0154
xp_proxiedmetadata overflow CAN-2002-0154 MS02-020 xp_mergelineages  
overflow CAN-2002-0154 MS02-020 xp_controlqueueservice overflow  
CAN-2002-0154 MS02-020 xp_createprivatequeue overflow CAN-2002-0154  
MS02-020 xp_createqueue overflow CAN-2002-0154 MS02-020  
xp_decodequeuecmd overflow CAN-2002-0154 MS02-020  
xp_deleteprivatequeue overflow CAN-2002-0154 MS02-020 xp_deletequeue  
overflow CAN-2002-0154 MS02-020 xp_displayqueuemesgs overflow  
CAN-2002-0154 MS02-020 xp_oledbinfo overflow CAN-2002-0154 MS02-020  
xp_readpkfromqueue overflow CAN-2002-0154 MS02-020  
xp_readpkfromvarbin overflow CAN-2002-0154 MS02-020 xp_repl_encrypt  
overflow CAN-2002-0154 MS02-020 xp_resetqueue overflow CAN-2002-0154  
MS02-020 xp_unpackcab overflow CAN-2002-0154 MS02-020
If someone is willing to sit down and do the research the details are  
"out there" and in a paper such as the comparison it was imperative  
to have these details.
Cheers,
David Litchfield