Digital > Fefes Blog 2.0 > a29dc020
  Leserreporter: Wer schöne Verschwörungslinks für mich hat: ab an felix-bloginput (at) fefe.de!
[zurück][ältere Posting][neuere Posting]  Dienstag, 12 Februar 2019 | Blog: 7 | No: 42480     feed-image

Was macht also Intel?

Aber eine Proof-of-Concept-Malware ist drinnen!

Ganz früher gab es in Rechnern nur eine Privilegienstufe. Die Trennung zwischen Betriebssystem und Anwendung war eher konzeptionell, nicht technisch. Wenn unter DOS zum Beispiel ein Prozess Mist machte, konnte er einfach Teile des Betriebssystems überschreiben.
Die Lösung lag auf der Hand. Man führt auf Hardware-Ebene Speicherschutz und eine Trennung ein. Also bewegten sich erst die Antiviren in den privilegierten Bereich und dann die Malware.
Was macht also Intel? Führt einen weiteren, noch privilegierteren Bereich ein. Der war so zugenagelt, dass sich da bisher m.W. keine Antiviren reinwurmen konnten. Aber eine Proof-of-Concept-Malware ist drinnen! Mit recht innovativen Methoden, gar. Intel hatte nämlich kürzlich die Regeln gelockert, wer in den ultra-privilegierten Bereich reindarf. Weil sich rausstellte: Wenn das keiner nutzt, ist es gar kein stechendes Verkaufsargument. Und die einzigen, die Schlange standen, waren die Hollywood-Kopierschutz-Fetischisten.
Gruss und seinen Forscherkollegen schafften es, über Sicherheitslücken in der Launch-Control-Funktionalität von Intel an Schlüssel zu kommen, mit denen sie Schadcode in eine Enklave laden können. Das Problem, dass dieser Code keine Systemaufrufe ausführen kann, um das System außerhalb der Enklave zu manipulierten, lösen sie mit der bewährten Hacker-Technik Return-Oriented Programming (ROP).
Das ist schon recht cool. :-)
Besonders unterhaltsam ist auch die Antwort von Intel:
Gegenüber dem englischen IT-Nachrichtenportal The Register sagte ein Intel-Vertreter, dass man die Schwachstellen als außerhalb dessen betrachte, vor dem SGX schützen soll. Die Aufgabe von SGX sei es, Code in einer Schutzumgebung auszuführen. Laut Intel liegt es demnach beim Systembesitzer sicherzustellen, dass der in eine SGX-Enklave geladene Code vertrauenswürdig sei.
OH ACH SO ist das! Das System, dem wir nicht vertrauen, und dem wir daher eine sichere Enklave aufgedrückt haben, dem vertrauen wir jetzt aber doch, wenn es um die Auswahl der Software geht, die in der Enklave läuft? Das klingt ja wie eine brillante Idee! Da hat ja jemand wirklich mitgedacht!1!!

[zurück] [ältere Posting][neuere Posting]
[zurück] [ältere Posting][neuere Posting]

Fefes Latest Youtube Video Links