Sonntag, 25. Februar 2018
Twitter Facebook Mister Wong Delicious stumbleupon digg Yahoo

Neueste Technologie für Administratoren

Systembetreuer im Windows-Umfeld brauchen Know-how über die neuesten Entwicklungen. Einsatzbeispiele und Tipps aus der Praxis führen zu mehr Effizienz im täglichen Betrieb. Wir bieten Skript-basierte Lösungen von Windows IT Pro exklusiv im deutschsprachigen Raum für unsere Abonnenten.

Meltdown – Alptraum der CPU-Entwickler und Administratoren

 Meltdown“ macht sich konzeptionelle Schwachstellen im CPU-Design zu Nutze. Um die Performance zu erhöhen, rechnen nicht genutzte CPU-Ressourcen („freie“ Register) schon einmal mit den Daten, die vermutlich bald benötigt werden. Das Vorgehen weist allerdings unerwünschte Seiteneffekte auf. Denn mit der „out-of-order execution“ werden die bereits angesprochenen Daten (die vorsorglich in den Cache geladen wurden) ausgelesen.

Selbst wenn die korrespondierenden Speicheradressen eigentlich vor dem Zugriff (durch den „Kernel-Modus“) geschützt sein sollten, gelingt es Daten direkt aus den Registern und dem Cache Abfließen zu lassen. Besonders gefährdet sind dabei virtuelle Systeme von Cloud-Providern. Schließlich „laufen“ auf einem Server unter Umständen VMs von dutzenden unterschiedlichen Mietern – ein perfektes Ziel für Hacker.

Für eine effiziente und funktionierende IT-Systemsicherheit sind unterschiedliche Punkte zu beachten. Auf den „höheren“ Schichten (etwa dem Betriebssystem-Level oder der Anwendungsschicht) tauchen immer wieder Sicherheitslücken in Softwarekomponenten auf, die mit entsprechenden Hotfixes und Patches wieder „gestopft“ werden müssen. Auch die Benutzer selbst sorgen immer wieder dafür, dass Hacker und deren Schadsoftware Dateien oder sensible Informationen „entwenden“ können – etwa durch allzu bereitwilliges Anklicken von E-Mail-Anhängen.

Auf den unteren Schichten des OSI-Modells (etwa der Transport- oder Vermittlungsschicht) sorgen bestimmte Mechanismen dafür, dass Datenpakete im Netzwerk auch genau an dem Ziel ankommen, für das sie bestimmt sind. Je weiter man sich von den Anwendungen und Betriebssystemen „nach unten“ bewegt, desto schwieriger wird es Fehler zu erkennen und entsprechende Gegenmaßnahmen einzuleiten. Das gilt für die Systembetreuer als auch für die Entwickler und Hersteller von Hardware, Firmware und Software gleichermaßen. Denn falls sich eine ausnutzbare Sicherheitslücke in der Gerätefirmware befindet, wird es für die darüber liegenden Sicherheitsmechanismen (etwa eine Firewall oder eine Endpoint-Virenschutz) schwer oder unmöglich, diesen zu erkennen.

Besonders im Bereich der IT-Kernkomponenten (CPU, RAM, Mainboard, Speichermedien) müssen sich die IT-Sicherheitsbeauftragen darauf verlassen können, dass diese Systeme „sicher“ sind. Damit dies der Fall ist, müssen beispielsweise bestimmte Dateien in den unterschiedlichen Speicherbereichen voneinander zu isoliert werden. Sprich wenn mehrere Anwendungen, virtuelle Maschinen oder Benutzer auf einem Server arbeiten, dürfen die Dateien von Benutzer-01 (oder VM-01 oder Anwendung-01) nicht auch für Benutzer-02 zur Verfügung stehen. Diese Abgrenzung der jeweiligen Speichern Bereiche wird als „memory isolation“ bezeichnet. Dazu zählen etwa Hauptprozessor-Caches (meist Level 1 bis Level 3), Hauptspeicher (oftmals DRAM) sowie die Massenspeichermedien (etwa mechanische Festplatten oder Solid State Drives). Nun hat sich allerdings herausgestellt, dass die Hardware-gestützte Implementierung einer kompletten „memory isolation“ auf sehr vielen CPUs fehlerhaft ausgeführt ist.

Probleme beginnen bei der CPU

Um die Probleme bei der fehlerhaften Implementierung zu verstehen, ist es zunächst wichtig, sich über einige Punkte in Bezug auf die Ansteuerung von CPUs durch das Betriebssystem vertraut zu machen: Nur bestimmten Teiles des Betriebssystems (meist der namensgebende „Kernel“) ist es erlaubt, direkt auf die Hardware zuzugreifen. Die restlichen Softwarekomponenten, Programmen und Benutzerkonten können somit nicht direkt auf die Hardware einwirken. Damit die Programme die Illusion eines direkten Speicherzugriffs erhalten, setzen moderne Betriebssysteme etwa Funktionen wie einen HAL (Hardware Abstraction Layer) sowie entsprechende Speichervirtualisierungen ein. Auf diese Weise „gaukelt“ das OS den jeweiligen Programmen vor, sie würden Zugriff auf den Hauptspeicher (oder den CPU-Cache oder das CPU-Register erhalten).

Um eine „saubere“ Trennung der jeweiligen Daten sicherzustellen, arbeiten CPUs in zwei (oder mehreren) unterschiedlichen Modi. Hier sind zum einen der „Kernel-Modus“ und zum anderen der „User-Modus“ zu nennen. Bestimmte Prozessor Architekturen (etwa Intel x86) verfügen über weitere Modi. Diese werden beispielsweise als Ring0, Ring1, Ring2 und Ring3 bezeichnet. Bei diesem Beispiel entspricht „Ring0“ dem „Kernel-Modus“ und Ring3 wird als User-Modus verwendet. Ring1 und Ring2 werden dabei nicht unbedingt vorausgesetzt – um die Kompatibilität von Betriebssystemen sicherzustellen, die „nur“ zwei Modi unterstützen. Bei Virtualisierungs-Lösungen kommt dagegen oftmals Ring1 zum Einsatz, und zwar als „Kernel-Modus“ für die Gastsysteme, während Ring0 für den Kernel-Modus des Hypervisors vorgesehen ist. Ring3 kommt dann wieder für den User-Modus (Anwendungen auf der VM) zum Zuge. Seltener kommt Ring2 zum Einsatz, etwa werden unter OS/2 die Grafiktreiber an dieser Stelle betrieben.

Durch diese Vorgehensweise können die Informationen voneinander isoliert werden. Möchte nun eine Anwendung Zugriff auf einen bestimmten Speicherbereich, erhält die Software diesen. Allerdings wird dabei nur Zugriff auf einen entsprechenden Zeiger (wie bei einer Verknüpfung) gewährt, und nicht auf den physikalischen Speicherbereich. Auf diese Weise kann – dank dem Betriebssystem – sichergestellt werden, dass kein Prozess Daten auslesen kann, die nicht entsprechend freigegeben wurden. Wechselt die CPU nun von einem Modus in den anderen, geht etwas Zeit verloren. Ständige Wechsel (sogenanntes Kontext-Switching) hat dramatische Auswirkungen auf die CPU-Performance. Daher sind die Entwickler (hoffentlich) bestrebt, diese Wechsel möglichst gering zu halten.

Der jeweilige Status der einzelnen Speicherbereiche wird durch einen entsprechenden Schalter („CPU mode bit“) festgelegt. Ist das nicht Bit gesetzt (entspricht dem Wert „Null“), kann der jeweilige Bereich nicht ausgelesen werden (Kernel-Mode), ist das Bit dagegen gesetzt (Wert „Eins“) kann der Speicherbereich ausgelesen werden (User-Mode). Das Bit kann dabei nur verändert werden, wenn sich die CPU im Kernel-Modus befindet.

Viele CPUs (beinahe alle Modelle seit 2010) verfügen über eine spezielle Funktion, die bestimmte Dateien bereits in den Speicher laden, bevor diese benötigt werden. Daher lesen die betroffenen CPUs bereits Daten aus, die in den nächsten Augenblicken (vermutlich) für die Berechnungen nötig sind. Auf diese Weise befinden sich die Daten schon in der Pipeline, weitere Ladezeiten lassen sich vermeiden. Lädt die CPU allerdings Daten, die im Nachhinein nicht zum Zuge kommen, können diese einfach überschrieben werden.

Dank ausgefeilter Vorhersage-Algorithmen landen allerdings mit hoher Wahrscheinlichkeit Daten im CPU-Cache, die tatsächlich für die nächsten Rechenschritte wichtig sind. Dies wird vor allem durch die hohe Parallelität aktueller Systeme ermöglichst, so können quasi alle nicht benötigten Register und Cache-Bereiche der CPU-Cores für diese Vorhersagemethode eingesetzt werden. Sprich wenn drei Threads auf einer CPU mit acht virtuellen Kernen laufen, können bis zu fünf Cores für diese Technik eingesetzt werden. Und genau diese Technik nutzt die „Meltdown-Angriffsmethode“ aus. Das perfide daran: „Meltdown“ greift nicht etwa auf eine Sicherheitslücke von Softwarekomponenten, wie fehlerhafte Anwendungen oder unsauber programmierten Teiles des Betriebssystems zu, sondern attackiert direkt die CPU-Funktionen. Daher wird prinzipiell fast jedes System angreifbar. Egal ob auf dem System ein Linux- oder Windows-Betriebssystem läuft, oder ein Hypervisor installiert ist: Diese Sicherheitslücke lässt sich quasi „universell“ ausnutzen.

Meltdown – Konzept des Angriffs

Mit Meltdown lassen sich konzeptionelle Schwachstellen in vielen CPU-Generationen ausnutzen. Dazu bedienen sich die Angreifer eines speziellen Tricks. Bei der „out-of-order execution“ werden die bereits angesprochenen Daten, die vorsorglich in den Cache geladen werden direkt „abgegriffen“. Denn die „freien“ CPU-Ressourcen rechnen schon einmal mit den Daten, die vermutlich bald benötigt werden. dieses Vorgehen kann allerdings unerwünschte Seiteneffekte aufweisen. Dazu zählen etwa Timing-Probleme, etwa wenn bestimmte Ergebnisse erst zu einem späteren Zeitpunkt für die Berechnungen wichtig sind. Aus der Security-Sicht ist dieses Vorgehen höchst problematisch: Denn die betroffenen CPUs erlauben es, unprivilegierten Prozessen (die sich eigentlich im User-Modus befinden) Code aus privilegierten Bereichen der CPU (die sich im Kernel-Modus befinden) zeitweise in einen anderen CPU-Register zu laden.

Mit den passenden CPU-Kommandos lassen sich so die Cache-Inhalte in den Hauptspeicher oder auf den Massenspeicher kopieren, und beispielsweise auch per Netzwerk an ein System außerhalb des Unternehmensnetzwerks übertragen. Zwar befinden sich (aufgrund der Cache-Größe) meist nur sehr wenige Datenmengen im Zugriff des jeweiligen Registers, dennoch lassen sich Datenraten von etwa 500 KByte/s erreichen. Die Attacke wird in drei Schritten durchgeführt:

  • Erstens: Der (geschützte) Inhalt einer bestimmten Speicheradresse wird in ein „freies“ CPU-Register geladen. Der Angreifer ruft dabei eine beliebige Speicheradresse ab, in der geheimer Inhalt vermutet wird.
  • Zweitens: Dank eines Befehls wird ein kurzfristiger Zugriff auf den geheimen Inhalt des Registers ermöglicht, unter anderen die korrespondierende  Cache-Speicheradresse.
  • Drittens: Die Angreifer setzten die CPU-Funktion „Flush+Reload“ ein, um die Cache-Einträge zu identifizieren und die passende physikalische Speicheradresse auszulesen.

Nun lässt sich der Inhalt des Registers einsehen. In der Regel erhält der Angreifer dabei einen Teil der gewünschten Informationen. Danach wird dieser Vorgang wiederholt, bis die benötigten Daten in Erfahrung gebracht wurden.

Fazit

Dank „Meltdown“ sehen sich die Angreifer in der Lage, Systeme zu kompromittieren, die memory isolation aufzubrechen, Daten auszulesen und auf diese Weise an sensible Informationen wie etwa Kennwörter oder Kreditkartendaten zu kommen. Besonders problematisch wird es, wenn auf einer physikalischen Maschine (etwa ein größerer Server für Container oder VMs) sehr viele unterschiedliche Mandanten und Instanzen laufen. Teilen sich beispielsweise 20 Kunden eines Cloud-Providers die „selbe“ Hardware, können die Informationen aller „Nachbarn“ ausgelesen werden. Bei Einzelsystemen, auf denen sich nur ein einziges Betriebssystem befindet ist die Gefahr meist deutlich geringer.

Schließlich müssten die Angreifer ja zunächst für einen Zugriff sorgen, und in diesem Fall lassen sich die Informationen vermutlich auch gleich aus dem System auslesen. Das perfide bei dieser Methode ist sicherlich, dass sehr viele Systeme auf diese Weise angreifbar sind, unabhängig vom aktuellen Stand der Anwendungssoftware oder des eingesetzten Betriebssystems. Inzwischen werkeln unterschiedliche Hersteller allerdings bereits an entsprechenden Gegenmaßnahmen, etwa die Mainboard-Hersteller (Firmware-Upgrades), Antiviren-Software-Hersteller und Microsoft (Patch für Windows 7, 8, 8.1 und 10).

Besonders gefährdet sind daher virtuelle Server, die über Cloud-Provider bereitgestellt werden. Denn oftmals werden sehr viele VMs auf größeren Servern (oder Clustern) betrieben. Somit genügt es, wenn der Angreifer eine VM-Instanz bei einem Provider bucht, und von diesem System aus den Meltdown-Angriff startet. Auf diese Weise lassen sich (beinahe) alle Daten der anderen Kunden auslesen – vorausgesetzt deren VMs „laufen“ auf demselben physikalischen Server.

Ein Virenschutz in einem solchen Gastsystem hat somit keine Chance, diese Zugriffe festzustellen. Falls der Angriff allerdings auf einer Maschine mit nur einem Betriebssystem gestartet wird (etwa physikalischen Server oder einem Client), stehen dagegen bereits Erkennungsmethoden zur Verfügung. Somit lässt sich die Gefahr schon einmal eingrenzen. Auch müsste der Angreifer zunächst einmal Zugriff auf die Server erlangen, wenn Systeme im Rechenzentrum eines Unternehmens direkt angegriffen werden soll. In diesem Fall wäre es für die Hacker sicherlich leichter, die Daten „konventionell“ (sprich mit entsprechender Malware) auszulesen.

Florian Huttenloher

Diesen Artikel bewerten
  
 4.23 (9 Bewertungen)
Kommentare
Anmelden
Anmelden