Security-Fixes for SQL Server and why Security Best Practices Matter
(MS15-058 SQL Server Security Bulletin)
With 14 July 2015, quite precisely one year after the first security bugs in 5 years had to be fixed, we have been given a new reason to test one’s security patching policy.
– Provided that you have such a policy for SQL Server.
And it is not my intention to point at anybody. Because: we have simply been spoiled due to the lack of security-related fixes in SQL Server. Security bugs (at least those that leaked out) have basically not occurred since SQL Server 2000.
– There is a range of statistics and papers, such as that by the American security expert David Litchfield (www.davidlitchfield.com/security.htm), the ITIC-Report from 2010, SQL Server Most Secure Database; Oracle Least Secure Database Since 2002, and the statistics by the NIST (National Institute of Standards and Technology) from 2013, on which the following graph is based:
Due to the fact that, based on the NIST data, the SQL Server has been the most secure database system 5 years in a row, it may indeed have moved away from the focus of administrators in terms of security patching.
The Security Bulletin from July 2015:
Vulnerabilities in SQL Server Could Allow Remote Code Execution (3065718)
https://technet.microsoft.com/en-us/library/security/MS15-058
3 security vulnerabilities are described here:
Which SQL Server versions are affected?
The list, starting with SQL Server 2008 Service Pack 3 and ending with SQL Server 2014, can be found in the bulletin.
A more detailed search is possible with the respective SQL Engine number in this blog article by Microsoft:
Under what circumstances can a system be attacked due to these bugs?
The preconditions for the three security bugs differ of course and are (on purpose) not described down to the last detail.
Yet WHAT is possible to read from it is that those who have set up rights only to a fine degree and dedicatedly are significantly less vulnerable since in part schema alteration rights in the database area are a prerequisite.
Therefore, I would like to recall that one is well-advised to really assign only necessary rights and to understand schemas as security areas. The use of db_owner, for example, should be off-limits for application users.
Those who have been following such rules so far may continue to feel fairly secure since the possibility to abuse these security vulnerabilities is thus greatly reduced.
For this reason, one should always take security best practices to heart.
A vulnerability does not yet make an exploit.
Here are a couple of links related to security matters in SQL Server:
SQL Server Best Practices – Implementation of Database Object Schemas
SQL Server 2012 Security Best Practices – Operational and Administrative Tasks
SQL Server 2012 Label Security Toolkit and white paper
SQL Server Database Ownership: recommendations
Guest account in User Databases
Schema-design for SQL Server: recommendations for Schema design with security in mind
Happy patching
Andreas
Leave a Reply
Want to join the discussion?Feel free to contribute!