Archives for: "July 2015"
Security-Fixes for SQL Server and why Security Best Practices Matter / Sicherheitsfixe für SQL Server und warum Sicherheits Best Practices wichtig sind (MS15-058 SQL Server Security Bulletin)
Jul 25th
(DE) - Wenn man denn eine solche für SQL Server hat. Und damit möchte ich jetzt niemanden anprangern. Denn: die letzten Jahre waren wir aufgrund des Mangels an Sicherheit bedingten Fixen in SQL Server schlicht verwöhnt. Sicherheitslecks (zumindest solche, die bekannt geworden sind) sind seit SQL Server 2000 so gut wie nicht mehr aufgetreten. - Dazu gibt es diverse Statistiken und Aufsätze, wie diesem von dem amerikanischen Sicherheitsexperten David Litchfield (www.davidlitchfield.com/security.htm) oder dem ITIC-Report von 2010: SQL Server Most Secure Database; Oracle Least Secure Database Since 2002 oder auch die Statistik vom NIST (National Institute of Standards and Technology) von 2013, auf der die folgende Grafik basiert: |
(EN) - 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: |
Dadurch dass er auf Basis der NIST-Daten 5 Jahre in Folge als sicherstes Datenbanksystem galt, mag der SQL Server in Sachen Sicherheitspatching durchaus aus dem Fokus der Administratoren gewandert sein. Der Security Bulletin vom Juli 2015: |
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
Beschrieben werden 3 Sicherheitslecks: |
3 security vulnerabilities are described here: |
- SQL Server Elevation of Privilege Vulnerability - CVE-2015-1761
- SQL Server Remote Code Execution Vulnerability - CVE-2015-1762
- SQL Server Remote Code Execution Vulnerability - CVE-2015-1763
Welche SQL Server Versionen sind betroffen? Die Liste, beginnend mit SQL Server 2008 Service Pack 3 und endend mit SQL Server 2014 findet sich im Bulletin. |
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: |
Unter welchen Umständen kann ein System durch diese Lücken angegriffen werden? Die Voraussetzungen sind für die 3 Sicherheitslecks natürlich unterschiedlich und auch (absichtlich) nicht bis ins letzte Detail beschrieben. Deswegen sollte man Best Practices für Sicherheit immer beherzigen. |
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. |
Hier noch ein paar Links in Sachen Security in SQL Server: |
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