So reagieren Sie angemessen auf kritische Sicherheitslücken in Prozessoren

Anbieter zum Thema

Linutronix GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Viele Prozessoren sind von einer äußerst kritischen Sicherheitslücke betroffen, aus der sich eine Vielzahl von Angriffsmöglichkeiten ergeben. Was diese Sicherheitslücke in der Praxis bedeutet und wie Sie darauf reagieren sollten, zeigt dieser Bericht.

Sie werden das Thema ganz sicher schon in den letzten Wochen verfolgt haben: Eine große Zahl aktuell auf dem Markt befindlicher CPUs ist von einer äußerst kritischen Sicherheitslücke betroffen, aus der sich eine Vielzahl von Angriffsmöglichkeiten ergeben – bekannt wurden die Angriffsszenarien unter den Namen Meltdown und Spectre.

Obwohl das Fehlerszenario ausreichend analysiert und äußerst umfangreich dokumentiert wurde, unterscheiden sich die Stellungnahmen der Hersteller und verschiedener Institutionen sehr stark. Wir möchten dieses Thema daher näher beleuchten und aufzeigen, was diese Sicherheitslücken in der Praxis bedeuten und wie Sie darauf reagieren sollten.

Worum geht es bei dieser Sicherheitslücke?

Letzten Endes bewirken die bekannt geworden Lücken das Auslesen von privilegiertem Speicher über einen Seitenkanal. Dabei kann beliebiger virtueller Speicher über lokale Sicherheitsgrenzen hinweg gelesen werden. Eine sehr detaillierte technische Beschreibung zu den Lücken wurde von Googles „Project Zero“ Team veröffentlicht:

Ausgenutzt wird bei einem Angriff die sogenannte spekulative Codeausführung. Moderne Prozessoren versuchen über verschiedene Spekulationsmechanismen den Programmfluss vorherzusehen und im Voraus auszuführen. Diese Ausführung findet mit Hilfe von internen Registern statt und beachtet dabei weder die Überprüfung von Arraygrenzen noch Zugriffsrechten.

Dabei werden auch Daten, auf die im realen Programmfluss nicht zugegriffen wird, spekulativ vom Speicher in den Cache geladen um einen eventuellen realen Zugriff zu beschleunigen. Dieser Seiteneffekt lässt sich durch seit Jahren bekannte Cache-Timing Attacken ausnutzen, um das Ergebnis der Spekulation "auszulesen".

Das bedeutet: Mit diesem Verfahren können unbemerkt alle Informationen gewonnen werden, die zum Beispiel für einen autorisierten Zugriff auf das System notwendig sind.

Welches Risikopotential ergibt sich hieraus in der Praxis?

Es handelt sich nicht um einen Remoteangriff, sondern um eine Attacke, für die das lokale Ausführen von Code erforderlich ist. Das klingt nun im ersten Schritt eher unkritisch und wurde leider auch fälschlicherweise in diversen Artikeln und Medienberichten so dargestellt, dass sich hierdurch für Embedded Geräte nur ein geringes Sicherheitsrisiko ergibt.

Doch Vorsicht: Allein schon das Ausführen von JavaScript über einen Browser kann bereits ein Risiko darstellen! Es ist mit an Sicherheit grenzender Wahrscheinlichkeit davon auszugehen, dass die ersten Exploits, die über einen Browser auszunutzen sind, bereits existieren und auch schon verbreitet werden.

Auch jede weitere Möglichkeit Code auszuführen (zum Beispiel ein Gastzugang, ein Diagnosezugang auf Ihr System, oder eine Schnittstelle, über die der Endkunde eigenen Code ergänzen kann) ist ein potentielles Risiko! Und auch Virtualisierung umgeht die Sicherheitslücken nicht.

Es wurde bereits nachgewiesen, dass ein Gastsystem Daten vom Hostsystem auslesen kann. Es ist daher mit Nachdruck darauf hinzuweisen, dass durchweg in jedem Anwendungsfall eine Prüfung auf ein Bedrohungspotential durch diese Schwachstellen durchzuführen ist!

Thomas Gleixner, CTO von Linutronix, ist in seiner Rolle als Co-Maintainer der x86-Architektur im Linux Kernel maßgeblich an der Entwicklung der Patches zur Behebung dieser Schwachstellen beteiligt. Er kommentiert die bekannt gewordenen Lücken wie folgt:

„Meltdown und Spectre sind in vieler Hinsicht eine völlige Katastrophe.“

„Hier werden technische Eigenschaften, die als Grundlage für Security-Konzepte dienen, komplett in Frage gestellt. In Anbetracht der Tatsache, dass seit Jahren von Forschern darauf hingewiesen wurde, dass Speculative Execution Risiken birgt und nur in Grenzen zulässig sein darf, muss man sich die Frage stellen, ob diese Warnungen und Erkenntnisse genügend Berücksichtigung beim Design von aktuellen CPUs fanden.

Es ist eine Tatsache, dass die Entwickler von Linux, aber auch von anderen Open-Source Betriebssystemen, erst relativ spät in die Behebung dieser Probleme eingebunden wurden. Jedenfalls Monate später als die Hersteller kommerzieller Betriebssysteme. Warum dies so ist, ist bis jetzt leider nicht klar. [...]

Auch die Reaktionen von Institutionen und Verbänden, die sich mit dieser Thematik auseinandersetzen, bietet noch ein großes Verbesserungspotential; [...]

Die Informationspolitik der CPU Hersteller ist teilweise sehr fundiert, als Beispiel sei hier ARM genannt, aber auch von offensichtlichen Versuchen geprägt, durch geschickte PR-Maßnahmen von den eigenen technischen Problemen abzulenken. [...]

Es ist an der Zeit, dass diese Probleme ernst genommen und auf breiter Basis offen und sachlich diskutiert werden. Sicherheit, sowohl im Privaten wie auch im Öffentlichen, darf nie auf die leichte Schulter und auf gar keinen Fall wirtschaftlichen Interessen untergeordnet werden. [...]“

(ID:45131462)