 Glimm und Dinorison, Moritz, wir sind Heller-Bade und wir sind froh auf Feedback auf Twitter mit dem Hashtag C3T. Und ich glaube, ihr nehmt dann, dass es einfach funktioniert und es einfach so funktioniert wie es soll. Und ich meine, was könnte schon schiefgehen hier? Unser Nächster und der erste Vortrag wird von Glimm und Dinoris gehalten, die die vorher schon mal mit Rohammer.js hier war. Und Moritz Lipp, wer an Armageddon gearbeitet hat, ein Exploit-Bug. Und ich möchte gerne einen großen Applaus für die Vortragner hören, über den Vortrag WAKU possibly go wrong with insert x86 Instruction hier. Vielen Dank, dass ihr hier seid heute. Das ist unser Vortrag, what could possibly go wrong with x86 Instruction here. Ein paar Worte über uns, ich bin Clementin Moritz. Ich habe ein PhD in Informatik und arbeite in Graz bei der Institute of Technology. Ihr könnt mich per E-Mail oder Twitter erreichen oder was auch immer. Hallo, mein Name ist Moritz Lipp. Ich bin ein PhD-Student am gleichen Ort, Graz University of Technology. Und ihr könnt mich auch per E-Mail oder Twitter erreichen. Also über diesen Vortrag, der Titel, sagt eigentlich schon alles. Aber das ist kein Software Talk. Geht noch nicht, bitte. Ich gehe sogar davon aus, dass wir über sicherer Software reden und das heißt nicht notwendigerweise, dass das eine sichere Ausführung ist. Und das geht um Information Leaks in der Hardware, die darunter ist. Und es geht um Cash Attacks, bei denen man nicht mehr den Speicherzugreifen zu greifen muss. Und wie man damit das Kernel ESLA umgehen kann. Der Vortrag sagt, es geht um x86 Instructionsanweisungen. Und das Ganze kann aber auch auf anderen Architekturen passieren, nicht nur auf x86. Also ein bisschen Hintergrund. Also das meiste des Hintergrunds wird um das hier gehen. Und das Ganze geht hier um einen großen Teil unseres Researchers. Und hier geht es um Move, also wie man anfängt mit diesen Cash Attacken. Und CL Flash, da geht es darum, Cash Attacken zu machen, ohne dass man Speicherzugreifen machen muss. Und wie man mit Prefetch das Kernel ESLA umgehen kann. Und gibt es doch ein Bonus. Und das ist nicht von unserer Arbeit, sondern wie man noch mehr Instruktion benutzen kann für Attacken. Eine kurze Einführung. Wir werden uns auf Intel CPUs konzentrieren. Und die Caches in Intel CPUs sehen ungefähr so aus. Es gibt verschiedene Levels und mehrere Chores hier. Und wir haben drei Cash Levels. Wir haben Level 1 und Level 2, die sind Private Pro Chore. Und Level 1 und Level 2 sind für jeden Chore privat. Und das ist Last Level Cache. Und die sind in Slices unterteilt. Also hier haben wir Slices für vier Chores. Aber die ganzen Slices sind über die verschiedenen Kerne geteilt. Also 0 kann 1, 2 und 3 auch zugreifen. Also dieser Cash ist inklusiv. Das heißt, alles was in Level 1 und 2 drin ist, ist in Level 3 auch drin. Das stellt sich ja aus, es ist sehr nützlich, um Cash-Angriffe ausführen zu können. Also heute haben wir Set-Assoziative Caches. Das heißt, man hat Daten, das sind ein bestimmtes Set geladen wird. Und das hängt nur von den Adressen an. Aber hier haben wir ein Stück der Adresse. Das gibt uns ein Index im Cash. Also das heißt, das wird dann ein Cash Set. Dann haben wir mehrere Wege pro Set. In diesem Fall ist es ein vier Wegeset. Und die Cash-Line wird in einen bestimmten Weg geladen. Und das hängt von der Ersetzungsregel ab und nicht von der Adresse. Also in der Regel, wenn man da was lädt, ist der Cache voll. Und dann muss man dafür Platz machen. Also da kommt dann diese Ersetzungspolicy ins Spiel. Also die dann sagt, okay, ich nehme jetzt diese Cash-Line hier raus und Platz zu machen für die nächste. Also heute werden wir nur drei Instruktionen anschauen von Intel Architektur. Also die Aspekte, die wir interessiert sind, kann man Daten im Speich anschauen. Das mit MOV, dann mit CL Flash. Geht es darum, etwas zu entfernen aus dem Cash. Und Prefetch werden wir anschauen. Und das heißt, man kann etwas vorholen, um zukünftig zu verwenden in den Cash-Laden. Und diese Instruktionen haben Seiteneffekte und da greifen unsere Angriffe an. Also wenn ihr euch nicht so gut auskommt mit Assembly, macht euch keine Sorgen. Also wir erklären das gut. Also erst schauen wir uns mal die MOV Instruktion an. Also ja, gut, jetzt dieses Slide ist halt schon Vollcode. Wie ihr hier sehen könnt, mit MOV bewegt man Speich von Register zu Register und von um Zoom Hautspeicher. Also gibt da viele verschiedene Möglichkeiten, wie man das benutzt. Aber es geht nur darum, Daten zu verschieben. Und wenn was schief geht, dann gibt es einen Fehler. Also es gibt ja, man würde denken, ja, da ist man stark eingeschränkt, da geht nichts schief, aber das stimmt nicht. Es gibt viele Fehler, die MOV machen kann. Aber die Daten, die MOV berührt, werden immer in den Cash geladen. Und das ist transparent gegenüber dem Programm, das gerade läuft. Aber es gibt Seiteneffekte, wenn man MOV ausführt. Und das werden wir uns jetzt genau anschauen. Also ihr kennt wahrscheinlich, dass schon die Daten sind entweder in den CPU-Registern, in den verschiedenen Levels des Caches oder im Hauptspeicher oder auf der Festplatte. Und je nachdem, wo die Daten sind, braucht es länger, bis es beim Prozessor hingeladen wird. Also das sind wir in diesem Plot hier. Also hier messen wir die Zugriffszeit auf eine bestimmte Adresse und große Anzahl. Und dann sieht man, wie oft es schon im Cash ist. Also bei etwa 70 Zyklen ist es geladen und dann ist es im Cash. Aber wenn wir annehmen müssen, dass die Daten im Hauptspeicher sind, dann braucht es deutlich länger, also vielleicht etwas mehr als 200 Cycles. Und dann ist es geladen. Also wenn wir jetzt messen können, wie lange es geht, bis die Daten geladen sind, wissen wir, ob es aus dem Cash kommt oder aus dem Hauptspeicher. Und diese Eigenschaft können wir mit einem Cash-Angriff auslösen. Also wir messen einen Zeitunterschied eines verschiedener Speicherzugriffes Also ein Angreifer überwacht die Cashlines, aber er weiß nicht, was da drin ist. Also er kann nur wissen, dass diese Cashline zugegriffen wurde oder nicht. Was man damit machen kann, ist, man kann ein Covert Channel bauen. Also Prozesse können miteinander kommunizieren über diesen versteckten Kommunikationskanal. Außerdem gibt es Side Channel Angriffe, also mit einem bösen Prozess kann man über andere Prozesse ausspionieren. Also man kann unter Umständen Kryptoschlüssel klauen. Es gibt verschiedene Typen von Cash Angriffen. Ich werde jetzt mal den bekanntesten vorstellenden Flash und Reload Angriff. Also rechts haben wir den Adressraum des Opfers und links haben wir den Adressraum des Angreifers. Die sind geteilt, also für den executable Bereich, aber natürlich das Opfer benutzt seinen eigenen Adressraum. Also wenn jetzt diese Daten in den Cash gelangen, dann werden die für den in der gleichen Zell gespeichert. Und der Angreifer kann jetzt die Flash Instruktion verwenden, um Daten aus dem Cash zu entfernen. Dann ist es nicht mehr im Cash. Das heißt, wenn es für den Angreifer nicht mehr im Cash ist, dann ist es für das Opfer auch nicht im Cash. Und wenn jetzt der Angreifer was Neues lädt oder das weg dem, dann ist es wieder im Cash. Und der Angreifer kann jetzt die Daten auch neu laden und dann messen, wie lange das ging und weiß, ob das Opfer zugegriffen hatte auf diese Cash-Zeile oder nicht, weil die Daten da sind oder nicht. Die zweite Angriff heißt Prime and Probe und da geht es jetzt nicht um shared memory wie beim anderen Angriff. Also anstelle, dass man da irgendwas reinmappt, lädt der Angreifer einfach viele Daten in eine Cash-Line. Also und füllt damit den Cash. Und jetzt kommt er neu das Opfer dran und lädt jetzt irgendwelche Daten, die ins gleiche Cash-Set gehören. Das heißt, das Cash-Set wird vom Angreifer und vom Opfer gleichzeitig verwendet. Und der Angreifer misst jetzt die Zugriffszeit auf all die Daten, die er vorhin in den Cash geladen hat. Und wenn man eine Adresse zugreift, die noch im Cash ist, geht es schneller. Und wenn es nicht mehr im Cash ist, muss es neu geladen werden und dann braucht es länger. Also das zusammenzufassen, ja, so stellt er fest, ob das Opfer Daten in den Cash geladen hat. Also wir zeigen euch mal, was man jetzt machen kann mit Cash-Attacks. Man kann einen versteckenden Kommunikations-Kanal implementieren. Das geht zum Beispiel so. Also man installiert ein bösartiges App auf dem Telefon, um irgendwelche Bilder anzuschauen, Filter anzuwenden darauf. Man sieht dem nicht gleich an, dass es bösartig ist, weil die einzige Berechtigung, die es hat, ist, um auf Bilder zuzugreifen. Also man kann das installieren, ohne sich Sorgen zu machen. Dann auf der anderen Seite installieren wir noch weiter ein App, welches das Wetter anzeigen kann. Und das hat Internetzugreifen, weil es muss ja die Wetterdaten irgendwo herkriegen. Was passiert jetzt, wenn man hier einen versteckenden Kommunikations-Kanal implementieren kann? Also der keine Permissions für die Apps benötigt, aber trotzdem den Apps ermöglicht, miteinander zu kommunizieren. Also versteckt vom Betriebssystem. Wenn dieser Kanal existiert, dann könnte natürlich das Gallery App ein Bild dem Wetter App schicken und das Wetter App könnte dieses Bild hochladen und allen zeigen. Ja, und das kann man diesen Prime and Probe und Flush and Reload Attacken bauen, diesen versteckenden Kommunikations-Kanal. Also wir müssen da irgendwie zwischen diesen zwei Apps Daten übertragen. Wie macht man das? Der Sender und Empfänger eidigen sich auf ein Cache Set, das sie beide verwenden. Der Empfänger schaut sich das Cache Set die ganze Zeit an. Und wenn der Sender etwas schicken will, also eine Null, dann tut er nichts. Das heißt, die Cache Seile gehört komplett dem Receiver. Umgekehrt, wenn der Sender etwas senden will, dann greift er auf eine Adresse zu, im gleichen Cache Set. Das heißt, der Receiver braucht dann länger, um auf diese Cache Seile zuzugreifen und weiß dann, okay, das ist eine Eins. Jetzt zeigen wir, was man mit diesem Covert Channel machen kann. Das Schöne daran ist, dass es Low Requirements hat und man kann damit sehr einfach so einen Covert Channel aufbauen. Und das geht auch zum Beispiel zwischen Virtual Machines auf Amazon Easy Tools. Und wir sehen, dieses Prime and Probe braucht dieses Shadow Memory nicht. Und das andere an diesem Cache Covert Channel ist, dass es sehr, sehr neu ist. Also das könnte man vielleicht merken, wenn andere Applikationen auch auf den Cache zugreifen, dann funktioniert diese Kommunikation vielleicht nicht. Und es gibt auch noch mehr Neues, dadurch, dass die Prozesse nicht zur gleichen Zeit gescheduled werden. Und dann kann ein Teil der Übertragung verloren gehen. Und was wir jetzt gemacht haben, ist, dass wir ein Error Free Covert Channel gebaut haben und haben dieses Neues Problem gelöst, indem wir Fehler Detection eingebaut haben, indem wir der Sender und Receiver synchronisiert haben. Und können so die Errors recovern, selbst wenn es einen Haufen Neues hat in diesem System. Und so können wir jetzt Files irgendwo hinschicken. Der Covert Channel ist komplett fehlerfrei geblieben, obwohl wir sehr, sehr viel Rauschen im System hatten. Und das Ganze haben wir zwischen verschiedenen virtualen Maschinen auf Amazon Easy Tools gemacht. Und wir wollten etwas damit machen. Und was wir jetzt geschafft haben, ist, dass wir eine SSL Connect Verbindung erstellt haben über diesen Cache. Und es gibt eigentlich kein Netzwerk zwischen diesen zwei Maschinen. Aber wir haben das jetzt eine SSL Connect Verbindung erstellt über diesen Cache Covert Channel. Und es ist also ein echtes Bedrohung. Und das Ganze wird bald veröffentlicht. Und das Zweite, das man hier machen kann, ist, dass es eine Crypto-Side-Channel-Angriff gibt. Und es gibt einen Angriff auf AES auf die Fast-Soft-Implementation. Und es benutzt vor Computed Lookup-Table. Und es ist bevorzugt zu diesem Side-Channel-Attack. Und es ist ein One-Round-Non-Plaintext-Attack. Also dieses AES benutzt einen vorberechtigten Zustand. Und es ist eine bekannte Plaintext-Attacke. Und was das bedeutet, ist, dass wenn man die Tabellenindices rauslesen kann, kann man den Key rückberechnen. Das geht mit diesem Flush and Reload und Prime and Pro. Und man hat links die Plaintext-Values. Und auf der rechten Seite hat man die Plaintext-Bite-Values mit dem Prime and Pro linkses Flush and Reload. Wir sehen hier ein Haufen Cash-Hits auf der linken Seite und auf der rechten Seite. Hier sieht man quasi ein Spielzeugbeispiel. Also der Key ist einfach nur null und solange man diese Diagonale in diesem Muster sieht, kann man den Key berechnen. Es ist ein alter Angriff und alles sollte inzwischen eigentlich gepflegt sein. Aber ihr könnt euch sicher sein, dass das noch nicht der Fall ist. Auf Android, in Bouncy Castle, die Default-Implementation benutzt immer noch diese T-Tables, die angreifbar sind und das ist schlecht. Und viele Implementationen, die man online findet, benutzen immer noch vorberichtende Werte. Und ihr solltet euch, ja, die letzte Anwendung dafür ist, wie man auf Tasteingaben spionieren kann. Und mit dem Flasche Reload kann man sehr, sehr feingrain angreifen. Da kann man auf Tasteingaben spionieren. Und wir haben sogar eine kleine Demo für euch. Also was ihr hier sehen könnt, und das ist nicht einmal auf X86, sondern auf einem Smartphone, aber ihr könnt das auch auf X86 machen. Auf der linken Seite seht ihr den Bildschirm, auf der rechten Seite seht ihr eine Shell, die quasi keine Privileges, also kein Route-Zugriff hat. Und auf der rechten Seite werden wir dieses Keyboard-Spy-Programm starten. Und auf der linken Seite kann man jetzt etwas eingeben. Und auf der rechten Seite sieht man, was hier eingegeben wurde. Und sogar wenn man die Leertaste drückt, kann man das sehen. Und wenn der Benutzer den Backspace-Key drückt, kann man das auch sehen. Und man kann wirklich das ganze Wort rekonstruieren, ohne dass wir irgendwelche Erlaubnisse oder Privilegien hatten, also kein Route-Zugriff. Was sehr, sehr schlecht ist. Also genug um die Move Instruction. Jetzt schauen wir Flasche an. Was die Flascheinstruktion macht, ist, sie invalidiert von allen Levels, die Cache-Line, die zu dieser Adresse gehört, die man dem Befehl mit gibt. Und es ermöglicht Flasche und Reload-Attacken. Aber es geht noch mehr dazu. Wenn man CL-Flash benutzt, CL-Flash hat ein anderes Timing als ... Wenn ihr eine Cache-Line habt im Level 1, und das bedeutet, es ist auch im Last-Level-Cache. Und das ist sehr nützlich, weil das ist auch, warum wir diese Inclusion-Property haben. Wenn wir herausfinden wollen, ob eine Line in irgendeinem Cache ist, muss man nur im Last-Level-Cache nachschauen. Und wenn man das hier sieht, dann kann man sagen, wir flaschen das jetzt. Und wenn man das jetzt hier rausflascht, dann ... wird es auch in Level 1 und Level 2 geflasht. Und das ist halt langsam. Wenn man CL-Flash auf nicht gecashen Daten ausführt, dann geht es auch zum Last-Level-Cache. Sieht aber, dass es nichts da hat. Und das bedeutet, es ist nirgends in einem Cache, und das bedeutet, jetzt muss es eigentlich nichts machen. Und das ist schnell. Und so kann man ... wie schnell oder langsam ist das wirklich? Also, um genau zu sein, es sind nur ein paar Prozessorzyklen. Und das ist jetzt auf Sandy Bridge, Ivy Bridge, und Haswell, und die verschiedenen Farben korrespondieren zu den verschiedenen Architekturen. Und ihr könnt hier sehen, dass man die verschiedenen Mikroarchitekturen über die verschiedenen Timings rauslesen kann. Und das Spezielle ist, dass die durchgestrichene Linie ist ein Cache-Flash von etwas, das schon im Cache war, und das gestrichelte ist, wenn es schon im Cache war. Also, was könnte hier schon schiefgehen? Also, wir haben eine neue Cache-Attacke. Und das ist die Flash-Flash-Attacke. Und ich werde dir die jetzt erklären. Also, es geht hier wieder um Cover-Channels und Side-Channel-Angriffe. Und wir können diese beide auch ausführen. Und es ist Stealthier aus den vorherigen Angriffe, und es ist auch schneller. Und wie funktioniert das jetzt genau? Das Prinzip ist ähnlich zum vorherigen. Wir haben den Angreifer auf der rechten Seite und das Opfer auf der linken Seite. Und hier haben wir wieder eine geteilte Cache-Line. Und der Angreifer flasht die Cache-Line und das Opfer lädt wieder Daten rein. Und der Angreifer flasht den Cache wieder. Und anscheinend, dass er die Cache-Line noch mal lädt, versucht es, sie jetzt zu flaschen. Und wenn man jetzt diesen Zeitunterscheid hat, kann der Angreifer herausfinden, ob die Cache-Line benutzt wurde oder nicht. Und ich habe vorhin über Stealthiness gesprochen und diese Cache-Attacke und das betrifft auch Rohammer. Die sind schon ziemlich stealthy, weil es gibt keinen Antivirus oder so heute, die das irgendwie sehen könnten. Aber wir könnten das mit Performance-Zählern rausfinden und weil man würde sehen, wie viele Cache-References passiert sind. Und wir wollen eine bessere Metrik haben, um das zu messen. Und dieser Angriff hat einen großen, häufigen Zugriff auf den Cache und sehr, sehr kurze Code-Loops. Und das bedeutet einen sehr, sehr kurzen Zyklus und das hat einen tiefen Translate-Look-Sitebuffer. Also man konnte da Angriffe detektieren und es gab keine False-Positives. Also diese Metrik werde ich jetzt verwenden, wie wir das hier reden. Also wir haben angefangen, dem wir ein Cover-Channel implementiert haben. Wir wollten das so schnell wie möglich haben. Also wir haben einen Protokoll entwickelt, um mit diesem Flash & Flash & Flash & Reload & Prime & Probe diese Daten auszunutzen. Wir haben mit einem Paketgröss von 28 angefangen. Da sieht man hier die Kapazität des Kanals, also rund 500 Kilowatt. Und bei Flash & Reload sind es 300. Also Flash & Flash ist schon mal deutlich schneller. Dann haben wir geschaut, wie leicht man das detektieren kann oder nicht. Also Flash & Flash ist schwer zu detektieren. Die beiden sind ja relativ ähnlich. Und der Sender ist gleich, der Empfänger ist nicht gleich. Also hier Sender-Self gibt es bei beiden nicht, weil das ist der gleiche. Aber Receiver Flash & Flash ist besser. Jetzt machen wir das gleiche, aber schwer zu detektieren. Also wir machen eine kleine Paketgröße und hoffen, dass das dann nicht so gut erkennen kann. Also es gibt weniger Cash-Hits, Cash-Miss ist so. Und dann sind diese Angriffe schlechter zu detektieren. Die Kapazität sind jetzt hier, die ersten zwei sind um die 50 Kilobyte. Und Prime & Pro ist etwas langsamer. Also das braucht einfach mehr Zeit, diesen Angriff auszuführen. Aber trotzdem ist nur Flash & Flash schwer zu detektieren. Ja, zwar nicht. Und ja, der Sender ist jetzt aber auch schwer zu erkennen bei Flash & Flash. Also ja, wenn ihr ein versteckten, schwer detektierbaren Kanado braucht, nehmt Flash & Flash. Es hatte aber zu viel Rauschen für gewisse Angriffe. Also wir wollten die Anzahlverschlüsselung zu feinen, um ein Beit des Keys rauszulesen. Und Flash & Reload ist dann ein bisschen besser. Also man muss nur 250 Mal verschlüsseln, um ein Beit des Keys rekonstruieren zu können. Aber Flash & Flash kommt dann nah ran mit 350. Und Prime & Pro hat am meisten Rauschen, da muss man fast 5.000 Verschlüsselungen ausführen, um ein Beit des Keys wiederherstellen zu können. So, und jetzt zur Stealthiness. Also ja, undetektierbarkeit. Da sieht man, ja, haben wir 256 Millionen Verschlüsselungen ausgeführt. Und der Spion und das Opfer waren am Laufen. Und hier, es ist nur Flash & Flash, wurde nicht detektiert. Ja, und da geht es nicht nur um den Cover Channel, sondern um ein Side Channel, weil im echten Leben kann man ja nicht dem Opfer sagen, warte doch schnell auf mich. So, noch ein bisschen mehr Hintergrund hier, bevor wir weitermachen. Also ich habe die verschiedenen Levels des Caches gezeigt, und jetzt schauen wir uns den Last Level nochmal genauer an. Also wir haben diese 4 Slices hier, das letzten Cash Levels, und da haben wir ein paar Bits der Adresse, die gehören zur Adresse. Und wir müssen wissen, in welchem Slice die Adresse ist. Und das ist ein Teil des Sets und Teil des Tags. Da gibt es eine Herrschfunktion, und die bestimmt, in welchem Slice die Cashline hinkommt. Und diese Funktion ist aber nicht dokumentiert von Intel. Also man hat so viele Slices wie Cores, eine undokumentierte Herrschfunktion, die eine physische Adresse auf ein Slice mapt. Und ja, es wurde nicht so entwickelt, dass es sicher ist, sondern dass es schnell ist. Man will, dass die Zugriffe gleichmäßig verteilt sind aus Performance Gründen. Also die Herrschfunktion nimmt ein paar Bits der physischen Adresse und gibt dir die 2 einige Bits des Slices zurück. Ja, bei 4 Slices, also 2 Bits, also gehen wir zurück zu CL Flash. So, CL Flash ist schneller, schneller, um auf den lokalen Slice zuzugreifen. Also wenn man immer Flasht, eine einzige Zeile, und man läuft auf, das Programm läuft auf ein, wie so 4 Cores, dann sieht man, dass bei einem Core CL Flash schneller ist. Also hier ist das Core 1. Man sieht Core 0, 2 und 3, ist ein bisschen langsamer. Also so weiß man, dass das Programm auf Core 1 läuft. Also, dass die Leidensprechung in Slice 1 war. Ja, mit dem kann man die physischen Adressen auf Slices mapten. Also man kann diese Herrschfunktion reverse engineer. Eine andere Variante, das rauszufinden, wären Performance Counter, die ich schon vorher erwähnt hatte. Um diese Herrschfunktion auszufinden, aber das ist eine andere Geschichte. Also geht die Servusnote nach, wenn euch das interessiert. So, die nächste Instruktion ist Prefetch. Also geht es darum, dass man ein CPU sagt, please, lade diese Daten, die ich später brauche, in den Cache, wenn du Zeit hast. Und tatsächlich gibt es hier 6 verschiedene Prefetch Instruktionen, 0 bis UT2. Das heißt, bitte lade die Daten in den ersten oder den letzten Level Cache. Ja, wir lassen die Details hier mal aus, das ist nicht so spannend. Was spannender ist, ist, wenn wir im Intel Handbuch nachschauen, was es über Prefetch da steht. Das heißt, benutzt die Prefetch Instruktion nur, wenn die Daten nicht in den Cache passen. Also eben, wenn ihr Daten streamt, dann ist es schneller. Also benutzt Prefetch nur auf Adressen, die zum Applikationskontext gehören. Also was passiert dann wohl, wenn man diese Bedingung verletzt? Tönt interessant. Wenn man Prefetch auf andere Adressen macht, dann kann das nicht deterministisches Performanceverhalten verursachen. Also wenn man zum Beispiel den Null-Pointer verwenden kann, kann es lange Verzögerung geben. Also ja, man will das nicht machen, weil die Anwendung sonst langsam wird. Also ja, was heißt denn, dass das nicht deterministisch ist? Schauen wir uns das mal an. Weil, ja, wir wollen ja die Software richtig schreiben. Also ein bisschen Hintergrundwissen dazu, um diesen Angriff zu verstehen. Also auf modernen Betriebssystemen hat jede Anwendung ein eigen virtuellen Adressrahmen. Also irgendwann muss die CPU diese virtuelle Adresse in eine physische Adresse übersetzen. Und dazu hat man diese kompliziert aussehende Datenstruktur hier. Also man hat ein Acht-Bit-Virtuell-Adresse und gewisse Bits gehen nach einem PM-Level einer Tabelle mit so vielen Entries hier. Also je nachdem, welche Bits da sind, wird bestimmt auf welche Line im Cache man zugreifen muss. Und man schaut wieder so Page Directory nach und holt sich die entsprechenden Adress-Bits raus. Also für jeder Level hier funktioniert das genau gleich. Bis am Ende, wenn man auf die Page-Table kommt, hat man 4 Kilowatt-Pages. Also es ist nicht wahnsinnig kompliziert, ein bisschen verwirrend. Also wenn man eine physische Adresse haben will, im Hauptspeicher, muss man das nachschauen. Und das machen, indem man die virtuelle Adresse übersetzt. Und dazu geht man durch all diese Stufen durch. Wir können das effizienter machen. Und Intel hat dazu spezielle Caches eingeführt für all diese Stufen. Also wenn man eine Adresse übersetzen will, dann schaut man im ITLB nach für Anweisungen und DTLB für Daten. Wenn es da ist und wenn es nicht da ist, geht man weiter unten, also diese Stufen, bis man am Ende im DRAM nachschauen muss. Dazu ist dieser Adress-Raum, den man hat, geteilt. Man hat einenseits das User-Memory und das Kernel-Memory. Und das ist da auch vorhanden, das User-Memory. Und wenn aus dem User-Memory man auf Kernel-Funktion zugreifen will, zum Beispiel ein File lesen, dann wechselt man in Kernel-Modus. Und ja, man kann das da machen mit diesen Rechten, die man dann hat. Im Kernel hat man Treiber. Und wenn man die Adressen der Treiber weiß, dann kann man Code-Reuse-Angriffe fahren. Also die benutzen also Leer, auch im Kernel, also Ka-Alse-Leer. Und das heißt, wenn das Programm läuft und der Kernel gemappt ist auf eine Adresse und wenn man den Computer neu startet, dann ist das eine andere Adresse. Und wenn es irgendwie eine Möglichkeit gäbe, rauszufinden, an welche Adresse der Kernel geladen ist, dann hat man diese Technik ausgehebelt und Ka-Alse-Leer ist wirkungslos. Dazu gibt es noch die Kernel-Direct-Physical-Map. Was heißt das? Es implementiert den zahlreichen Betriebssysteme, wie zum Beispiel OSX, Linux und Xenhypervisor und BSD, aber nicht in Windows. Also das heißt, das komplette physische Speicher ist dazu im Kernel-Memory an einem festen Offset hingemappt. Also es ist im User-Space gemappt. Wenn etwas im User-Space gemäß ist, dann ist es im Kernel-Space auch an einem bestimmten Stell gemappt. Aber da kann man nicht zugreifen, weil man die Rechte dazu nicht hat. Aber das brauchen wir dann später. Also zurück zu Prefetch und was man jetzt mit diesem Wissen anfangen kann. Also Prefetch ist nicht eine übliche Instruktion, weil es sagt, das CPU, ja, das brauche ich wohl später. Ja, also wenn du es nicht ausführen kannst, dann ignorier das. Also es ist nur ein Hinweis an die CPU und es wird nicht unbedingt ausgeführt, aber ist es aber normalerweise. Und auch eine schöne Eigenschaft ist, es gibt keine Faults. Also egal, was man mit dieser Instruktion macht, das Programm stört es nicht ab. Und außerdem, da werden keine Rechte überprüft. Also es gibt im Fall nicht, dass man ihnen auf Kernelspeicher zugreifen will und die CPU sagt, nein, das geht nicht, du darf das nicht. Also das kann nicht passieren. Das ist sehr schön. Dann das zweite ist, unser Operant ist eine virtuelle Adresse. Also heißt jedes Mal, wenn man diese Instruktion ausführt, muss man diese physische Adresse ausrechnen. Also man muss diesen Lookup machen mit diesen Tabeln, die ich vorher erwähnt hatte. Und ja, ihr habt es wahrscheinlich schon erraten, die Ausführungszeit variiert. Und wir werden gleich sehen, was man damit anfangen kann. Also zurück zu dieser Direct Physical Map. Und wir können jetzt ein Oracle bauen für Adress-Übersetzung. Also wir können herausfinden, welche Physische Adresse zu einem virtuellen Adresse gehört. Normalerweise will man nicht, dass der User es war, weil damit kann man Rohhamer Angriff fahren und fortgeschrittene Cache Angriffe. Also man will nicht, dass der User das rausfinden kann. Aber wir schauen mal, ob wir das vielleicht irgendwie rausfinden können. Wenn man hier eine Page im User Space hat und wir haben die Zwillingspage im Kernelspace. Und wenn die gecached sind, dann sind sie beide im gleichen Ort gecached. Und der Angreifer wird dann den Adress-Ram flaschen und vom Kernel. Und da kann man Prefetch ausführen auf der Kernel-Adresse. Und das generiert hier keinen Volt. Also kann man der CPU jetzt sagen, hol diesen Adresse bitte in den Cache. Obwohl ich eigentlich keinen Zugriff habe auf diese Adresse. Und wenn ich jetzt hier messe, ob ich hier ein Cache habe, dann kann ich jetzt rausfinden, wo genau diese Adresse jetzt im physischen Adress-Raum gemappt wird. Und so können wir jetzt die physische Adresse für diesen Adress-Raum rausfinden. Und so können wir das jetzt mapen. Und das sieht dann etwas so aus. Und es ist ziemlich einfach. Man macht das einfach für alle Adressen. Und irgendwann sieht man ein Cache-Hit. Das ist da, wo der Graph nach unten geht. Und da wissen wir jetzt, dass diese physische Adresse korrespondiert mit unserer virtuellen Adresse. Und wir können hier die Prefetch-Timings ausnutzen, weil, als ich gesagt habe, wenn man Prefetch ausführt und es ist ausgeführt auf etwas, das nicht im Cache ist, dann ist das nicht deterministisch und geht lange. Das Timing hängt davon ab, wo die Übersetzung aufhört. Und diese zwei Eigenschaften und die Informationen kann man zusammentun und kann das folgende machen. Wir können Varianten von den Cache-Attacken generieren, zum Beispiel Flash und Prefetch. Und wir können da jetzt Rohammer-Attacken fahren auf privileged Adresses, also Kernel-Space-Adresses. Und dazu können wir es benutzen, um die Iceler zu umgehen, obwohl das Prog-Fi-System nicht mehr zugänglich ist für nicht privilegierte Prozesse. Dazu kann man noch die virtuellen Adressen zu physischen Adressen mapen, was auch eine privilegierte Operation wäre. Und das bedeutet, man kann jetzt wieder diese Return to Directory exploits ausführen. Und noch dazu kann man rausfinden, wo das Kerneltreiber geladen sind im Speicher. Und dadurch kann man auch KRA-SLR umgehen. Und hier werde ich euch zeigen, wie. Also für das erste Oracle muss man alle gemapten Adresses finden. Und das macht man, indem man die Evict-Translation macht. Und dann macht man einen CIS-Call auf den Treiber, den man gefunden hat. Und dann muss man schauen, wie lange das geht, bis es geprefetched wird. Und die schnellste Zuge zeigt, ist, wo die Treiber-Page genau ist. Und auf Windows 10 kann man das Ganze in unter 12 Sekunden machen, was sehr, sehr schön ist. In der Realität sieht das Ganze auch so aus. Und es gibt ein Haufen langer Messungen. Und es gibt dann ein paar sehr, sehr kurze. Und dann sieht man, dass der Treiber sich in diesem Adressraum befindet. Und so kann man diese Red-2-Dir-Attacken fahren. Und das ist jetzt aber noch nicht ganz alles, weil es gibt da noch ein paar andere Instruktionen. Und das nächste ist nicht unsere Arbeit, aber es geht da um mehr Anweisungen, die man ausnutzen kann. Die RD-Seat-Instruction-Anweisung. Was es macht ist, es holt ein zufälligem Seat von der Hardware. Und alles, so wie mit allem, was Zeit braucht, kann man auch dadurch eine Cover-Channel-Attacke fahren. Und hier die Laufzeit von dieser Anweisung hängt von operanten ab. Und ein paar Leute haben es geschafft, die Firefox-Same Origin-Policy zu umgehen mit diesem Angriff. Und die Jump-Instruction ist auch ein Problem. In gewissen CPUs hat man Brunch-Prediction und Brunch-Tiger-Prediction. Und das wurde zwar schon im Detail untersucht. Und da kann man Cover-Channels machen, Side-Channel-Attacks auf Krypto und das Kernel-ASLA umgehen. Die TSX-Instruction-Set ist eine Erweiterung für Hardware Transactional Memory Support. Und damit kann man auch Kernel-ASLA umgehen. Also abschließend, also CPU-Design, die ganze Sache ist mehr ein Problem, was CPU-Design als ein Instruction-Set-Problem. Und all diese Sachen sind sehr, sehr schwierig zu flicken. Und sie haben alle mit Performance-Optimization zu tun. Und wenn man jetzt das flicken will, müsste man quasi die Optimierungen rausnehmen. Es gibt ein paar Vorschläge, wie man die Cache-Attacken abschalten könnte. Und das Problem ist, dass all diese schnellen Flick-Patches würden nicht funktionieren, weil da müsste man Instruktionen entfernen. Wir finden immer wieder neue Instruktionen, die Informationen rausgeben, die sie nicht sollten. Also vielen Dank für Ihre Aufmerksamkeit. Und wenn ihr noch Fragen habt, dann werden wir die gerne beantworten. Vielen Dank für den Vortrag. Wir haben jetzt kurz ein Frage- und Antwort-Session haben. Geht doch bitte zu den Mikrofonen und die sind jeweils in diesen Gängen. Ah, nee, es ist jetzt da. Es sind beide da. Und wenn wir warten, werden wir von unserem Signalangel Fragen haben. Es gibt keine Fragen von der Mikrofon-Fragen, bitte. Hi. Können Sie mich hören? Ja. Versuch's nochmal. Können Sie mich jetzt hören? Also ich würde gerne wissen, was eure Stealthiness-Metric war. Könnt ihr es von einem normalen Prozess unterscheiden? Also die Frage war zu dieser Stealthiness-Metric. Also wir haben diese Metric verwendet mit Cache-Misses und Cache-References, normalisiert über Instruktions-TLB-Ereignisse und haben einfach eine Schwelle festgelegt und praktisch alle normalen Applikationen waren drunter und alle Angriffe drüber. Also wir haben einfach diese Schwelle gewählt, um die Applikation zu unterscheiden. Das andere Mikrofon. Vielen Dank für den Vortrag. Das war super. Die erste Frage. Habt ihr Intel informiert, bevor ihr diesen Talk hier gehabt habt? Nein, haben wir nicht. Die andere Frage ist, was sind eure zukünftigen Pläne? Also ich fand es interessant, dass wir diese Angriffe mehr oder weniger per Zufall finden und interessant wäre, wenn man irgendwie eine automatisierte Möglichkeit hätte, diese Sorte von Angreifen weiterzufinden. Hallo, eine Frage. Wenn ihr einen Dämon habt, der einfach zufällig irgendwelche Cache-Lines invalidiert, wäre das nicht besser, wenn man ein Cache abschalten würde? Ja, also wenn man die Cache-Lines invalidiert, wäre das besser. Wenn du weißt, welche Cache-Lines von einem Prozess einfach benutzt werden, dann könnte man genau diese auswerfen, wenn man Prozesse wechselt. Oder wenn man Prozesse wechselt, könnte man den ganzen Cache flaschen. Dann ist es leer, dann sieht man keine Aktivität mehr. Also ja, das kann man machen, aber es ist natürlich wieder ein Performance-Problem. Vielleicht eine zweite Frage. Es gibt Arme-Architekturen, die die Random-Cache-Line-Innovation haben. Habt ihr das ausprobiert? Wenn Sie wirklich zufällig sind, aber ich meine, in der Praxis muss man wahrscheinlich einfach mehr Messungen machen, um das Rauschen rauszufiltern, und dann kann man wieder diese Angriffe machen. Also wie einfach, wenn man mehr Rauschen hat, dann braucht es einfach mehr Messung. Bei Arme ist es angeblich Zufall, aber tatsächlich haben wir angenehme Technik um diese Pseudo-Zufälligkeit rauszufiltern. Also wenn es wirklich Zufall wäre, dann würde es funktionieren, aber das ist sehr schwer zu implementieren. Also ich denke nicht, dass wir einen echten Zufallstallgenerator wollen, nur für den Cache. Es gibt ja noch drei Leute. Meine Frage ist über ein Detail für diesen Key-Logger. Er kommt zwischen Space, Backspace und Alphabet, und erscheint, könnt ihr auch herausfinden, was genau für Tassen gedrückt wurden? Es kommt auf die Implementation der Tastatur drauf an. Also wir haben das Stock-Keyboard verwendet, das mit Samsung kommt, also das vorinstallierte Keyboard, und wenn man irgendwo eine Tabelle in deinem Code hat, also wenn man zum Beispiel diesen Ort drückt, dann ist es ein A und diesem Ort ist ein B. Also wenn man das hat, dann kann man vorgeschritten an Angriff fahren. Also man muss einfach, ja, im Prinzip diese Tabelle definieren in deinem Code. Wenn man das hat, dann kann man tatsächlich den einzelnen Tassentrock identifizieren. Vielen Dank. Hi, thank you for your talk. Meine erste Frage ist, was können wir jetzt genau machen, um diese Attack dann ein bisschen auszuheben? Das Wichtige ist, Krypto zu schützen. Und heute wissen wir, wie man Krypto baut, das Geschütztes von dieser Angriffe. Also ich meine, ja, macht es einfach nicht so, wie es schlecht gemacht ist heute. Also das kann man besser machen. Aber ich denke, Krypto alleine zu schützen ist machbar, alles zu schützen, ja, weiß nicht. Ja, wenn Intel und ARM das wirklich reparieren wollen, dann kann man da sicher noch was machen. Nach der Systemseite, wenn man irgendwie Speicherteilen verhindert, dann ist Flaschen reload, hat viel mehr Rauschen. Also das wäre zum Beispiel eine Verbesserung. Vielen Dank. Also wir haben keine Signalangel gefragt. Hallo, ich wollte fragen, wie ihr genau diesen Side Channel aufbaut. Es muss ja irgendwie synchronisiert sein, damit man diese Informationen übertragen kann. Habt ihr es irgendwo dokumentiert, wie das genau gemacht wird? Gibt es da irgendwie sieben Schichten oder so? Ich wäre sehr interessiert, wie das funktioniert. Ja, du findest diese Informationen im Paper. Also es gibt eine Handvoll Papers über Cover-Channels. Ja, das Paper kommt im Februar raus und das Amageddon-Paper, da steht auch noch was drin und da findet man raus, wie genau die Synchronisation funktioniert und so weiter. Okay. Hi, ihr habt erwähnt, dass ihr Angriffe braucht für die AES Side Channel Attacken und benutzt ja auch Round Table Angriffe und Schedule Manipulation. Ja, da haben wir ja nur ein paar synchronen Angriffe gemacht. Also wir wussten vorher, wann der Victim gescheduled wird. Okay, vielen Dank. Ich sehe keine weitere Fragen mehr. Vielen Dank für die Vortragenden.