Glorf IT

Im Zusammenhang mit meinem Posting "JTL-Wawi und das veröffentlichte SA-Passwort" stellte Ralph die Frage, wie kritisch es ist, wenn ich eine Anwendung nutze, die immer mit dem Sysadmin arbeitet. In dem Posting habe ich schon beschrieben, warum es für einen Angreifer ein so großes Geschenk ist an das SA-Passwort zu kommen. Kurz gesagt, er kann sich damit bislang meistens zum Administrator am Server machen.

Im konkreten Fall kann zunächst jeder Depp einen Angriff durchführen solange das im Internet veröffentlichte Default-Passwort nicht geändert wird. Gehen wir also mal davon aus, ein Admin ändert das SA-Passwort. Wie gefährdet bin ich dann als Nutzer so einer Software?

Wenn man einschätzen will, wie kritisch eine Lücke ist, dann muss man zwei Fragen beantworten:

• Wie schlimm ist es, wenn jemand die Lücke ausnutzt?
• Wie schwierig ist es, die Lücke auszunutzen?

Wie lauten die Antworten in diesem konkreten Fall, wenn die Software als Prozess am Arbeitsplatz ausgeführt wird?

Wie schlimm ist es, wenn jemand die Lücke ausnutzt?

Worst Case! Weil der SQL-Server-Dienst im Systemkontext läuft, ist der Server kompromittiert oder der Einzelarbeitsplatz kann komplett aus der Ferne übernommen werden, ja nachdem wo der SQL Server installiert wurde. Nichts ist mehr sicher, dem Angreifer ist nichts unmöglich.

Wie schwierig ist es, die Lücke auszunutzen?

Es sind mehrere Lücken, die beide damit zu tun haben, dass die Anwendung am Arbeitsplatz ausgeführt wird und damit im Kontext des Benutzers:

• Das SA-Passwort wird beim Einrichten an eine Stelle geschrieben, die jeder Benutzer lesen kann. Die verwendete Verschlüsselungsmethoden sind leicht protokollierbar, der Schlüssel ist ebenso zugänglich. Das ist für einen ernsthaften Angreifer die einfachste Methode: Die Software bei sich installieren, in aller Ruhe ausspähen und einen Exploit schreiben, der anderen zur Verfügung gestellt werden kann.
• Während des Zugriffs kann jeder Prozess, der im gleichen Benutzerkontext läuft wie das JTL-WAWI, den JTL-WAWI-Prozess ausspähen: er kann den Hauptspeicher durchwühlen, die von der Anwendung verwendeten Schnittstellen sniffen oder sich sogar als Debugger an den Prozess hängen. Wenigstens seit Windows-XP hat jeder Windows-Benutzer das Recht die "eigenen" Prozesse derart zu untersuchen. Viele Entwickler glauben offenbar dazu wären Admin-Rechte nötig. Daher habe ich beschlossen für diese Zielgruppe ein Buch zur Sicherheit von Anwendungen mit SQL-Server zu schreiben. Mal schauen, ob es auf Interesse stößt.

Als Angreifer haben wir also zwei Angriffspunkte, um an das begehrte SA-Kennwort zu bekommen. Wie man das ganz konkret macht, beschreibe ich hier absichtlich nicht. Angehende Skript-Kids möchte ich nicht zu unüberlegten (weil kriminellen) Handlungen verleiten. Aber seien Sie sicher, dass die bösen Jungs wissen wie das funktioniert. Jeder Fachinformatiker im ersten Lehrjahr sollte dazu in der Lage sein. Ebenso reichen die im Informatikunterricht vermittelten Kenntnisse, um sich da einzulesen.

Es ist nur die Frage, ob Angreifer sich die Mühe machen. Das hängt davon ab, was zu holen ist und wie verbreitet die Software ist und wo der Angreifer sitzt?

Wo sitzt der Angreifer?

Falls mein Geschäft eine Oneman-Show ist und die Software nur auf einem Einzelarbeitsplatz läuft, dann dürfte der Angriff am ehesten über das Internet erfolgen, z.B. durch Ausnutzen einer bekannten, noch ungelösten Lücke (z.B. Internet-Explorer oder Flash) oder einfach per Mailanhang z.B. (präpariertes PDF). Der Schädlich könnte schauen, ob er in der Registry das SA-Kennwort findet, anhand des ebenfalls dort stehenden Schlüssels entschlüsselt und ggf. via SQL Server sein schändliches Werk tun.

Falls der SQL-Server im Netzwerk auf einem Server installiert ist, dann dürften mehrere Mitarbeiter vorhanden sein. Für jeden Arbeitsplatz gilt die gleiche Angriffsmöglichkeit wie beim Einzelplatz. Zugleich kommt noch hinzu, dass ein Mitarbeiter anhand einer der vielen Anleitungen einen Sniffer startet (sehr einfach, auch für absolute Laien), das SA-Kennwort erspäht (dito) und dann die Grenzen der Möglichkeiten erprobt (mit Excel zum SQL Server verbinden ist nicht schwer, über SQL Server andere Dateien auslesen erfordert schon mehr Skills). Je nach Motivation des Mitarbeiters kann er sich dann austoben: Die Möglichkeiten reichen vom Stillen der Neugier (steht dort auch, was die Kollegen verdienen) und Kundendaten mitnehmen (um den geplante Start in sie Selbstständigkeit zu erleichtern) bis hin zur Rache (Festplatte formatieren, weil Gehaltserhöhung nicht bekommen, MS fühlt sich ungerecht behandelt, ihm wurde gekündigt, …)

Weil es geht…

In den letzten Jahren kam ein Trend auf, der alle obigen Ausführungen relativiert. Mit den sogenannten Skript-Kids kamen Angriffe hinzu, wo die Angreifer keine wirtschaftlichen Betrachtungen anstellen: Lohnt sich der Aufwand, was ist zu holen, … ? Gerade weil es so einfach ist, werden von meist Jugendlichen Angriffe ausgeführt, einfach nur weil es geht und sie Grenzen austesten wollen. Die Motivation ist hier der Spaß am Knobeln und vielleicht der Prestige-Gewinn im Freundeskreis. Weil es ihnen nicht darum geht damit Geld zu machen, ist es ihnen egal wie lange sie dafür brauchen, sie haben ja nach der Schule meist viel Zeit. Viele der besonders populären Angriffe der letzten Jahre auf Sony etc. waren so motiviert. Die öffentliche Bestrafung einiger der Skript-Kids führte aber in meinen Augen nicht dazu, dass weniger Angriffe durchgeführt werden. Die Kiddies prahlen damit halt nicht mehr so öffentlich.

Und die benötigte Kenntnisse? SQL lernen bayerische Gymnasiasten in der 9ten Klasse…

Update 3.2.2013: Zuschriften entnahm ich, dass einige nicht glauben, dass auch mit normalen Benutzerrechte die beschriebenen Spionageaktionen möglich sind. Daher können interessierte Entwickler anhand dieser Anleitung die benötigten Rechte selber überprüfen.

Heute wurde die Erstauflage des Buches "Microsoft SQL Thinking" gedruckt. Ab Montag sollte es im Handel für Euro 34.95 erhältlich sein. Das Buch richtet sich an SQL-Einsteiger: Entwickler, Betriebswirte und Neugierige.

Der Unterschied zu den mir bisher bekannten Büchern ist der schnelle Einstieg anhand von Beispielen. Anstelle langwierig und methodisch alle relevanten Funktionen aufzulisten, wird SQL praxisbezogen vermittelt. Von mir sind die Kapitel 9 bis 19, sowie die Anhänge A und B. Das Schreiben machte Spaß, das Lesen hoffentlich auch.

Details und Fehlerkorrekturen werden auf SQL-Thinking.de veröffentlicht. Hier können Leser gerne Kommentare hinterlassen, z.B. Verbesserungsvorschläge für die zweite Auflage.

Wer die Transact-SQL Data Manipulation Language (DML) Reference schon immer mal gerne als eBook haben wollte, der kann nun zugreifen:

• epub
• mobi
• PDF

Es enthält wirklich (einfach nur) den Text aus den Books Online. Aber halt als eBook zum mitnehmen.

Durch die installation der Software JTL-Wawi-Full holt man sich ein gravierendes Sicherheitsproblem aufs System, wenn man einfach nur die Standard-Installation gemäß Anleitung durchführt: Man hat dann einen SQL Server 2005 SP2 (Express Edition), der im Systemkontext läuft und ein fest vorgegebenes SA-Passwort hat. Das SA-Kennwort steht zudem öffentlich in der erwähnten Anleitung.

Warum ist das ein Problem?

Der SQL Server-Dienst läuft im Systemkontext. Alle Aktionen, die über ihn ausgeführt werden, haben daher potentiell Windows-Admin-Rechte. Die installierte SQL-Server-Instanz heißt auch auf jedem System gleich und der Kunde wird angeleitet den nötigen Port in der Firewall freizugeben. Daher kann jeder drittklassige Hacker sich über die gängigen Ports mit dem SQL Server als SysAdmin verbinden (Instanzname, Name des SA und dessen Passwort sind ja gut dokumentiert).

Damit kann der Angreifer allerlei Schabernack anstellen:

• Er kann alle Daten ändern und löschen.
• Er kann sogar den Gastrechner komplett übernehmen: heimlich oder destruktiv. Dem Angreifer sind im Prinzip keine Grenzen gesetzt.
• Er kann beispielsweise Windows-Benutzer mit Windows-Admin-Rechten anlegen,
• Software aus dem Internet nachladen und installieren oder
• einfach nur zerstörerisch wirken (Festplatten formatieren, …).

Leider ist es für einen Anwender fast unmöglich alle Lücken zu stopfen, weil laut Anleitung der SA für die normale Arbeit der Anwendung genutzt wird. Offensichtlich gibt es kein SQL-Benutzer- und -Rechtekonzept. Ein verantwortungsvoller Admin müsste in der Datenbank selber eine Gruppe mit den nötigen Rechten anlegen. Dazu muss er per Try&Error ausprobieren, welche Rechte auf welche Objekte im laufenden Betrieb mindestens benötigt werden. In der Anwendungsdatenbank "eazybusiness" sind jedenfalls keine Rollen oder Benutzer angelegt und damit auch keine dedizierten Rechte.

Was jetzt?

Weil die oben genannten Angriffspunkte von dem Hersteller ganz unschuldig bereits im Internet kommuniziert wurden, hilft die übliche Geheimhaltung auch nicht mehr weiter. Außerdem machte einer der Geschäftsführer auf meinen sehr ausführlichen Hinweis hin deutlich, dass er seine Firma hier nicht in der Pflicht sieht. Aus seiner Sicht können sie den Admin nicht ersetzen. Das verstehe ich so, dass der Admin des jeweiligen Kunden dafür verantwortlich sei die problematische Installation zu erkennen und Gegenmaßnahmen zu treffen. Als Beispiel wird in der Mail das Ändern des SA-Passwortes genannt. Immerhin wurde daraufhin eine Woche später, am 12.11.2012, ein entsprechender Hinweis in die Anleitung aufgenommen (vorher fand ich das auf deren Web-Seite nur tief vergraben in der FAQ):

Für maximale Sicherheit sollte auf jeden Fall das Standard Datenbankpasswort "[Anm.: Passwort entfernt]" geändert werden.

Außerdem solle – laut dem neuen Hinweis – der Zugriff via Firewall auf bestimmte Clients eingeschränkt werden. Aus meiner Sicht ist das aber eher die minimale Sicherheit, nicht die maximale …

Die Antwort der Firma nötigte mir Respekt vor deren Kunden ab. Nur wenige Admins, die ich kenne, haben die nötigen Kenntnisse, um die minimalen Rechte zu erforschen (z.B. mit Profiler) und zu vergeben. Außerdem ist das Benutzerkonzept des SQL Servers nicht gerade trivial. Ich wäre froh, wenn unsere Kunden alle solche Admins hätten, die mit SQL-Experten mithalten können. Normale Anwender wären damit jedenfalls hoffungslos überfordert.
Anhand der Beiträge in den Foren kann man erkennen, dass aber nicht alle Kunden derartig gut ausgebildete Admins haben, sondern sich sogar für einfache Dinge wie Backups durchwurschteln und bei der Problembeschreibung deren Batches inkl. SA&Passwort ins Forum stellen. Daher dürften diese Kunden vom Anspruch des Herstellers überfordert werden, die Probleme alleine zu erkennen und zu lösen. Ich finde es schade, dass diese Kunden mit den durch die Standard-Installation verursachten gravierenden Sicherheitsproblemen alleine gelassen werden.

Wenn man lange sucht, findet man einzig den Hinweis, wie man das SA-Passwort ändert. Direkt darunter steht übrigens aus welcher Tabelle man die Namen und Passwörter der Anwendungsbenutzer im Klartext auslesen kann, die für die Anmeldung am System genutzt werden. Kein Witz.

Welche Maßnahmen wären aus meiner Sicht für eine minimale Sicherheit des SQL Servers nötig?

• Der Hersteller sollte in der Installation des SQL Server kein festes SA-Kennwort mehr vergeben. Außerdem eine Anleitung veröffentlichen, wie bestehende Kunden die gemischte Authentifizierung nachträglich ausschalten können.
• Wenn für den Admin die Windows-Authentifizierung genutzt wird, dann kann man sich das ganze Theater mit dem öffentlichen SA-Passwort sparen. Alle Batches können wir bisher veröffentlicht werden ohne das Schaden entsteht.
• Außerdem sollten mit der Datenbank die benötigten Gruppen und User bereits angelegt werden oder wenigstens entsprechende Skripte veröffentlicht werden. Die Doku sollte beschreiben, wie man einen Windows-Benutzer für die Anwendung im SQL Server anlegen kann, dass der Zugriff möglich ist. Dann muss kein SQL-SysAdmin für den laufenden Betrieb genutzt werden.

Als Kür käme dann noch ein echtes Benutzerkonzept mit einer dedizierten Rechtevergabe. Offenbar gibt es schon die Möglichkeit im System Benutzer anzulegen. Wenn die Benutzer nur auf Views zugreifen dürften, die deren Rechte gegen eine Rechtetabelle prüfen, dann wäre das nochmal erheblich näher an einem sicheren System.

Warum reicht es nicht aus, einfach nur das SA-Passwort zu ändern?

Der Anwender startet die Anwendung bei sich lokal auf dem PC. Wenn die Anwendung generell mit SysAdmin-Rechten arbeitet, dann kann man mit idiotensicheren Werkzeugen das Passwort des SA ausspähen. (Nein, eine Anleitung werde ich nicht geben.)
So (oder, falls er es umständlich mag, mit einer der üblichen Injection-Attacken) könnte ein Mitarbeiter den Server übernehmen oder einfach nur löschen. Das gilt freilich auch für Remote-Angriffe via Trojaner oder präparierte Webseiten.
Aber auch das ist nicht wirklich nötig, weil die Zugangsdaten (ODBC-DSN, User und Passwort) in der Registry unter HKCU gespeichert werden, immerhin leicht verschlüsselt. Ich habe kurz überlegt, ob ich mal mit einem API-Tracer schaue, ob ich sehe, welche Methoden genutzt werden, aber dazu hatte ich dann keine Lust, weil es einfachere Möglichkeiten gibt…

Welche Sofortmaßnahmen wären für betroffene Nutzer sinnvoll?

Ein Nutzer ohne tiefe SQL-Kenntnisse hat in meinen Augen keine Chance das System effektiv abzusichern. Daher sollte er sofort den SQL Server-Dienst deaktivieren, bis es eine ausführliche Anleitung gibt, wie der Kunde den SA disablen und Windows-Authentifizierung nutzen kann. Dazu kann man unter "Dienste" auf den Dienst "SQL Server (JTLWAWI )" rechtsklicken und in den Eigenschaften den Starttyp "Deaktiviert" konfigurieren.

Wenn er SQL-mäßig fit ist, dann muss er wenigstens den SA disablen (oder umbenennen oder gigantsich langes Passwort geben) und andere SQL-Benutzer anlegen, die nur die Werte in den benötigten Tabellen ändern dürfen, nicht aber Admin-Rechte haben (auch nicht DBO). Sie müssen auch sehr lange PAsswörter haben, um Brute-Force-Attacken zu bestehen (>20 Zeichen). Dazu ist der Einsatz des SQL Server Management Studio Express zu empfehlen. Besser sollte er die Vollversion des SQL Servers kaufen, dann kann er mit dem SQL Profiler die Anwendung aufzeichnen und dann damit die benötigten Rechte erforschen. Dabei könnte es man bemerken, dass manche Funktionen nicht klappen, falls diese doch SysAdmin-Rechte benötigen.

Wer rettet die unkundigen Betroffenen?

Der Download der Software ist frei. Es ist Freeware, aber offenbar nicht Open Source. Was heißt das in Bezug auf Sicherheit? Einem geschenktem Gaul schaut man nicht ins Maul?
Wer sich fragt, wovon die Firma lebt, wenn sie die Software verschenken: Sie verkaufen Zusatzmodule unter dem Motto "Professionelle Softwarelösungen für Ihren Erfolg im E-Business". Den Spruch finde ich unter den gegebenen Umständen beachtlich.

Naja, durch den kostenlosen Download kann das immerhin jeder von Euch selber nachschauen. Bei dem Paket "JTL-Wawi-Full" wird die SQL Server 2005 Express Edition mit besagter Konfiguration mitgebracht, seltsamerweise nicht die Ausgabe mit erweiterten Diensten (also mit Management Studio Express). Wer sich Lorbeeren verdienen möchte, kann ja mal erforschen, was zur tatsächlichen "maximalen Sicherheit" nötig wäre und die Skripten dort im Forum veröffentlichen. Es schaut nicht so aus, als ob die Firma das machen würde. Wobei mir unklar ist, warum sie die Situation so gelassen sehen. Meine Warnung hat daran nur wenig geändert.

Freiwillige vor… Das wäre auf jeden Fall eine gute Tat.

Wer sich für den SQL Server 2012 interessiert, der sollte das kostenlose eBook "Introducing Microsoft SQL Server 2012" mal anschauen. Erhältlich als PDF, mobi und epub (und damit auch für den Kindle geeignet).

Als bei unseren Kunden Probleme mit der Passwortlänge auftraten, konnte ich es kaum glauben: Angeblich gab es Probleme, weil die Passwörter unserer Funktionsbenutzer am SQL Server zu lang waren. Dazu muss man wissen, dass der SQL Server die am Server eingestellten Windows-Passwort-Policies berücksichtigt.

Tatsächlich findet eigentlich auch Microsoft, dass lange Passwörter besser sind als kurze. Dennoch hat Microsoft dokumentiert, dass die Installation des "Office 365 Integration Module (OIM)" die am Server eingestellten Passwort-Policies ungefragt verändert. Anschließend dürfen Passwörter maximal 16 Zeichen lang sein. Daher gab es bei unseren Kunden Probleme, weil für unsere Anwendungen vor Ort grundsätzlich längere Passwörter generiert werden. Längere Passwörter verstoßen aber gegen die durch Office 365 erzwungenen vereinfachten Passwort-Regeln. Microsoft drückt es im Artikel "What should I know about password policies?" so aus:

Note
If you install the Office 365 Integration Module (OIM), the OIM configuration wizard enforces the Strong password policy, and updates the policy to include the following requirements:

* Passwords must contain 8–16 characters.

* Passwords cannot contain a space or the Office 365 email name.

Das klingt nicht weiter spektakulär. Man muss schon verstehen, was gemeint ist:

• Die besonders erwähnte "strong password policy" ist ohnehin schon Default. Das steht jedenfalls im gleichen Dokument. Das könnte man also als Nebelkerze betrachten.
• Mit "8-16 characters" ist gemeint: mindestens 8, aber höchstens 16 Zeichen.

Die Regeln werden also aus Kundensicht unsicherer. Leider kann man die Regeln offenbar danach nicht wieder manuell verändern und auch lange Passwörter erlauben. Laut Microsoft ist das ein Feature, kein Bug.

Unglaublich? Aber wahr.

Ein Kollege machte mich schon vor Wochen auf das kostenlose Werkzeug "SQL Monitor" bei Codeplex aufmerksam. Ich glaube, es war Robert. Es wurde für Performanceanalysen konzipiert und macht einen brauchbaren Eindruck. Leider werde ich wohl sobald nicht dazu kommen, es auszuprobieren. Damit ich den Link wieder finde, setze ich es hier mal als Merker für mich und alle Interessierten.

Als ich erstmals mit dem SQL Server Management Studio 2012 arbeitete bemerkte ich gleich, dass nun viel mehr Funktionen angeboten werden, sie auch andere Tastenkombinationen nötig machten. Einen Überblick bietet Microsoft hier.

In unserem Kulturkreis sind es immer 3, 7 oder 10 Dinge, die jemand zu sagen hat. Heute möchte ich auf den Artikel "The Seven Sins against TSQL Performance" aufmerksam machen. Die von Grant Fritchey genannten Punkte sind alles Klassiker, die schon viel Leid und Elend verursachten. Ein Lese-Tipp für angehende SQL-Server-Experten.

Wer hat an der Uhr gedreht, …?

Schon wieder ging ein Monat ins Land und die nächste Vortrag im Rahmen der SQL-PASS Franken steht an. Das Thema finde ich sehr interessant, weil ich zwar viele kenne, die sich dafür interessierten, aber ich kenne nur sehr wenige, die sich dann für den Einsatz entschieden und echte Praxiserfahrungen haben: "CLR Integration im SQL Server". Referent ist Stefan Bechtloff. Er dürfte den "Regulars" bekannt sein.

Hier die Details im O-Ton:

Bereits seit der Version 2005 existiert die Möglichkeit .Net Programmierung im Microsoft SQL Server zu verwenden. Die CLR-Komponente (Common Language Runtime) bildet das Kernstück von Microsoft .NET Framework und stellt die Ausführungsumgebung für den gesamten Code in .NET Framework bereit.

Bisherige Performance Aspekte hielten Unternehmen davon ab, die CLR Integration zu forcieren. Durch die verbesserte Integration im SQL Server 2012 öffnen sich neue Konzepte und Möglichkeiten den SQL Server noch besser in den Entwicklungsprozess zu integrieren. CLR Datentypen, CLR Trigger, CLR Functions und CLR Strored Procedures werden an praxisnahen Beispielen veranschaulicht. Lösungen bekannter Probleme im SQL Server wie Prüfung mit regulären Ausdrücken oder Export von Daten werden vorgestellt.

Die Teilnehmer des Vortrages erhalten einen umfassenden Einblick in die CLR Integration des SQL Servers und gehen mit neuen Ideen und Lösungsansätzen nach Hause.

Referenten Information
Stefan Bechtloff – Senior Consultant von New Elements GmbH – berät und unterstützt seit vielen Jahren Unternehmen beim Aufbau von Lösungen mit dem SQL Server und .NET – von der Architekturvorgabe bis hin zur Implementierung.
Der Diplom-Informatiker nutzt dabei sowohl die technologischen Möglichkeiten der .NET-Plattform als auch den SQL Server.

Termin: Dienstag, 16.10.2012, ab 18:30 bis ca. 20:30 (danach bitte etwas Zeit für das Essen danach einplanen)

Veranstaltungsort: New Elements GmbH
Thurn-und-Taxis-Straße 10, D – 90411 Nürnberg
(Alcatel-Lucent Gebäude im Nordostpark)
Kostenfreie Parkplätze sind direkt vor der Tür vorhanden.

Der Eintritt ist wie immer kostenlos, man muss auch kein Mitglied sein oder werden.
Wegen der Raumplanung ist eine kurze Info an die Regionalleiter der SQLPASS Franken wichtig.
Interessierte bitte daher formlos bei Tillmann Eitelberg (tei@sqlpass.de) oder Michael Deinhardt (mde@sqlpass.de) per Mail oder via Xing anmelden.
(Es geht – wie immer – dabei nur darum abzuschätzen, wie viele in etwa kommen, damit genügend Stühle da sind.)

SQL-PASS ist eine von Microsoft unabhängige SQL-Server-User-Group. Daher muss man auch keine Angst haben, dass man irgendetwas angedreht bekommt. Es gibt mehrere Regionalgruppen, unsere fränkische ist meines Wissens die Größte in Deutschland. Mehr Infos hier: www.sqlpass.de

In den letzten Monaten kamen – nach langer Pause – mal wieder zwei Security-Fixes für das Paket "SQL Server". Sie betrafen tatsächlich aber nicht die DAtenbank-Engine, sondern die Werkzeuge außen rum:

Im August wurden im Bulletin MS12-60 eine Reihe von Patches veröffentlicht, die durch einen Fehler in den "allgemeinen Windows-Steuerelementen" aus Office 2003 (KB2687323) und Office 2008 (KB2687441) verursacht wurden. Hier wurde jeweils eine "Remote Code Execution" beseitigt. Offensichtlich werden sie in den älteren Versionen des SQL Servers benutzt, vermutlich im SQL Server Management Studio. SQL Server 2012 ist nicht betroffen.

Im Oktober wurden im Bulletin MS12-70 Patches für alle SQL Server-Versionen veröffentlicht. Hier ist der Fehler in den "SQL Server Reporting Services". Durch den Fehler kann eine "elevation of rights" verursacht werden. Möglicherweise kannte man den Service durch einen Buffer-Overflow oder eine ähnliche Lücke dazu bringen eigenen Code auszuführen.

In Kooperation mit Microsoft findet nächsten Freitag, 03. August vom 9 bis 13 Uhr eine Infoveranstaltung von ppedv zum Thema „Neuerungen in SQL Server 2012“ direkt bei Microsoft in Unterschleißheim statt. Es gibt zwei Vorträge zu je 90min:

• Die wichtigsten Neuerungen in der SQL Server 2012 Datenbank Engine
• Neuerungen in der Abfragesprache Transact SQL und Volltextsuche

Leider steht da nicht, wer der Referent ist: Andreas Rauch von ppedv. Ich kenne ihn nicht, aber die Themen klingen sehr gut. Vor allem, weil es diesmal nicht um BI, sondern um den SQL Server und dessen Kern geht. Klasse.

Die Teilnahme ist kostenlos, aber die Plätze sind begrenzt. Details zum Inhalt und Registrierung bei ppedv.de.

Update 7.8.2012: ppedv antwortete auf meine Anfrage. Der Referent beider Vorträge ist Herr Andreas Rauch von ppedv AG. (oben ergänzt)