Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



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

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

From: Shawn Fitzgerald <sargon97_at_gmail.com>
Date: Tue, 28 Nov 2006 19:41:59 -0800

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_at_ngssoftware.com]
Sent: Tuesday, November 28, 2006 9:01 AM
To: Steven M. Christey; bugtraq_at_securityfocus.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
  
Received on Nov 29 2006

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]