schrht
Ensign
- Registriert
- Aug. 2023
- Beiträge
- 181
Ich hab mir jetzt mal die Mühe gemacht, mir das Paper zu Downfall durchzulesen. Disclaimer vorweg: Hardwaresicherheit ist nicht mein Spezialgebiet. Ich wäre wirklich froh, wenn sich jemand finden würde, der sich besser damit auskennt und gegebenenfalls meine Fehler ausbessert.
Zum Threat Model dieser Angriffe sagt das Paper:
Ich hab's in einer früheren Antwort schon einmal gesagt, damit dieser Angriff für einen Bedrohungsakteur erfolgreich sein kann müssen folgende Rahmenbedingungen gegeben sein:
Wenn ich an die großen Anbieter, wie GCP, AWS, Azure und Konsorten denke, dann ist die Wahrscheinlichkeit, dass diese Bedingungen bewusst erreicht werden können absolut verschwindend. Bei kleineren Hostern ist die Wahrscheinlichkeit etwas größer, aber immer noch vernachlässigbar.
Und wenn Angreifer:innen Zugriff auf einen Terminalserver haben, wie @Evil E-Lex das beschreibt, dann ist es schon deutlich leichter, aber .. warum genau sollte ich mir das antun? Wenn ich bereits, wahrscheinlich über einen kompromittierten Benutzer:innen-Account oder eine andere ausgenützte Schwachstelle, Zugriff auf das System habe, dann ist es deutlich leichter, im selben Muster weiterzumachen, also den nächsten Benutzeraccount zu knacken oder den nächsten Tomcat aufzumachen, der seit 2016 keinen Patch mehr gesehen hat.
Im Großen und Ganzen werden folgende Angriffsmethoden dargelegt:
Das heißt bei einem Angriff, bei dem spezifische Instruktionen zum Einsatz kommen, kommt's nur bei ungefähr der Hälfte zu einem Datenleak - wenn man denn das Glück hat, ganz genau den richtigen CPU-Kern zu erwischen.
Etwas weiter im Text wird dann auch noch von False Positives gesprochen, da bin ich mir aber ehrlich gesagt nicht hundertprozentig sicher, wie ich das interpretieren sollte. Es könnte also unter Umständen sein, dass die Erfolgsrate noch geringer ist. Unter Laborbedingungen ist es dem Autor gelungen, ungefähr 6kb/s zu extrahieren:
Das ist für kryptographische Schlüssel, Passwörter und dergleichen absolut ausreichend, aber jetzt definitiv nicht weltbewegend. Geschäftsgeheimnisse im großen Ausmaß werde ich damit nicht exfiltrieren.
Stichwort Diebstahl kryptographischer Schlüssel:
Daraus könnte ich interpretieren, dass OpenSSL für den Angriff notwendig ist, und alternative Implementationen (LibreSSL, mbedTLS oder proprietäre TLS-Bibliotheken) nicht betroffen sind, aber darauf geht der Autor nicht ein. Und dass AES-NI zum Einsatz kommt, das kann man ruhig als gegeben annehmen. So seit .. 2012?
Ich brauche als eine VM, die auf demselben CPU-Kern, im Nachbarthread situiert ist, und von der aus ich dann eine Anfrage stellen kann. Was ich auch nicht herauslese: Was für einen Key stehle ich da? Alle vorhandenen? Das mag mein fehlendes Wissen, oder meine mangelnden Englischkenntnisse sein, aber das wirkt denkbar ungeeignet für einen gezielten Angriff.
Ähnlich verhält es sich mit der Gather Value Injection, und dem Diebstahl arbiträrer Daten:
Ja, gut. Wenn die Angreifer:innen mir ein Kernelmodul unterjubeln können, dann habe ich so oder so verloren, sichere Prozessoren oder nicht. Am "kritischsten" ist meiner Meinung nach der Angriff gegen Intel SGX, aber da muss ich mir zuerst deutlich mehr Wissen über SGX aneignen, bevor ich da einen halbwegs qualifizierten Kommentar abgeben kann.
Nochmals die Bitte, wenn jemand, der deutlich ausgeschlafener ist als ich, und mehr Kenntnisse in dem Bereich der IT-Security hat als ich, mich hier korrigieren kann und möchte, ich wäre sehr dankbar.
Dennoch, ich bleibe bei meiner Kernaussage: Beeindruckende Forschung, in einer Laborumgebung erschreckend effektiv. In der Praxis in den aller-, aller-, allermeisten Fällen komplett irrelevant - wie alle anderen Angriffe dieser Art bisher auch. Wir haben in der IT-Security viele andere, deutlich dringendere Probleme.
Zum Threat Model dieser Angriffe sagt das Paper:
Ich hab's in einer früheren Antwort schon einmal gesagt, damit dieser Angriff für einen Bedrohungsakteur erfolgreich sein kann müssen folgende Rahmenbedingungen gegeben sein:
- Die Angreifer:innen müssen die Möglichkeit haben, auf einen Prozess zuzugreifen, der sich auf dem selben Prozessorkern, in aneinanderliegenden Threads des gleichen Prozessorkerns oder sogar im selben CPU-Thread wie das Angriffsziel befindet.
- Gleichzeitig müssen die Angreifer:innen auch ein System erwischen, auf welchem es die entsprechenden Daten, wie kryptographische Schlüssel zu holen gibt.
Wenn ich an die großen Anbieter, wie GCP, AWS, Azure und Konsorten denke, dann ist die Wahrscheinlichkeit, dass diese Bedingungen bewusst erreicht werden können absolut verschwindend. Bei kleineren Hostern ist die Wahrscheinlichkeit etwas größer, aber immer noch vernachlässigbar.
Und wenn Angreifer:innen Zugriff auf einen Terminalserver haben, wie @Evil E-Lex das beschreibt, dann ist es schon deutlich leichter, aber .. warum genau sollte ich mir das antun? Wenn ich bereits, wahrscheinlich über einen kompromittierten Benutzer:innen-Account oder eine andere ausgenützte Schwachstelle, Zugriff auf das System habe, dann ist es deutlich leichter, im selben Muster weiterzumachen, also den nächsten Benutzeraccount zu knacken oder den nächsten Tomcat aufzumachen, der seit 2016 keinen Patch mehr gesehen hat.
Im Großen und Ganzen werden folgende Angriffsmethoden dargelegt:
- Gather Data Sampling (+ Cross-Process Covert Channel)
- Stealing Cryptographic Keys & Stealing Arbitrary Data
- Gather Value Injection
- Breaking Intel SGX
Das heißt bei einem Angriff, bei dem spezifische Instruktionen zum Einsatz kommen, kommt's nur bei ungefähr der Hälfte zu einem Datenleak - wenn man denn das Glück hat, ganz genau den richtigen CPU-Kern zu erwischen.
Etwas weiter im Text wird dann auch noch von False Positives gesprochen, da bin ich mir aber ehrlich gesagt nicht hundertprozentig sicher, wie ich das interpretieren sollte. Es könnte also unter Umständen sein, dass die Erfolgsrate noch geringer ist. Unter Laborbedingungen ist es dem Autor gelungen, ungefähr 6kb/s zu extrahieren:
Das ist für kryptographische Schlüssel, Passwörter und dergleichen absolut ausreichend, aber jetzt definitiv nicht weltbewegend. Geschäftsgeheimnisse im großen Ausmaß werde ich damit nicht exfiltrieren.
Stichwort Diebstahl kryptographischer Schlüssel:
Daraus könnte ich interpretieren, dass OpenSSL für den Angriff notwendig ist, und alternative Implementationen (LibreSSL, mbedTLS oder proprietäre TLS-Bibliotheken) nicht betroffen sind, aber darauf geht der Autor nicht ein. Und dass AES-NI zum Einsatz kommt, das kann man ruhig als gegeben annehmen. So seit .. 2012?
Ich brauche als eine VM, die auf demselben CPU-Kern, im Nachbarthread situiert ist, und von der aus ich dann eine Anfrage stellen kann. Was ich auch nicht herauslese: Was für einen Key stehle ich da? Alle vorhandenen? Das mag mein fehlendes Wissen, oder meine mangelnden Englischkenntnisse sein, aber das wirkt denkbar ungeeignet für einen gezielten Angriff.
Ähnlich verhält es sich mit der Gather Value Injection, und dem Diebstahl arbiträrer Daten:
Ja, gut. Wenn die Angreifer:innen mir ein Kernelmodul unterjubeln können, dann habe ich so oder so verloren, sichere Prozessoren oder nicht. Am "kritischsten" ist meiner Meinung nach der Angriff gegen Intel SGX, aber da muss ich mir zuerst deutlich mehr Wissen über SGX aneignen, bevor ich da einen halbwegs qualifizierten Kommentar abgeben kann.
Nochmals die Bitte, wenn jemand, der deutlich ausgeschlafener ist als ich, und mehr Kenntnisse in dem Bereich der IT-Security hat als ich, mich hier korrigieren kann und möchte, ich wäre sehr dankbar.
Dennoch, ich bleibe bei meiner Kernaussage: Beeindruckende Forschung, in einer Laborumgebung erschreckend effektiv. In der Praxis in den aller-, aller-, allermeisten Fällen komplett irrelevant - wie alle anderen Angriffe dieser Art bisher auch. Wir haben in der IT-Security viele andere, deutlich dringendere Probleme.
