Der unnütze, schreckliche Prozessorfehler und SQL Server Deployments

– fast alles, was man wissen muss

Von Allan Hirt, 4. Januar 2018

Übersetzung aus dem Englischen, mit freundlicher Genehmigung von Allan Hirt. Hier finden Sie den Original-Artikel: http://sqlha.com/2018/01/04/no-good-terrible-processor-flaw-sql-server-deployments-nearly-everything-need-know/

Falls ihr es noch nicht erfahren habt: erst vor kurzem wurde ein ernster Sicherheitsfehler in fast jedem Prozessor, der in den letzten 10 Jahren hergestellt wurde, entdeckt. Anfänglich dachte man, es träfe nur auf Intel zu, doch jetzt scheint es jeden zu treffen. Offizielle Reaktionen:

AMD (spielen das Problem runter)
ARM (tolle Reaktion)
Intel (oh je)

Es gibt zwei Defekte, bekannt unter den Namen Meltdown und Spectre. Im IT-Magazin „The Register“ gibt es einen tollen zusammenfassenden Artikel – so muss ich es nicht erst wiederkäuen. Dies ist ein Hardware-Problem – nichts außer neuen Chips wird es entfernen. Dennoch, so ziemlich jeder, der ein OS, Hypervisor oder Software geschrieben hat, hat Patches (oder wird sie haben), die diesen Fehler hoffentlich eliminieren werden. Dieser Blogbeitrag behandelt physische, virtualisierte und Cloud-basierte Deployments von Windows, Linux und SQL Server.

Die Tatsache, dass jeder Anbieter schnell damit umgeht, ist eine gute Sache. Das Problem? Die Performance wird höchstwahrscheinlich beeinträchtigt. Niemand kennt das Ausmaß, besonders bei SQL Server Workloads. Man wird alle Erwartungen/Performance SLAs testen und neueinstellen müssen. Man wird neue Baselines und Benchmarks brauchen. Hierin liegt etwas Ironie, da es scheint, dass virtualisierte Workloads höchstwahrscheinlich den größten Erfolg haben werden gegenüber denen auf physischen Deployments. Nur die Zeit wird es zeigen – niemand weiß es bisher.

Was müsst ihr machen? Trödelt nicht herum oder steckt den Kopf in den Sand in der Ansicht, dass ihr nichts machen müsst und ihr sicher seid. Wenn ihr in den vergangenen 10-15 Jahren etwas installiert habt, wird es wahrscheinlich gepatcht werden müssen. Punkt. PATCHT ALLES! Denkt jedoch daran, dass es neben diesem riesigen Bereich so ziemlich eine Garantie gibt – selbst auf Linux – dass man eine Downtime im Zusammenhang mit Patching haben wird.

Untenstehend ist eine Liste, die die größten Akteure für SQL Server-bezogene Deployments – physisch, virtualisiert und Cloud – zusammenfasst. All diese Links zu finden, hat etwas gedauert, deswegen habe ich mir gedacht, dass ich sie an einen für jedermann leicht zugänglichen Ort stellen sollte. Jeder Anbieter und jedes Produkt haben ihre eigene Handlungsempfehlung und Reaktion, und inzwischen kann es auch Updates zu dem geben, was ich gepostet habe, aber dies sollte euch erstmal einen Einstieg geben. Was ich nicht mit aufgelistet habe, sind die Hardware-Anbieter. Fragt bei Dell, HP, Hitachi etc. nach, um zu sehen, ob es da auch Firmware/BIOS/UEFI Updates gibt.

Wenn ihr Hilfe bei den neuen Baselines und Benchmarks braucht, oder einfach Hilfe dabei, bei dem allem durchzublicken und einen Plan zu entwickeln, kontaktiert uns. Wenn ihr auf einer älteren, nicht unterstützten Version einer der untenstehenden Dinge lauft, die nicht gepatcht werden, solltet ihr ernsthaft daran denken, eure Upgrade-/Migrationspläne zu beschleunigen. Das ist auch etwas, wobei wir euch helfen können.

AWS

Wenn ihr eure Workloads bei Amazon Web Services laufen lasst, kann ihre Antwort hier gefunden werden. Es scheint, dass ihr Zeug repariert worden ist, aber wenn ihr IaaS VMs mit EC2 laufen habt, werdet ihr eure Betriebssysteme und die Software darin patchen lassen müssen.

Azure

Die Antwort von Microsoft für Azure-Kunden findet ihr hier. Sie haben einen KB-Artikel (4073235) verfasst, der hier steht. Wie auch AWS, haben sie alles grundlegende Zeug gepatcht. Wenn ihr IaaS VMs laufen habt, müsst ihr sicherstellen, dass sie ordentlich gepatcht sind, es sei denn, ihr habt automatisches Patching und Windows Server laufen (siehe unten).

GCP

Wenn ihr Google Cloud für eure Workloads verwendet, ist ihre Antwort hier. Genau wie bei AWS und Azure haben sie sich zwar um die Basis gekümmert, aber ihr seid für eure IaaS VMs/Workloads verantwortlich.

Red Hat Enterprise Linux

Red Hats Antwort steht hier und spricht mehr die Auswirkung und Performance an. Um die Patching-Seite der Medaille zu verstehen, empfehle ich euch diesen Link. SQL Server wird auf 7.3 oder später unterstützt, und für diese Builds sind Patches verfügbar (obwohl ich zum Zeitpunkt des Schreibens dieses Beitrags nicht 7.4, sondern nur 7.3 sah).

Zum Zeitpunkt des Schreibens dieses Blogbeitrags wurde die „kostenlose“ Version von RHEL, CentOS, die viele für Nicht-Produktionsumgebungen oder zum Testen verwenden, noch nicht repariert, aber sollte sie bald.

SQL Server

Microsoft hat einen tollen KB- (4073225) Artikel verfasst, der eure Optionen hier zusammenfasst. Microsoft ist dabei, SQL Server 2008 und später zu patchen, aber die Realität ist, da SQL Server 2005 technisch auf Windows Server 2008 und 2008 R2 laufen kann, wäre er betroffen, aber wird nicht mehr unterstützt. Ich sehe nicht, dass Microsoft irgendetwas dafür tut. Dies wäre ein guter Zeitpunkt zu überlegen, wann ihr ein Upgrade oder eine Migration plant.

Microsoft führt fünf Szenarien in der KB auf. Bitte lest sie aufmerksam und trefft die richtige Wahl.

SLES

Wenn ihr SLES für euer SQL Server Deployment verwendet, kann ihre Information hier und hier gefunden werden (KB). Es scheint, dass sie 11 SP3-LTSS bis einschließlich 12 SP3 repariert haben. Wenngleich sie nicht offiziell für SQL Server unterstützt werden, kann die OpenSUSES-Info hier gefunden werden.

Ubuntu

Hier ist Ubuntus Antwort. Zum Zeitpunkt des Schreibens dieses Blogbeitrags hatten sie noch keine Patches veröffentlicht, aber sobald sie es tun, werden sie auf Ubuntus Sicherheitsbulletin erscheinen.

VMware

VMware hat eine Sicherheitsankündigung gepostet, was dieses Thema betrifft, sowie einen Blogbeitrag. Wenn ihr also ESXi als euren Hypervisor verwendet, müsst ihr es lesen. Zum Zeitpunkt des Schreibens dieses Blogbeitrags sieht es aus, als haben sie ESXi 5.5, 6.0 und 6.5 repariert. Es sieht nicht aus, als ob sie was, das älter als 5.5 ist, reparieren werden.

Beachtet auch dies. Zumindest zum Zeitpunkt des Schreibens dieses Blogbeitrags bekommt 5.5 nur ein Patch für CVE-2017-5715, aber nicht CVE-2017-5753. Das bedeutet ganz klar, dass ESXi 5.5 immer noch teilweise angreifbar bleiben wird. Ich weiß nicht, ob VMware vorhat, dies in Zukunft anzugehen, aber falls nicht, solltet ihr wirklich überlegen, auf 6.0 oder später upzugraden oder zu migrieren. Das solltet ihr so oder so tun, da 6.0 die erste Version von ESXi ist, die vMotion von geclusterten SQL Server Konfigurationen unterstützt.

Windows Server

Ähnlich wie bei SQL Server hat Microsoft einen KB-Artikel (4072698) zu diesem Thema geschrieben, der hier zu finden ist. Zum Zeitpunkt des Schreibens dieses Blogbeitrags hat Microsoft Patches für Windows Server 2008 R2, 2012 R2, 2016 und RS3 (AKA 1709) veröffentlicht. Hoffentlich werden 2008 und 2012 auch bald Patches bekommen. Wenn ihr automatisches Updaten aktiviert habt, sollten die Fixes von Windows Update aufgegriffen werden. Falls nicht, müsst ihr sie manuell ausführen. Wenn ihr noch auf Windows Server 2003/R2 oder früher lauft – ich sehe nicht, dass Microsoft soweit mit dem Patchen zurückgeht. Da seid ihr auf euch gestellt. Die Schadensminderung wäre, SO BALD WIE MÖGLICH auf etwas upzugraden, das gepatcht wird. Wenn ihr 2008 oder 2012 laufen habt und Microsoft keinen Patch veröffentlicht, empfehle ich euch dringend, darüber nachzudenken, eure Deployments auf etwas, das gepatcht wird, upzugraden/zu migrieren.

Weitere Informationen zum Patch vom 3. Januar kann in der KB 4072699 gefunden werden. Beachtet, dass ihr das Patch eventuell aufgrund von einigen Anti-Virus-Anbietern – es sei denn, die Registrierung wird verändert – nicht automatisch sehen werdet.

XEN

Wenn ihr XEN als euren Hypervisor verwendet – sie haben auch Zusammenfassung erstellt. Es sieht im Moment nicht so rosig für sie da aus, da sie (zum Zeitpunkt des Schreibens dieses Blogbeitrags) noch nicht für alles Patches zu haben scheinen. Ich bin sicher, dass sich das ändern wird.

Andere

Apple – Wenn ihr High Sierra, Sierra oder El Capitan laufen habt, sieht es danach aus, dass sich Apple schon im Dezember 2017 darum gekümmert hat. Hier gibt es weitere Informationen dazu.

Browsers

Chrome – Es sieht danach aus, dass Google später im Januar ein Patch für Chrome herausgeben wird. Hier ist der Link für weitere Informationen.
Firefox – Version 57 oder später hat die richtigen Fixes. Lest diesen Blog für weitere Informationen, also patcht mal los!
Edge und Internet Explorer – hier gibt es einen Blogbeitrag von Microsoft. Es sieht danach aus, dass das Sicherheitsupdate (KB4056890) vom Januar das bereits erledigt. Wenn ihr als einen dieser Browser benutzt, aktualisiert bitte eure Betriebssysteme so bald wie möglich.