USA 2005

### Overview In this talk, security researcher and consultant Cesar Serrudo examines the popular perception that Oracle Database is inherently secure while Microsoft SQL Server is notoriously insecure. Drawing on his firsthand vulnerability research auditing both systems—as well as the experience of his colleague, Esteban—Serrudo challenges common media narratives and marketing campaigns (such as Oracle's "Unbreakable" and Microsoft's "Trustworthy Computing"). By contrasting patch release timelines, response center attitudes, and overall vulnerability trends between 2001 and 2005, Serrudo demonstrates that the actual security posture and vendor responsiveness tell a very different story.

### Key Topics - **Media Narratives vs. Reality**: How media coverage of worm outbreaks created an enduring reputation that SQL Server was insecure and Oracle was bulletproof. - **Historical Vulnerability Trends (2001–2005)**: The impact of early blank administrative password exploits, worm outbreaks like Slammer, and how Microsoft and Oracle addressed incoming flaw reports over time. - **Vendor Response & Researcher Relations**: A direct comparison between the Microsoft Security Response Team (which matured and established researcher collaboration) and Oracle's security response (noted for slow communications, unresponsive staff, and weak patch verification). - **Patching Quality and Deployment**: Differences in patch complexity, public availability, and quality assurance failures, including faulty Oracle Critical Patch Updates (CPUs).

### Technical Details - **Vulnerability Counts**: Serrudo audited SQL Server extensively, reporting around 40 security bugs, and found 20 security bugs during a superficial audit of Oracle. His colleague reported over 100 vulnerabilities in Oracle. - **SQL Server History & Metrics**: Between 2002 and 2005, SQL Server suffered three worm outbreaks due to weak default configurations (e.g., blank administrative passwords) and pervasive internet-facing deployments. However, following a dedicated three-month security push in 2002 and improvements leading up to Service Pack 3, Microsoft dramatically lowered flaw counts, leaving only 2 remote exploitable vulnerabilities across 15 security bulletins in a three-year period, with zero unpatched known flaws by 2005. - **Oracle History & Metrics**: Over the same three-year window, Oracle had 24 security alerts containing 34 remote exploitable vulnerabilities and more than 100 reported vulnerabilities left unpatched. Vulnerabilities discovered in older versions like Oracle 8i still persisted into Oracle 10g. - **Patch Quality Assurance Issues**: Oracle's April and July CPUs suffered from poor quality assurance; for example, an April patch failed because an essential script was omitted, requiring a "patch for the patch." Another vulnerability reported by the researchers was patched only in 10g Release 1 while leaving 9i Release 2 vulnerable. - **Patch Usability & Defense**: SQL Server patches were made publicly available and easy to deploy (often requiring minimal manual steps), supported by free audit utilities like Microsoft Baseline Security Analyzer. Conversely, Oracle patches required access credentials, were complex and delicate to apply, and left internal functionality vulnerable to authenticated exploit queries that standard IDS/IPS cannot easily filter.

### Takeaways Serrudo concludes that a database vendor's security should not be judged merely by marketing claims or security certifications. While SQL Server earned a negative reputation due to worms targeting default installations on internet-facing systems, Microsoft invested heavily in code audits, responsive patch turnarounds, and public security tooling. In contrast, Oracle relied heavily on marketing and compliance certifications despite slow patch turnarounds, flawed patch testing, and poor researcher engagement.