(DE)
Ziemlich genau ein Jahr, nachdem die seit 5 Jahren ersten Sicherheits-Bugs in SQL Server gefixt werden mussten, gibt es nun, seit 14.7.2015, wieder einen Grund, seine Security-Patching-Policy zu testen.

- 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)
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:

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:

Beschrieben werden 3 Sicherheitslecks:

3 security vulnerabilities are described here:

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.
Genauer kann man anhand seiner jeweiligen SQL Engine Nummer in diesem Blog-Artikel von Microsoft suchen:

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.
WAS man jedoch herauslesen kann, ist, dass diejenigen, die Rechte nur sehr feingradig und dediziert gesetzt haben, wesentlich weniger angreifbar sind, da teilweise Schemaänderungsrechte im Datenbank-Bereich Voraussetzungen sind.
Daher erinnere ich an dieser Stelle gern daran, dass man weise beraten ist, wirklich nur benötigte Rechte zu vergeben, und Schemas als Sicherheitsbereiche zu verstehen. Die Verwendung von db_owner beispielsweise sollte Tabu für Applikations-Benutzer sein.
Wer solche Regeln bisher beherzigt hat, kann sich auch weiterhin einigermaßen sicher fühlen, da die Möglichkeit, diese Sicherheitslecks auszunutzen somit stark verringert ist.

Deswegen sollte man Best Practices für Sicherheit immer beherzigen.
Eine vulnerability ist eben noch kein exploit.

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: