Meltdown und Spectre: Die Auswirkungen von Prozessor-Bugs auf die Sicherheit des IoT

Einführung

Bisher wurde die Systemsicherheit sowohl von der Unternehmensleitung als auch von einzelnen Mitarbeitern stets als eine Angelegenheit betrachtet, die nur für den IT-Bereich relevant ist. So wurde dieser Aspekt innerhalb von Embedded-Systemen oftmals nicht ernst genug genommen. Aufgrund der explosionsartigen Zunahme der Nutzung des Internet der Dinge („Internet of Things“, IoT) und der Tatsache, dass Embedded-Systeme in sicherheitskritischen Anwendungen immer wichtiger werden, ändert sich diese Ansicht inzwischen schnell. Vor Augen geführt wurde dies der Öffentlichkeit im vergangenen Jahr durch die Mirai-Malware, welche digitale Videorecorder und andere internetfähige Geräte auf niedriger Ebene infizierte. Bei den Angriffen auf die Geräte ging es nicht darum, die jeweiligen Gerätefunktionen zu beeinträchtigen (diese funktionierten normal weiter). Vielmehr sollten zunächst weitere Geräte identifiziert und infiziert werden, um dann eine große Anzahl infizierter Geräte als Startplattformen für Distributed-Denial-of-Service-Angriffe zu verwenden und Webhost-Webseiten lahmzulegen oder zumindest drastisch zu verlangsamen. Da viele dieser Recorder und die mit ihnen verknüpften Kameras Teil eines Sicherheitssystems waren, braucht es nicht viel Fantasie, um zu erkennen, dass eine Infektion dieser Geräte auch für andere Zwecke genutzt werden konnte. Mirai und seine Varianten breiteten sich schnell aus, da Millionen von Geräten mit fehlerhaften Sicherheitseinstellungen ausgeliefert wurden, die den gierigen Malware-Programmen praktisch offenen Zugang boten.

Mirai nutzte zum Zugriff auf die Zielgeräte das Internet und das Internetprotokoll, jedoch können auch andere Kommunikationskanäle wie Bluetooth zum Einsatz kommen. IoT-Sicherheitsspezialist Armis hat acht Schwachstellen im Bluetooth-Stack, der die Kommunikation in vielen mobilen Geräten verarbeitet, identifiziert. Das Unternehmen taufte diese Schwachstellen „BlueBorne“. Sie werden in einem anderen Whitepaper zum Thema IoT-Sicherheit erörtert: „Der Kampf mit den Hackern um Bluetooth verschärft sich“

Es wird immer deutlicher, dass es sich bei Hackern nicht mehr nur um sozial minderbemittelte junge Männer handelt, die von ihrem Schlafzimmer aus agieren, sondern um organisierte, technisch äußerst versierte Gruppen. Einige sind kriminelle Gruppen, andere sind Regierungskreisen zuzuordnen. So wird weitgehend akzeptiert, dass Russland eine Reihe unterschiedlicher Cyberwaffen gegen die Ukraine einsetzt, unter anderem, um das Stromverteilungsnetz lahmzulegen. Vielfach werden bei den Angriffen dieser Gruppen Schwachstellen in der Software sowie menschliche Schwächen ausgenutzt. Doch diese organisierten Gruppen wenden sich jetzt dem IoT und dem Industrial Internet of Things zu, bei dem Datenerfassung und -übertragung oft ohne menschliches Eingreifen vor sich gehen und wertvolle Informationen zu den Aktivitäten eines Unternehmens liefern können. Diese Informationen werden dann für wirtschaftliche Zwecke ausgenutzt oder manipuliert, um ernsthaften Schaden anzurichten – einerseits physisch, um Geräte außerhalb der Spezifikation laufen zu lassen, andererseits finanziell durch die Störung der betrieblichen Vorgänge eines Unternehmens.

Vor diesem Hintergrund ist die Entdeckung der beiden Hardware-Schwachstellen Meltdown und Spectre besonders besorgniserregend.

Meltdown und Spectre

Was sind Meltdown und Spectre?

Bei den meisten Sicherheitsproblemen, denen sich Unternehmen heute gegenübersehen, geht es darum, Schwachstellen in der Software eines Systems auszunutzen. Darüber hinaus gibt es Angriffsmethoden, bei denen die aus der physischen Implementierung eines Systems erfassten Informationen ausgenutzt werden. In diesen sogenannten Seitenkanalangriffen werden beispielsweise Zeitgeberdaten, Stromverbrauch oder elektromagnetische Lecks erfasst, um ein Bild der Aktivitäten des untersuchten Systems aufzubauen. Meltdown und Spectre gehen über diese Angriffsmethoden hinaus und nutzen Aspekte im Design von Hochleistungsprozessoren aus, um Zugriff auf Informationen aus laufenden Anwendungen zu erhalten. Diese Designmerkmale kommen in vielen modernen Prozessoren von Intel und AMD sowie in Prozessorkernen von Arm zum Einsatz. Es handelt sich um Caching und spekulative Ausführung.

Ein einfaches Pseudoprogramm sieht möglicherweise wie folgt aus:

• t = a+b
• u = c+d
• v = e+f
• w = v+g
• x = h+i
• y = j+k

Beim herkömmlichen Computerdesign führt ein Skalarprozessor wie der Intel 486 und der Arm 1176 für jeden Taktzyklus einen Befehl aus. Diese sechs Befehle nehmen sechs Taktzyklen in Anspruch.

Um die Leistung eines solchen Systems zu erhöhen, brauchte lediglich der Taktzyklus beschleunigt zu werden. Dabei ergeben sich jedoch zwei Probleme. Das erste besteht darin, dass es im Grunde eine Beschränkung für die Ausführungsgeschwindigkeit von Logikgattern gibt; das zweite ist, dass die Lese- und Schreibgeschwindigkeiten im Speicher immer mehr hinter den Prozessorgeschwindigkeiten hinterherhinken. Eine Alternative zur Erhöhung des Taktzyklus ist es, den Prozessor dazu zu bringen, mehr als einen Befehl gleichzeitig auszuführen, also einen Prozessor mit Superskalarität zu schaffen. Ein Prozessor mit zwei Befehls-Pipelines würde also zwei Befehle gleichzeitig ausführen. Derselbe Pseudocode sähe dann so aus:

• t, u = a+b, c+d
• v, w = e+f, v+g
• x, y = h+i, j+k

Und theoretisch erfolgt dies in der Hälfte der Ausführungszeit.

Bei der Untersuchung des Codes wird ein Problem offensichtlich. Das zweite Befehlspaar kann nicht gleichzeitig ausgeführt werden, da v abgeschlossen sein muss, bevor w ausgeführt werden kann. Pipeline 2 muss warten, bis Pipeline 1 wie folgt ausgeführt wurde:

• t, u = a+b, c+d
• v = e+f            # zweite Pipeline führt keine Befehle aus
• w, x = v+g, h+i
• y = j+k

Das Ergebnis sind vier Taktzyklen statt drei, also trotzdem eine Verbesserung.

Aber da die einzige Abhängigkeit zwischen w und v besteht, können die Befehle durch den Austausch von w und x neu angeordnet werden, was zu folgendem Ergebnis führt:

• t, u = a+b, c+d
• v, x = e+f, h+i
• w, y = v+g, j+k

Dies sind die optimalen drei Befehle, die mit zwei Pipelines möglich sind. Beispiele für solche Prozessoren mit Superskalarität sind die meisten Intel- und AMD x86-Prozessoren ab Pentium 2 sowie die meisten neueren Arm-Prozessorkerne.

In der Praxis sind Programme komplexer als dieses kleine Beispiel. Der größte Unterschied besteht darin, dass sie über Verzweigungen verfügen. Diese sind entweder bedingungslos (werden immer genommen) oder bedingt (werden abhängig vom berechneten Wert genommen). Sie können vorwärtsgerichtet (if-Anweisung) oder rückwärtsgerichtet (Loops) sein. Sie sind direkt – an eine bestimmte Zieladresse – oder indirekt, verwenden also eine Adresse aus einem Register, einem Speicherplatz oder aus dem Prozessorstack.

Damit die Ausführung beim Auftreffen auf eine Verzweigung nicht angehalten wird, verwenden Prozessoren Verzweigungsvorhersagen. Dabei werden Statistiken aus vorherigen Verzweigungen genutzt, um eine begründete Annahme zu treffen, ob die Verzweigung genommen wird. Eine weitere Methode, wenn drei oder vier Pipelines vorhanden sind, ist die Spekulation. Hierbei handelt es sich um den Versuch, zu erraten, welche Befehle erforderlich sind, und diese dann auszuführen. Wenn sie nicht verwendet werden, da sie möglicherweise durch eine Verzweigung redundant geworden sind, wird das Ergebnis verworfen. Mithilfe der Verzweigungsvorhersage für wahrscheinliche Pfade kann die Programmausführung durch eine spekulative Befehlsausführung erheblich beschleunigt werden.

Aber, wie schon erwähnt, hat die Speichergeschwindigkeit nicht mit der Ausführungsgeschwindigkeit Schritt gehalten. Um dies zu umgehen, verwenden die Entwickler von Prozessoren Caches, also kleine Speicher für Subsets des Speichers auf dem Prozessor-Chip. Dadurch wird eine Kopie der Speicherorte im Hauptspeicher erstellt, auf die kürzlich zugegriffen wurde oder die sich in der Nähe eines Standorts befinden, auf den bereits zugegriffen wurde und somit wahrscheinlich demnächst benötigt werden.

Im Rahmen dieser Tools kann ein Angreifer potenziell zwei Aspekte nutzen. Der erste ist, dass die Verzweigungsvorhersage so trainiert werden kann, dass sie schlechte Vorhersagen trifft. Der zweite ist: Wenn Angreifer die Zeit eines Speicherzugriffs messen, können sie sehen, ob sich die Adresse im Cache befand oder nicht.

Anhand dieser Informationen kann der Meltdown-Angreifer die im Betriebssystemkernel gespeicherten Daten lesen. Der Spectre-Angreifer kann den Speicherbereich anderer laufender Programme lesen, die nicht zugänglich sein sollten.

Abbildung 1: Grundlegende Befehlssequenz in Meltdown

Für den Zugang zur Ziel-Hardware könnten Angreifer ein kurzes JavaScript-Programm einsetzen. Wenn die Systeme einen Webbrowser ausführen (beispielsweise ein Handy oder ein Tablet), kann dies über die Ausführung einer infizierten Webseite erfolgen. Andere Geräte wie IoT-Endpunkte können angegriffen werden, indem die Malware das Web nach schwach geschützten Geräten durchsucht, der gleiche Ansatz wie bei Mirai. Nach einem Angriff durch Meltdown oder Spectre gibt es im kompromittierten System keinerlei forensische Beweise.

Trotz der enormen Publicity und Berichterstattung gibt es keine aufgezeichneten Fälle von Meltdown oder Spectre.

Wer ist betroffen?

Meltdown ist hauptsächlich ein Problem bei Intel-Prozessoren. Alle Intel-Prozessoren seit 1995 sind anfällig, mit Ausnahme von Itanium und einigen Atom-CPUs. Arm hat außerdem gemeldet, dass der Cortex A-75 anfällig ist. Außerhalb der Embedded-Welt hat Apple angegeben, dass die meisten seiner Produkte anfällig sind und hat für die gesamte Produktpalette aktualisierte Betriebssysteme herausgebracht.

Spectre ist weiter verbreitet, da viele Intel- und AMD-Prozessoren hierfür anfällig sind. Die Prozessorkerne Arm Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A17, Cortex-A57, Cortex-A72, Cortex-A73 und Cortex-A75 sind alle anfällig. Diese Kerne sind zwar das Zentrum vieler Prozessoren, aber die populärste Kernfamilie für Embedded- und IoT ist der Cortex M, der nicht anfällig ist. Arm weist darauf hin, dass Cortex-R-Betriebssystemkerne meist in geschlossenen Systemen eingesetzt werden, in denen Angreifer oft keine Schnittstelle für Attacken finden.

Raspberry Pi verwendet einen der anfälligen Kerne (Raspberry Pi 3 und später Raspberry Pi 2 verwenden den Broadcom BCM2837 mit dem Arm Cortex-A53) und ist somit immun gegen Spectre und Meltdown.

Was die breite Palette an Platinenprodukten angeht, ist die Lage weniger klar. Da es bei der Platinenauswahl darum geht, Leistung und Funktionen auf die Anforderungen der Anwendung abzustimmen, sind dies auch nach wie vor die vorrangingen Kriterien. Entwickler bevorzugen aber möglicherweise eine Platine, die weniger empfänglich für diese Bedrohungen ist, statt einige der Maßnahmen zur Minderung der jeweiligen Auswirkungen auszuprobieren.

Minderung der Auswirkungen

Seit den ersten Meldungen wurde eine wahre Lawine möglicher Minderungsmaßnahmen ausgelöst, von den Chip-Herstellern und Arm sowie von den Entwicklern von Betriebssystemen. Die Hauptanbieter für Betriebssysteme haben Aktualisierungen veröffentlicht, die bei der Minderung helfen bzw. die Angriffe sogar komplett eindämmen. Auch Antimalware-Anbieter haben ihre Produkte aktualisiert, um zu verhindern, dass die Aktionen zur Auslösung der Angriffe ausgeführt werden können.

Hardware-Anbieter haben ebenfalls eine Reihe von Fixes für ihren Microcode herausgebracht, um mögliche Auswirkungen zu mindern. Das Problem ist aber, dass Meltdown und Spectre die Designentscheidungen ausnutzen, die zur Beschleunigung der Systemleistung getroffen wurden, und die Maßnahmen zur Minderung haben den Effekt, dass der Prozessor verlangsamt wird. Laut den ersten Kommentaren in der Presse kann es sich dabei um erhebliche Leistungseinbußen von bis zu 25% handeln. Dieser Wert ist inzwischen nach unten korrigiert worden, aber die Situation ist nach wie vor sehr unklar. Intel beispielsweise musste seine Microcode-Aktualisierungen zurücknehmen und eine Reihe auf die Prozessorfamilie ausgelegte Aktualisierungen einführen, für die es zum Zeitpunkt der Verfassung dieses Artikels noch keine Leistungseinschätzungen gibt. Ein weiteres Problem ist, dass viele der Kommentatoren und Tester, die an diesem Thema arbeiten, PC- und IT-Personal sind und die Auswirkungen auf Embedded-Systeme einfach nicht messen.

Es gibt einige Fixes von Arm, die sich auf das Betriebssystem beziehen. Wiederum ist aber nicht klar, welche Leistungseinbußen bei Anwendung dieser Fixes in Kauf genommen werden müssen.

Embedded-Produkte arbeiten oft in Echtzeit. Zum Zeitpunkt der Verfassung dieses Artikels gibt es keine Kommentare von RTOS-Anbietern, außer von einem, der angibt, dass RTOS immun gegen das Problem ist. Entwickler von Embedded-Systemen entscheiden sich oft für einen Prozessor, indem sie die Leistungsanforderungen abwägen und einen Prozessor auswählen, der nahe an der benötigten Taktgrenze arbeitet. Selbst ein geringer Leistungsabfall kann dazu führen, dass die Anwendung fehlschlägt.

Was sollten IoT-Ingenieure tun?

Vereinfacht gesagt, gibt es in Bezug auf das IoT eine Reihe von Punkten zu beachten. Die Edge-Geräte, in denen Informationen erfasst und Geräte gesteuert werden, das Gateway, das Feeds aus mehreren Geräten sammelt und ins Netzwerk einspeist, die Netzwerkprozessoren und schließlich die Server in der Cloud. Im Bereich Server arbeiten Unternehmen wie Amazon hart daran, die Isolation zwischen unterschiedlichen Benutzern weiter zu verbessern und andere Sicherheitsmaßnahmen zu intensivieren. Allgemein wirken sich Meltdown und Spectre nicht auf Ethernet-Netzwerkprozessoren aus. Die Gateway-Systeme sind möglicherweise einem Risiko ausgesetzt. Vieles, was für Edge-Geräte gilt, trifft auch auf Gateways zu.

Im Hinblick auf das IoT gibt es zwei Probleme. Erstens Produkte, die bereits entwickelt sind, und zweitens zukünftige Produkte.

Viele bereitgestellte IoT-Produkte verwenden einfachere Prozessoren, Cortex M-Kerne. Dabei besteht kein Risiko eines Angriffs durch beide Arten von Malware. Unabhängig vom Prozessor ist es sinnvoll, eine Prüfung aller bereitgestellten Produkte durchzuführen und ihre Anfälligkeit zu bewerten, einschließlich das Risiko eines Angriffs und Überlegungen dazu, ob Patches ausgegeben werden sollte. Weiterhin sollte eine Unternehmensstrategie für die Behandlung zukünftiger Sicherheitsprobleme entwickelt werden, da diese mit ziemlicher Sicherheit in Prozessoren, im Kommunikations-Chip oder dem IoT-Produkt selbst auftreten werden.

Bei neueren Produkten müssen die Sicherheitsanforderungen in die Designanforderungen integriert sein. (Eine Umfrage der Barr Group von 2018 zeigt, dass die Anforderungen für weniger als 22% aller IoT-Projekte im Jahr 2017 Sicherheitsbelange umfassten.) Und da es selbst bei großen Vorsichtsmaßnahmen in Design und Implementierung trotzdem zukünftig Probleme geben wird, sollten die Designanforderungen auch Möglichkeiten für potenzielle Problemumgehungen und Vor-Ort-Fixes bieten.

Da Vor-Ort-Fixes für Software teuer sind und die Ausgabe von Ersatzplatinen noch teurer ist, ist es viel günstiger, mehr Zeit und Mühe auf die Erstellung robuster und sicherer Systeme aufzuwenden. Selbst kleine Veränderungen tragen zur Einschränkung der Anfälligkeit bei, beispielsweise, die Erstnutzung des Systems nur dann zu ermöglichen, wenn der Benutzer die werkseitig bereitgestellten Passwörter ändert. (Und es sind nur einige wenige Codezeilen erforderlich, um viel genutzte Passwörter – Passwort, 123456 oder asdgfg zu verhindern). Untersuchen Sie im Detail, welchen Zugriff Sie auf welche Teile des Systems benötigen. Vielleicht sind unterschiedliche Sicherheitsebenen für verschiedene Aufgaben möglich.

Bis die anfälligen Prozessoren mit Firmware veröffentlicht werden, die Meltdown oder Spectre keine Chance bieten, sollten Sie Alternativen in Betracht ziehen. Verwenden Sie eine gute Programmierpraxis und geeignete Tools, um hochwertigen Code zu entwickeln. Und richten Sie sich darauf ein, dass schon bald ein neues Problem auftauchen wird.

Meltdown und Spectre: Die Auswirkungen von Prozessor-Bugs auf die Sicherheit des IoT. Datum der Veröffentlichung: 15. März 2018 von Farnell