Dieser Blog ist umgezogen // This Blog has moved: http://andreas-wolter.com/blog/

Andreas Wolter — Wed, 20 Sep 2017 10:41:00 +0000

Liebe Leser dieser Blog ist hiermit nur noch „Archiv“ und wird nicht mehr weiter gepflegt. Seit August 2017 finden sich neue Artikel ausschließlich unter der neuen URL: http://andreas-wolter.com/blog/	Dear Readers this blog is now merely an „archive“ and no longer being updated. Since August 2017 new articles are exclusively available under the new URL: http://andreas-wolter.com/en/blog/
Die aufwändige Mehrsprachigkeit (Deutsch und Englisch professionell manuell übersetzt) wird beibehalten – aber Layout-technisch anders gelöst. Damit dürfte ich immer noch den einzigen mehrsprachigen IT-Blog weltweit betreiben. Ich hoffe, das neue Design gefällt Ihnen.	The complex multilingualism (German and English professionally manually translated) is being continued – but solved differently in terms of layout. With that I most likely still operate the only multilingual IT-Blog worldwide. I hope you like the new design.

Mein aktueller Artikel, der erstmalig ausschließlich auf der neuen Website zu finden ist, lautet: Optimieren von Workflows mit In-Memory und nativ kompilierten Objekten - oder wie es nicht funktioniert

My currently last article, which is exclusively available at the new website for the first time, is Optimizing workflows with In-Memory and Natively Compiled Objects - or how it does not work

Cu at my new Blog

Andreas

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)

Andreas Wolter — Sat, 25 Jul 2015 10:40:00 +0000

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

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:

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:

http://blogs.msdn.com/b/sqlreleaseservices/archive/2015/07/14/ms15-058-sql-server-security-bulletin-released.aspx

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:

Securing SQL Server

SQL Server Security Blog

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

SQL Server & BI Blog by Andreas Wolter - Category: "Patching"

Dieser Blog ist umgezogen // This Blog has moved: http://andreas-wolter.com/blog/

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)