Last week a web-based news story comes to my attention - Microsoft's glasnost on interoperability means more bugs.  The article poses an interesting question of whether Microsoft's recent changes to expand interoperability will make it easier for researchers to find new vulnerabilities.  I don't personally agree with the theory that sharing APIs will cause an influx of new bug discoveries, but it is an interesting read...

... except for one little quote, which asserted that last year SQL Server had "...most vulnerabilities last year of any commercial database..."  That is a big error, though it may be a misquote or a miscommunication.  Certainly, if you go look at the current version of the original article, the incorrect statement has been removed.

However, given that as of today, some versions of the article containing the original (incorrect) quote are still available, I thought it worth documenting the real (really good) story of SQL vulnerabilities and what commercial database had the most vulnerabilities last year.

• Microsoft Security Bulletin search tool shows 0 bulletins for SQL Server 2005 over the life of the product, which shipped about 2.5 years ago.
  • Secunia Page for SQL Server 2005 affirms this, showing 0 advisories over the life of the product
• Microsoft Security Bulletin search tool shows that SQL Server 2000 has not had a Security Bulletin for over 4 years (January 2004)
  • Secunia Page for SQL Server 2000 affirms this, showing the most recent Secunia advisory in January 2004
• I did a scan of the National Vulnerability Database (NVD) http://nvd.nist.gov for "Microsoft" and "SQL" and found only three issues disclosed since July 2003 (only 3 in the 4.5 years).  It turns out only one of them may be attributed to SQL and even then, it is a client side control:
  • CVE-2004-1560.  This one was disclosed in Sep-04 and only affected SQL Server 7
  • CVE-2007-5090.  This one was disclosed in Sep-07 and is actually a vulnerability in IBM Rational ClearQuest
  • CVE-2007-4814.  Disclosed in Sep-07, this is a vuln in client side control sqldmo.dll 2000.085.2004.00.  I can't tell for sure, but this looks like a SQL 2000 component based upon the versioning.
• Finally, I thought I'd check the Symantec-owned www.securityfocus.com web site and searched on their vulnerability search page.
  • A search on "SQL Server", the latest it identified the Sep-04 vulnerability that affected SQL 7
  • A search on "SQL Server 2005" identifies the client side CVE-2007-4814 as the latest issue plus 2 issues in 2006 that affect Xml Core Services
  • A search on "SQL Server 2000" identifies a 2002 issue as the latest since the page was modified in 2007.  Before that, the Xml Core Services issues of 2006

In contrast, I can briefly look at Oracle Critical Patch Updates (CPU) for 2007:

Critical Patch Update - January 2007	17 db vulns, 13 for 10g
Critical Patch Update - April 2007	16 db vulns, 13 for 10g
Critical Patch Update - July 2007	18 db vulns, 16 for 10g
Critical Patch Update - October 2007	30 db vulns, 16 for 10g

So.  One thing is clear from the rudimentary investigation I've performed here - SQL Server was not even close to having the most vulnerabilities last year of any commercial database.

In fact, though SQL 2000 Server may have had a rough track record up through 2003, the SQL team has certainly turned a corner since then and SQL Server 2005 has had one of the best security track records of any commercial database ever.

Let me close be re-quoting something I highlighted in a post a little over a year ago from David Litchfield in his paper Which database is more secure? Oracle vs. Microsoft:

Why have there been so little bugs found in SQL Server since 2002?
Three words: Security Development Lifecycle – SDL. SDL is far and above the most
important factor. A key benefit of employing SDL means that knowledge learnt after finding and fixing screw ups is not lost; instead it is ploughed back into to the cycle. This means rather than remaking the same mistakes elsewhere you can guarantee that new code, whilst not necessarily completely secure, is at least more secure than the old code.

I’m not claiming SQL Server is utterly vulnerability free, and I most certainly would never claim SQL Server is unbreakable, but the SQL Server team has made huge progress securing their customers.

Share this post :