Glorf IT

Heute auf der Zugfahrt las ich in der Zeitschrift "database pro" (Ausgabe September/Oktober 2009) die Ergebnisse einer Gartner-Studie bei der 686 Unternehmen zu ihrem Einsatz von Datenbanksystemen befragt wurden. Für mich wenig überraschend gaben 70% an Oracle-Datenbanken zu nutzen, aber auch 68% nutzen den Microsoft SQL Server. Mehrfachnennungen waren offenbar erlaubt. Auch meine Firma nutzt drei DB-Systeme: SQL-Server, Oracle und DB2…

Mit etwas Abstand folgen jeweils MySQL mit 50% und DB2 mit 39%. Abgeschlagen dahinter folgen Informix, Sybase ASE/IQ und Teradata im Zehnerbereich. Die Restlichen werden nicht erwähnt. Leider wurde weder Link noch Name der Studie zur Quellenüberprüfung angegeben. Daher weiß ich nicht, um welche Unternehmen es sich handelte, wo sie "sitzen" und warum nur so wenige berücksichtigt wurden. Dennoch gebe ich das einfach mal so weiter.

Gestern suchte ich heraus, ob sich an der Liste der Features des "SQL Servers 2008 Express with advanced services" etwas gegenüber der Version 2005 geändert hat. Natürlich kommen alle neuen Features des 2005er Express hinzu, aber mir geht es um die "erweiterten Dienste". Und da bleibt offenbar alles wie es ist.

Die erweiterten Dienste kann man in der Übersicht gut an dem Sternchen in der Spalte "Express" erkennen. Sie bietet als Mehrwert gegenüber der normalen Express-Edition folgende Features:

• enthält eine abgespeckte Fulltext-Engine: Suche in gespeicherten Texten ist möglich
• enthält einen abgespeckten Reporting Service: Reports auf lokale Daten sind möglich, Report-Manager und Report-Desiger sind enthalten
• enthält eine abgespeckte Version des Verwaltungswerkzeuges: "SQL Server Management Studio Express". Hier wurde einige Dinge eingespart die für Entwickler relevant sind, wie bspw. die Projektverwaltung und Berichte

Andere spannende Dinge, wie der Profiler, Integration-Services, SQL Server Agent oder Database Mail sind weiterhin nicht in den kostenlosen Editionen enthalten. Dazu muss man weiterhin eine höhere Edition erwerben.

Frisch aus dem Urlaub zurück überraschte mich bei Heise die Nachricht, dass eine mir bisher unbekannte Firma ein Sicherheitsproblem am Microsoft SQL-Server entdeckt und veröffentlicht habe. Sie meldeten das Problem Ende 2008 an Microsoft und die signalisierten, dass das aus deren Sicht keine relevante Lücke sei und nicht behoben wird. Sentrigo schrieb daraufhin ein Tool, dass diese Lücke ausnutzt um sie zu beheben. Dazu muss man das Tool aber regelmäßig immer wieder aufrufen. Erst heute kam ich dazu mal die Hintergründe zu recherchieren.

Welche Tragweite hat das Problem?
Hat jemand Windows-Admin-Rechte an dem Computer auf dem der SQL-Server läuft, dann kann der Windows-Admin die Passwörter der angemeldeten Benutzer im Klartext lesen, weil sie in einer internen Tabelle pro Datenbank-Verbindung gespeichert werden. Das betrifft alle aktuellen Systeme: SQL Server 2000, SQL Server 2005 und SQL Server 2008 (die Betas von R2 daher vermutlich auch).

Während in der Login-Tabelle nur der Hash des Passwortes gespeichert ist, werden die Informationen zu angemeldeten Benutzern unverschlüsselt im Hauptspeicher gehalten. Ein Administrator kann nun mit geeigneten Werkzeugen, z.B. OllyDbg, den Hauptspeicher nach den Passwörtern durchsuchen. Sentrigo hat nun das kostenlose Werkzeug Passwordizer gebaut, dass diese Passwörter findet und mit Schrott überschreibt. Hier ein Beispiel:

C:\WINDOWS>E:\temp\Passwordizer\passwordizer\x86\passwordizer.exe 2212
Process is 32bit
DATA section found at 27cf000
Exe name is C:\Programme\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe
MSSQL Server version is 90000 10820000
Scanning for sessions table (Can take up to several minutes)
Session table found at 27e6fe8
Getting user passwords for MSSQL Server 2005
Session id: 51
Username: sa
Password: k******9
Password cleared from memory

Sentrigo Passwordizer process completed successfully
1 passwords removed from memory

Im Output steht eigentlich alles was man wissen muss, insbesondere die Adresse an der die Informationen gefunden werden können. Natürlich ist die bei jedem Start anders, aber damit kann man sich das Problem mal aus der nächsten Nähe ansehen, weil man ja jetzt genau weiß wo man suchen muss.

Aber auch remote kann man die Passwörter lesen, wenn man am SQL-Server SysAdmin-Rechte hat. Das geht aber nur am SQL-Server 2000 und 2005, ab 2008er wurde laut Heise.de der dazu nötige DBCC-Befehl aus anderen Gründen entfernt. Im Securosis Blog verrät ein Sentrigo-Mitarbeiter, dass man "DBCC BYTES" dazu verwenden kann. Das ist aber kein großes Geheimnis, denn nur DBCC Bytes ist im SQL Server 2008 nicht mehr vorhanden, alle anderen gibt es dort weiterhin.

Meine Einschätzung: Ich sehe keine realistische Gefahr für die SQL-Server-Kunden, aber Microsoft hat einen peinlichen PR-Gau erlebt.

Warum? Die Sicherheitslücke ist schon sehr exotisch. Man muss schon zuerst mal Windows-Admin oder wenigstens SQL-Server-SysAdmin sein, um die Lücke ausnutzen zu können. Und dann sieht man nur die Passwörter derjenigen die sich aktuell über SQL-Authentifizierung angemeldet haben. Wenn man die von Microsoft empfohlene Windows-Authentifizierung verwendet, sieht man gar nichts. Was kann der Windows-Admin, der immer auch zugleich SysAdmin ist, mit den SQL-Server-Passwörtern anfangen? Gute Frage. Er darf alles tun, was er ohnehin schon als SysAdmin darf: sich als dieser Benutzer ausgeben und am SQL-Server Dinge in dessen Namen tun.

Die Gefahr besteht also lediglich darin, dass der Anwender SQL-Authentifizierung nutzt und das gleiche Passwort auch für sein Online-Banking, E-Bay oder dergleichen verwendet. Das könnte ein krimineller Windows-Admininistrator mal ausprobieren und ggf. dann tun was er möchte. Die Lücke ist in meinen Augen eher eine Kleinigkeit, da Administratoren auch auf viel einfachere Weise die Passwörter Ihrer Kollegen ausspähen könnten. Dennoch ist es natürlich eine Lücke und eine peinliche noch dazu.

Aber für die bisher weitgehend unbekannte Firma Sentrigo war das der PR-Boost schlechthin. Sie haben Microsoft so richtig vorgeführt, weil Microsoft danach schrie. Natürlich hätte Microsoft das ernst nehmen müssen. Man speichert einfach keine Passwörter im Klartext. Warum auch? Ich habe keine Ahnung wie aufwändig die Behebung gewesen wäre, aber da nun mal alle Mitarbeiter mit dem R2 beschäftigt waren, blieb für solche Dinge wohl keine Zeit mehr. Und damit hat sich Microsoft so richtig blamiert.

Vermutlich werden sie es nun doch beheben müssen, sonst müssen sie sich immer vorwerfen lassen, dass sie eine nicht behobene Sicherheitslücke haben. Und diese Diskussionen mag doch keine Firma gerne… 😉

Update 16.9.2009:

• Ja, es geht mittels DBCC BYTES, das wurde schon im Frühjahr im Vortrag "SQL SERVER Anti-Forensics" von Cesar Cerrudo (Folie 18) veröffentlicht.
• Heute bekam ich eine Mail von Firma Sentrigo, die sich für den Download des Tools "Passwordizer" bedankte und fragte an welchen Lösungen von ihnen ich denn Interesse hätte. Hallo? Am Passwordizer natürlich. Ich bereue bei der Angabe der persönlichen Daten ehrlich gewesen zu sein…

Alle Interessierten sind zu unserem Jubiläumstreffen "5 Jahre PASS Deutschland" zur Regionalgruppe Franken am Dienstag, den 15.09.2009 um 18:30 Uhr, eingeladen.

Der PASS Deutschland e.V. wurde am 31.08.2004 gegründet und feiert deshalb im August/September 2009 in allen Regionen das fünfjährige Bestehen. Zu diesem Jubiläum sind in allen Regionen Treffen der Regionalgruppen mit besonderem Inhalt geplant:

SQL Server 2008 R2: Self Service BI, SQL Server Data Warehouse Scale Out und weitere Neuheiten. Referent ist Oliver Goletz, Microsoft. Hier die offizielle Info zu dem Vortrag:

In der ersten Hälfte 2010 wird Microsoft basierend auf der SQL Server Technologie die Basis für eine Scale-out SQL Server Lösung für sehr große DWH liefern. Das derzeit unter dem Codenamen Madison bekannte Produkt basiert auf der MPP-Technologie (Massively Parallel Processing), die von DATAllegro entwickelt und von Microsoft erworben wurde. Mit dieser Technologie, die sich schon im Praxiseinsatz bewährt hat, werden DWH im Bereich von mehreren 100 TB möglich sein.

Im Bereich Business Intelligence wird mit dem Produkt Gemini ein In-Memory Online Analytic Processing (OLAP) Client integriert, der "Self Service BI" durch Datenanalyse in großem Umfang und die Datenmodellierung in Excel auf Basis verschiedenster Datenquellen in der Office Plattform ermöglicht.

Oliver Goletz hat nach seinem Studium der Wirtschaftsinformatik in Köln sechs Jahre bei einem Microsoft Gold Partner SQL- und BI-Projekte durchgeführt. Danach arbeitete er anderthalb Jahre als Projektmanager für die Siemens AG in Schanghai und Beijing. Seit zwei Jahren ist er als Technologieberater für Großkunden im Bereich SQL und BI bei Microsoft Deutschland tätig. In dieser Rolle führt er regelmäßig Kundenveranstaltungen und EBCs sowie Deep-Dive SQL-Partnertrainings durch.

Wir treffen uns diesmal in einem größeren Rahmen, in den Konferenzräumen des Eurocom Centers, Lina-Ammon-Str. 19 (Erdgeschoss) in Nürnberg. Das liegt verkehrsgünstig direkt an der U-Bahn-Station Scharfreiterring.

Und wie jedes Mal so ist auch diesmal der Eintritt frei, auch Nicht-Mitglieder sind herzlich eingeladen. Bitte dennoch bei Klaus Oberdalhoff unter kob(ät)sqlpass.de anmelden, damit er weiß, wie viele Stühle ungefähr benötigt werden.

In dem Artikel "Advanced SQL Injection In SQL Server Applications" beschreibt Chris Anley (NGSSoftware) sehr ausführlich wie SQL-Injection am SQL-Server funktioniert. Darin findet man problemlos die Anleitung wie man vorgehen muss, um einen SQL-Server mit dieser Lücke zu übernehmen. Natürlich geht er vom schlimmsten Fall aus, dass nämlich die Anwendung Admin-Rechte am SQL-Server hat, aber das ist ja auch nicht ganz unrealistisch.

Das ist eine Pflichtlektüre für jeden, der Software mit Zugriffen aus dem Microsoft SQL Server schreibt. Danach weiß man, was man besser absichern sollte und warum… 😉

In dem Artikel "Wer sind heute meine 5 Langläufer? " beschrieb ich ein gefundenes SQL-Statement mit dem man sich Infos zu den langsamsten SQL-Statement anzeigen lassen kann. Im Laufe der zeit modifizierte ich die Abfrage immer weiter.

Hier ist die verbesserte Fassung, die viele weitere interessante Angaben über den Befehl macht:

SELECT TOP(200)
qs.execution_count AS "Executions",
CAST(CAST(qs.total_elapsed_time AS NUMERIC(20,4))/1000/qs.execution_count AS NUMERIC(20,4)) AS "AvgDuration[ms]", – Umrechung in Millisekunden
CAST(CAST(qs.total_worker_time AS NUMERIC(20,4))/1000/qs.execution_count AS NUMERIC(20,4)) AS "AvgCpuTime[ms]", – Umrechung in Millisekunden
SUBSTRING(st.text,(qs.statement_start_offset+2)/2, – Offset wird in Bytes angegeben
(CASE WHEN qs.statement_end_offset = -1
THEN LEN(CAST(st.text AS NVARCHAR(MAX)))*2
ELSE qs.statement_end_offset
END – qs.statement_start_offset)/2) AS "SqlStatement",
CAST(CAST(qs.last_elapsed_time AS NUMERIC(20,4))/1000 AS NUMERIC(20,4)) AS "LastDuration[ms]", – Umrechung in Millisekunden
CAST(CAST(qs.last_worker_time AS NUMERIC(20,4))/1000 AS NUMERIC(20,4)) AS "LastCpuTime[ms]", – Umrechung in Millisekunden
CAST(CAST(qs.total_elapsed_time AS NUMERIC(20,4))/1000 AS NUMERIC(20,4)) AS "TotalDuration[ms]", – Umrechung in Millisekunden
CAST(CAST(qs.total_worker_time AS NUMERIC(20,4))/1000 AS NUMERIC(20,4)) AS "TotalCpuTime[ms]", – Umrechung in Millisekunden
qs.total_logical_reads AS "TotalLogicalReads",
qs.total_physical_reads AS "TotalPhysicalReads",
qs.total_logical_writes AS "TotalLogicalWrites",
qs.creation_time AS "FirstExecution",
qs.last_execution_time AS "LastExecution",
db_name(st.dbid) AS "Database"
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS st
WHERE qs.total_elapsed_time > 0
ORDER BY "AvgDuration[ms]" DESC, qs.execution_count DESC

Viel Erfolg damit… 🙂

Wenn man im SQL Server 2005 wissen will, was so alles im Datencache steht, dann kann man sich mit Hilfe der Data Management View "sys.dm_os_buffer_descriptors" einen Überblick verschaffen. Man erfährt welche Seite in den Cache geladen wurden.

Mit diesem Statement sieht man sogar wie viele Seiten aktuell von welcher Tabelle aus welcher Datenbank im Cache "belegt" werden:

SELECT CASE GROUPING(db.name) WHEN 0 THEN db.name ELSE N'#all dbs#' END AS [dbname],
CASE GROUPING(object_name(p.object_id)) WHEN 0 THEN object_name(p.object_id) ELSE N'#all objects#' END AS [objname],
CASE GROUPING(p.index_id) WHEN 0 THEN CAST(p.index_id AS NVARCHAR) ELSE N'#all indexes#' END AS [indexid],
COUNT(page_id) AS [pagecount]
FROM sys.dm_os_buffer_descriptors AS bd
JOIN sys.allocation_units AS au
ON bd.allocation_unit_id = au.allocation_unit_id
JOIN sys.partitions p
ON au.container_id = p.hobt_id
JOIN sys.databases as db
ON bd.database_id = db.database_id
GROUP BY db.name, object_name(p.object_id), p.index_id WITH ROLLUP
ORDER BY [pagecount] DESC

Ich hoffe das hilft jemandem… 😉

Wie man mit dem SQL-Server Text-Dateien einlesen kann, wusste ich schon länger. Dazu musste man früher OpenRowSet mit einem ODBC-Text-Treiber verwenden:

SELECT *
FROM OPENROWSET('MSDASQL',
'Driver={Microsoft Text Driver (*.txt; *.csv)};DEFAULTDIR='E:\data;Extensions=txt;',
'SELECT * FROM [test.txt]') AS t;
Aber das war tricky und der Output war immer pro Zeile ein Datensatz. Freilich konnte man auch die Daten mittels "BULK INSERT" in eine Tabelle laden, aber auch das war umständlich. Seit SQL-Server-2005 gibt es dazu eine gute und dokumentierte Lösung:

SELECT x
FROM OPENROWSET(BULK 'E:\data\test.txt', SINGLE_CLOB) AS t(x);

Das funktioniert auch mit Bildern oder beliebigen anderen Dateien, dann ist es aber ein "SINGLE_BLOB". Aber das Schreiben ist so immer noch nicht möglich. Freilich kann man auch hier wieder mit OpenRowSet arbeiten. Der Text-Treiber kann aber keinen INSERT, daher muss man dann schon den Treiber für Access nehmen und so tun als wäre es eine csv-Datei. Mit dem gelang es aber nicht eine neue Datei anzulegen. Man musste also zuerst eine leere Datei via xp_cmsshell anlegen und konnte sie dann füllen. Das geht aber nur mit 32-Bit-SQL-Servern, weil es gibt keine 64-Bit-Treiber für die Jet-Engine gibt… 🙁

Bei Simple-Talk fand ich eine praktikable Lösung dazu: Man verwendet "bcp" via "xp_cmdshell", um die Daten in eine Text-Datei zu schreiben. Klingt schwierig, ist es aber nicht. Wie für alle obigen Lösungen benötigt man auch hier Admin-Rechte. Die Lösung taugt also nicht für den laufenden Betrieb, aber eignet sich prima für eigene administrative Aufgaben.

DECLARE @Cmd nvarchar(2000);
SET @Cmd = N'bcp "select t from [TestTable]" queryout "F:\temp\outfile.txt" -T -S'
+ @@servername + N' -w'; – "-w" für Unicode-Datei "-c" für ANSI
EXEC xp_cmdshell @Cmd;

Natürlich muss man die Verwendung von xp_cmdshell erst mal erlauben.

Hier steht der Trick im Detail beschrieben und etliches mehr: "The TSQL of Text Files"

Mein Kollege Peter machte mich auf einen Tests für Bewerber aufmerksam. Man solle Ihnen eine leichte Programmmieraufgabe geben, um die Fähigkeiten des Kandidaten zu erleben. Als Beispiel soll ein Programm die Zahlen von 1 bis 100 ausgeben. Ist die Zahl hingegen durch 3 teilbar, dann statt dessen "Fizz". Ist sie durch 5 teilbar, dann "Buzz". Ist sie aber durch 3 und 5 teilbar, dann "FizzBuzz". Erstmals beschrieben wurde das offenbar im Artikel "Using FizzBuzz to Find Developers who Grok Coding".

Das Ganze hat zwei Aspekte:

• Taugen solche Tests überhaupt, um im Bewerbergespräch wertvolle Erkenntnisse zu sammeln?
• Und wie ist die TSQL-Lösung dieser konkreten Aufgabe… 😉

Ich bin unsicher wegen der Aussagekraft: Ich persönlich würde gut ausgearbeitete Tests zur Auswahl der Bewerber befürworten, um einfach besser einschätzen zu können, ob sie die gewünschten Qualifikationen haben. Leider kann ich in Bewerbergesprächen nicht so gut einschätzen, was die Leute nur sagen und was sie tatsächlich können. Leider erlebte ich schon, dass die Selbsteinschätzung und dementsprechend die Darstellung der Bewerber stark von der Wirklichkeit abwich.

Aber was sagt so ein Luschi-Test aus? Ich nehme mal an, dass er nur die totalen Blender ausfiltert, oder? Hat er sonst noch einen positiven Effekt?

Jetzt zum spaßigen Teil. In dem oben genannten Blog-Beitrag bringt jemand eine TSQL-Lösung:

declare @counter int
declare @output varchar(15)
set @counter = 1
while @counter < 101 begin set @output = '' if @counter % 3 = 0 set @output = 'Fizz' if @counter % 5 = 0 set @output = @output + 'Buzz' if @output = '' set @output = @counter print @output set @counter = @counter + 1 end

Diese Lösung gefällt mir besser:

SELECT
CASE WHEN number%15=0 THEN 'FizzBuzz'
WHEN number%3=0 THEN 'Fizz'
WHEN number%5=0 THEN 'Fizz'
ELSE CAST (number AS Varchar(10)) END AS "number"
FROM master.dbo.spt_values
WHERE type='P'
AND number BETWEEN 1 AND 100

Wem das zu wenig tricky ist, hier eine komplexere Lösung, die ohne Modulo auskommt:

SELECT
ISNULL(MAX(T.word),CAST (number AS Varchar(10))) AS "number"
FROM master.dbo.spt_values AS S
LEFT OUTER JOIN ( SELECT 3, 'Fizz' UNION
SELECT 5, 'Buzz' UNION
SELECT 15, 'FizzBuzz') AS T(num,word)
ON S.number%T.num=0
WHERE S.type='P'
AND S.number BETWEEN 1 AND 100
GROUP BY S.number

Neben den modernen Datenbankzugriffsschichten wie ADO.net, LINQ oder Entity-Framework sind in den älteren Systemen meist noch die guten alten Schnittstellen wie ODBC und OLEDB im Einsatz. Um Daten zu holen gibt es hier nur die Möglichkeit Cursor zu öffnen. Die entsprechenden ODBC- oder OLEDB-Befehle rufen am SQL-Server Stored-Procedures auf, die die Cursorverwaltung und -abarbeitung übernehmen.

Bei sourceforge.net fand ich neulich zufällig eine Beschreibung dieser Prozeduren: "SQL Server API Server Cursors". Wer unbedingt Cursor benötigt, z.B. weil er die Daten seitenweise lesen muss, der könnte sich damit seine eigenen .net-Cursor schreiben…

Bei jedem Start des SQL-Servers wird eine neue Errorlog-Datei angelegt. Die alten werden aber nicht sofort überschrieben. Stattdessen werden die letzten 6 beibehalten. Das gleiche kann man auch dediziert auslösen:

EXEC sp_cycle_errorlog

Dabei passiert Folgendes:

• Datei "errorlog.6" wird gelöscht
• Datei "errorlog.5" wird in "errorlog.6" umbenannt
• Datei "errorlog.4" wird in "errorlog.5" umbenannt
• Datei "errorlog.3" wird in "errorlog.4" umbenannt
• Datei "errorlog.2" wird in "errorlog.3" umbenannt
• Datei "errorlog.1" wird in "errorlog.2" umbenannt
• Datei "errorlog" wird in "errorlog.1" umbenannt
• Das neue "Errorlog" wird angelegt.

Man kann sich vom SQL-Server die Liste der aktuell verwalteten Errorlogs anzeigen lassen:
EXEC sp_enumerrorlogs

Beispiel:

Will man sich ein Errorlog ansehen, dann geht das mittels sp_readerrorlog:
EXEC sp_readerrorlog 0

Oder mit xp_readerrorlog: Hier gibt es mehr Parameter.
EXEC master.dbo.xp_readerrorlog 6, 1, 'Version', NULL, NULL, NULL, N'asc'

• Nummer des Errorlogs
• optional: Typ des Errorlogs: 1=SQL Server (Default), 2=SQL Agent
• optional: Suchstring 1
• optional: Suchstring 2
• optional: Suchstring 3
• optional: Sortierung "asc" (Default) oder "desc"

Mein Kollege Vladimir zeigte mir einen guten, aber undokumentierten Trick, wie die Anzahl der historischen Errorlogs erhöht werden kann. Dazu muss man unter [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer] den Key "NumErrorLogs" (REG_DWORD) z.B. auf "99" setzen. Wobei "MSSQL.1" für die Instanznummer steht. Die Liste der Instanzen und deren Numemrn steht unter [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL].

Hinweis: Wird der Wert von "99" dann wieder auf einen niedrigeren gesetzt, dann muss man selber dafür sorgen, dass die "alten" Errorlogs über der neuen Maximalzahl gelöscht werden.

Leider fand ich dazu so gut wie keine Infos, lediglich auf MS-Connect ist das mal offiziell erwähnt… 😉

In der aktuellen Ausgabe des SQL-Server Magazine wird ein "Mega Guide to Free SQL Server Tools" veröffentlicht. Die wirklich lange Liste wirkt etwas lieblos zusammengestellt, aber da kann ich mich täuschen. Sie ist jedenfalls so lang, dass ich nur wenige Einträge wirklich las. Vermutlich muss ich mir irgendwann mal die Zeit nehmen, um sie ganz durch zu arbeiten und die relevanten Werkzeuge mal anzusehen. Einige kenne und nutze ich ja auch tatsächlich schon…