 Ich habe Schofenburg und fütze Alldorf aus der Universität in Begen und gehört aus halt der Professor für Cybersecurity in Birmingham und sie reden über die vertrauenswertiges Ausführungseinheit zum Beispiel von Italien und so weiter und vielleicht soll hier es nicht so vollständig vertrauen, weil es ist Software und alle Software hat Probleme und sie reden, wie man die Inklaven einlaufen kann, eine systematische Analyse der Sicherheitsprobleme macht. Willkommen zu unserem Vortrag, ich bin Joe von der Universität Fritz Wir haben einen sehr interessanten Talk über, wie man in Inklave Tore einrennt und viele fragen, was Inklaven sind und was das Ganze ist. Also lasst mich erstmal ein bisschen einfügen mit ein paar Termen. Inklaven sind grundlegend das eine sichere Sfort im Prozess der CPU. Das ist ein verschlüsselten Arbeitsspeicherbereich, der nur von innen benutzt werden kann. Und was hier aus den letzten Verteidigungsangriffe auf Burgen ist, wenn alles stark ist, dann versucht man die Tür anzugreifen, das ist die schwächste Punkt. Und das ist die Idee dieser ganzen Forschung. Das funktioniert auch mit Inklaves und wir haben das Input und Output Interface eingerannt. Wir haben die unterschiedlichen Sachen uns angeschaut. Wir haben über 40 Interfaces, die wir angreifen können, mit unterschiedlichen Inklaveprojekten, die absurde sind. Das heißt, wir werden uns die Details jetzt im reitere Teil anschauen. Auch eine nette Sache, die wir sagen können, wir haben zwei unterschiedliche Paper darüber geschrieben, sieben CVEs und insgesamt einige Responsive Disclosures und viel Embargo-Daten. So, die Frage ist, warum brauchen wir überhaupt Inklaven? Wofür sind die überhaupt notwendig? Wenn ihr traditionelle Tripsysteme anschaut oder traditionelle Computerarchitekturen, hat man eine sehr große vertrauenswürdige Computerbasis. Das heißt, wenn ihr ein Laptop benutzt, um diesen Vortrag zu sehen, dann vertraut ihr die Körne, ihr vertraut vielleicht einem Hypervisor, wenn ihr irgendwelche entsprechende Software habt auf dem CPU, Arbeitspeicher, vielleicht die Festplatte, ein TPM-Modul und so weiter. Mit so einem großen Bereich, der angegriffen werden kann, dann kann noch überall Sicherheitslücken existieren, vielleicht auch irgendwelche Viren. Und die Idee von diesen Inklaves ist, wie zum Beispiel bei Intel, die Idee dahinter ist, man nimmt den Großteil des SoftwareStacks inzwischen der echten Anwendung und der echten CPU aus dem vertrauenswürdigen Bereich heraus. Das heißt, im Endeffekt, man vertraut nur der CPU und man vertraut seinen eigenen Code. Aber man muss den Betrieb systemlich mehr vertrauen. Und das Ziel ist es, gegen einen Verteidiger sich zu verteidigen, zum Beispiel eine, wo jemand anderes Route hat oder wenn man in einer Wolke oder in der Cloud etwas ausführt, man kann mit Hardware-Level in vielen Sachen auf einem fremden Computer ausführen können. Man muss dem Administrator nicht mehr vertrauen. Das Problem dabei ist natürlich, dass der immer noch allein das Schutzstelle ist, also vorherige Angriffe und vielleicht wird da einer andere hier auch vorgestellt auf diesem Remote-Congress. Viele haben die Mikroarchitektur der CPU angegriffen. Das heißt, wir greifen den Hardware-Level an, Foreshader und Fidder, Spectre, zum Beispiel. Und was weniger angeschaut wird, ist der Software, die in der Inklave läuft. Es gibt irgendwelche Software, die man vertraut und wir schauen uns weiter an, was es wirklich in so einer Inklave davon, wenn man sich die Software anschaut. Man kann einen Angräfer klassischen Software-Wachs ausnutzen. Ja, das ist ein sehr interessanter Randehensweise. Lass uns mal die Software anschauen. Das heißt, wir müssen erst mal anschauen, wie sieht die Software-Umgebung für diese Inklaves aus und werfen aus. Und da haben Sie analysiert. Hier habt ihr ein Beispiel, das ist eine große Ego-Systeme mit vielen, vielen Laufzeitssystemen, die open source sind. Was haben Sie gemeinsam? Was ist die Idee in der ganzen Entwicklungsumgebung? Was jede vertranswürdige Ausführungsumgebung hat, ist, dass sie eine sichere Inklave hat in einer feindlichen Umgebung. Das heißt, man kann in der Kiste sicher rechnen und drumherum die Welt ist brennt und alles, und das ist egal. Aber wie immer ist der Problem, dass es um die Details geht. Wie arbeitet man in einer Welt, wo der Umgebungswelt brennt und wir haben unser eigenes Sicherheitsbereich. Man braucht eine Software-Schicht dazwischen, einen geschützten Kontakt oder eine sichere Brücke hat von der unsicheren Welt in die Inklave und zurückgeht. Und wir wollen uns anschauen, welche Sicherheitschecks hier durchgeführt werden müssen um das zu realisieren. Hier ist ein wunderschönes Bild. Links, rechts aber die gute, schöne Inklave und links die gefährliche Wüste. Und die Frage ist, was passiert, wenn die Brücke selber ein Problem hat. Und diese Frage zu beantworten, müssen wir uns diese gelbe Kiste anschauen und fragen uns, welche Sicherheitsüberprüfungen müssen wir machen, um wenn wir von der Außenwelt in die Innenseit-Welt gehen, in die Inklave gehen. Es ist etwas, was wir in den letzten Jahren gezeigt haben, dass diese gelbe Kiste in zwei Teile produziert werden kann. Wir haben zwei unterschiedliche Schichten. Der eine Teil ist das AVI, die niedrige CPU-Level und das zweite ist die API. Und das ist, wie die Software das sieht. Und der Rest dieses Vortrags reden wir durch ein paar relevante Sicherheitslücken in beiden dieser Schichten und erklären, was es bedeutet. Zuerst zu Allererst Spritzwell, die interessante Low-Level-Umgebung in der AVI. Ja, du sagst, es geht um die CPU und die Nährstatus. Und die Frage ist, was bedeutet das eigentlich? Es bedeutet, dass der Anreifer den Inhalt von den CPU-Registern kontrolliert. Und in jedem Eingang in die Inklave und in jedem Ausgang wissen wir über Prüfen, einfach ein paar Schritte machen. Und die Inklave und die vertrauenswürdige Laufzeit-Umgebung hat wohl initialisierten CPU-Status. Und der Compiler kann mit den aufrufigen Situationen in erwarteten Aufruf-Situationen arbeiten. Wir müssen die CPU-Register initialisieren, wenn wir die Inklave betreten. Und wir müssen sie brennigen, wenn wir die Inklave wieder verlassen. Und wir können nicht vermuten, dass irgendwas der Anreifer gibt. Wir müssen aufpassen, dass es richtig ist. Und wir haben unterschiedliche Run-Time-Umgebungen uns angeschaut. Und wir haben viele Sicherheitslücken gefunden, die in dieser Abilayer existieren. Und eine große Sache, die wir dabei gefunden haben, ist, dass viele dieser Sicherheitslücken bei Zisk-Prozessoren passieren. Und insbesondere halb bei Intel SGX. Wir haben auch ein paar Reduced-Instruction-Set-Prozessoren angeschaut, also RISK-Prozessoren wie zum Beispiel ARM. Und es ist klar, dass diese komplexen APIs viel größerer Angriffssitzstelle haben als die einfacheren. Und hier ist ein Beispiel in komplexerem Design. Hier ist der X86 String-Instruction, die von einem Direkt-Inrichtungsfleck haben. Also diese Rep-Funktion, die es ermöglicht, String-Operationen zu betrachten. Zum Beispiel, wenn man einen Buffer beschreibt, dann wird das halt in so einen Rep-String-Operation umgewandelt. Und der Buffer wird gelesen, aus links nach rechts, und wird überschrieben. Und diese Richtungsfleck bedeutet aber, dass wir auch in die andere Richtung gehen können, von rechts nach links, also rückwärts. Ich denke, wenn wir mal nicht darüber nachfahren, warum das eine gute Idee war und warum das gestarrt war, aber es ist möglich, die Richtung zu ändern und rückwärts durch den Speicher zu gehen. Und das System VAB sagt, dass es für Vorwärts gesetzt werden musste. Und Kapital erwarten, dass das passiert, aber was ist, wenn das nicht passiert? Wenn unsere Vertrauens-Würde-Operation diese Memset auf dem Buffer durchführt und mit dem normalen Direktionsfleck, dann gehen wir normalerweise von vorne nach hinten durch. Dann ist also alles in Ordnung. Also praktisch korrekterweise von vorne nach hinten. Wenn also ein Angreifer, die in die Hinterklappe reingeht, dieses Fleck aber auf 1 gesetzt hat, also auf rückwärts gesetzt hat, heißt das jetzt, dass vom Anfang unseres Buffers, wo unser Pointer jetzt hin zeigt, seht ihr, dass das Ganze jetzt rückwärts läuft. Das ist natürlich ein Problem. Das ist etwas, was wir nicht wollen in unseren Vertrauens-Würdingung-Gebungen, weil es uns erlaubt Schlüssel zu überschreiben. Es erlaubt, viele Dinge tun die nicht wirklich sinnvoller sind. Wir haben das Ganze also veröffentlicht. Wir haben einen CVI zugewiesen bekommen, wie ihr hier auf dem Slide sehen könnt, auf dem, wo ihr sehen könnt. Man muss also daran denken, diese Flecks zu setzen, alle Flecks zu verifizieren, aber es gibt immer noch etwas mehr. Also wie wir Haus gefunden haben, gibt es Fließkammer einheiten und viele, viele ähnliche Dinge erlauben. Ich lasse die ganzen Details jetzt mal weg, aber in dieser Präsentation, sagen wir einfach mal, dass wir in ältere, in 87 Einheiten gibt es das FPU-Kontrollwort und das MXCSR-Register in neueren Einheiten. Obwohl die X780er älter ist, benutzen wir z.B. die GCT, die für lange Fließkammer zahlen. Beide sind also entsprechend immer noch relevant. Obwohl, also diese alten Dinge, man kann sagen, dass sie veraltet sind, werden sie immer noch genutzt. Und wenn man sie jetzt auf die System 5 AWI schaut, dann sind die entsprechende Register jetzt vorm Aufrufenden gespeichert, also über entsprechende Aufrufe hinweg transportiert. Die Status-Bits sind aber globales Status-Bits. Also eine Applikation kann einen so einen globalen Status setzen und das wird über die ganzen Lauf der Vergangenheit behalten. Das Problem hier ist, unsere Inklave ist allerdings eine entsprechende Applikation und unser Angreifer kann das jetzt entsprechend manipulieren. Was also passiert? Was also passiert, wenn wir bei einem normalen Benutzer, wir machen einfach ein paar Berechnungen da, wir machen eine 2,1 x 3,4 und das, da kommt dann 7,14 raus, wie erwartet. Aber was passiert, wenn der Angreifer in die Inklave reingeht und die entsprechenden Präzisions- und Wundungsregeln komisch letzt und da kommt dann, ich habe bei unserem Fall, etwas ganz anderes heraus. Das ist etwas, was wir definitiv nicht mehr nicht möchten. Das ist, der Entwickler erwartet eine bestimmte Genauigkeit in der Berechnung, aber Präzision. Das passiert allerdings nicht, wenn der Angreifer, die in Plaventschränke aufräuft. Wir haben also, wir haben uns also auch an Microsoft weitergeleitet. Das ist nicht ausnussbar, also interessant, dass das Internet-Xrestor hat das gepatched mit einer X-Restor-Infektion, die kundigen kompletten Status auf einen bekannten Wert ist, wo hingegen oben entklarf nur den entsprechenden Wert auf seinen zu ersten Wert. Wir können vielleicht dieses spezielle Register setzen, aber es gibt ein weiteres Fleck und damit kann der Angreifer jedes beliebige Blitzkommairgebnis als Not-a-Number bewirken. Das ist ein stilles AVE-Problem. Wir haben also das auch entsprechend weitergeleitet und glücklicherweise haben jetzt danach dann also alle eklamen One-Time-Entwickler X-Restor verwendet. Also in die ganzen kleinen Details möchte ich nicht reingehen, oder was es macht, aber nur zur Gruppe, was die Idee, warum das ein Problem sein könnte. Wir haben also in diese Probleme reingeguckt, ob die virologisch sind, und wir haben herausgefunden, dass wir diese Überläufe als Seitenkanal nutzen können. Zum Beispiel kann man z.B. mit Acceptance unmaskieren. Er hat dieser Enklave, die abhängig von der entsprechenden Eingabe ausgelöst werden oder nicht. Darüber können wir das in der Enklave benutzen, um zum Beispiel eine Binär-Suche innerhalb des Eingabenraums durchzuführen und entsprechend über eine deterministische Anzahl von schlüssendem Material herauszufinden. Man kann sich auch mehr tun. Wir können also entsprechend auch Maschinen-Learning in den Enklappen machen. Z.B. kann man innerhalb der TEE durchführen. Zum Beispiel die Erkennung von Handschrublichen zu fallen. Wir haben zwei Nutzer. Ein Nutzer schiebt also die entsprechenden Modelle in die Enklave. Der zweite Nutzer schiebt Eingabe-Werte in die Enklave. Aber der zweite Nutzer kann also dieses FPU-Register entsprechend verändern. Er kann also die Fehlerrate von diesem Erkenner hochtreiben auf die Art und Weise, über die verminderte Präzision, von 100% korrekt auf 8, nur 8, noch 8% korrekt. Also dieses Modell komplett loszumachen. Wir haben noch mehr getan. Wir haben Länder angreifen über kleine Differenzen in Bildern. Das ist einfach nur um euch zu zeigen, dass das ja nur um zu zeigen, dass hier Dinge auf dem ABI-Level sehr viel schneller geben können. So, das ist also über die TPU-Status. Jetzt reden wir mehr über die... Danke, Pritz. Wir haben ein sehr einfaches Beispiel hier genommen. Lass uns also annehmen. Wir nehmen also einfach an, wir laden einen Standard-Unit, ein Unitspannery in den nächsten Enklave. Und was ich hier illustrieren möchte mit diesem Beispiel, ist, dass es sehr, sehr wichtig ist, wo Pointer herkommen, wo Zeiger herkommen. Weil die Enklave sowohl in nicht-vertrauenswürdigen als auch im enklaven-Speicherbereich-Map. Nehmen wir also an, wir haben also ein einfaches Echo als binary, dass es einfach nur ausgibt, was es da rausgibt. Und normalerweise zeigt er normalerweise an irgendein Stringsprachter, Hello World, der in dem nicht-vertrauenswürdigen Speicher steht. Wenn alles also läuft, wie geplant, dann bekommt die Enklave-Zudruf zu nicht-vertrauenswürdigen Speicher. Aber das Problem ist, dass die Enklave auch Zudruf auf ihren vertrauenswürdigen Memori hat. Wenn also ein Angreifer, für das ein Zeiger auch enklaven-Speicher-Effekt zurückgibt, was dann etwas passieren wird, dass die Enklave jetzt auf diesen Zudruf und dem aufgibt. Das heißt, wir haben also jetzt eine Sicherheitslücke, in dem der eigentliche Zudruf-Speicher auf den eigentlichen Zudruf-Speicher lebt. Wir haben also hier ein einfaches Hello World binary. Wir lassen das also entsprechend laufenden, aber mit modifizierten Beicher-Adresse. Normalerweise soll es Taflausgeben, aber hier gibt es ein String aus, der eigentlich nur innerhalb der Enklave-Zugrufe ist. Also, diese Art, die hat wirklich noch nicht bekannt im Bereich der Kernelforschung. Also, der Enklave-Memory, und derzeit, der nicht supposed to do, ein Greifer kommt also entsprechend. Eigentlich sieht es so aus, als könnte man das recht einfach mal prüfen. Schaut immer, wenn die Pointer rum sind, wo die herkommen. Und der hat gedacht, wir sollten alle Pointer-Checks überprüfen, und wir haben festgestellt, diese Methodik hat sie zu überprüfen. Der Intel-Code ist gut, der überprüft alle Pointer, aber man muss etwas Spezielles für Strings machen. Wir reden hier über C, d.h. Strings-Banden mit einem 0-byte, und man kann Strillen benutzen, um den Länge des Strings zu berechnen. Und jetzt schauen Sie mal, ob ein String komplett außerhalb des Arbeitsbrechen überrechter Enklaves ist. Man berechnet, wie lang der String ist, und dann schauen wir, ob der Anfang und das Ende komplett außerhalb der Enklave ist. Erstens mal schauen, wenn wir diesen String außerhalb der Enklave passen. Der erste Schritt ist, die Enklave berechnet die Länge des Strings überhalb der Enklave. Das ist schon ein bisschen komisch. Alles sieht gut aus, sollte eigentlich nie gemacht werden. Das String ist innerhalb der Enklave, und wird der Aufruf abgebrochen. Das ist in Ordnung, aber ein paar von euch, die Seitenkathale benutzen wissen, dass es interessant ist, weil die Enklave hat eine Berechnung gemacht, die es nie machen sollte. Die Länge, das ergeben, ist die Frage, wie viele nicht 0-bytes in der Enklave sind. Die Zeit, die sie braucht, um falsch zurückzugeben, beträgt davon ab, wie viele 0-bytes in der sicheren Enklave existieren. Und das, was wir gefunden haben, wir waren vor drüben, und haben gesagt, oh, ein kleiner, einfacher Timingangriff, und wir hießt uns ein Graph, und es ist nicht so einfach, wie wir dachten. Die blauen, das String länger, 1, die roten, 2, und 3, dass die sich einfach so sehen. X86 ist super schnell. Das heißt, eine Einzige im Element ist einfach nur ein Teil der Pipeline. Man sieht das nicht mehr, wenn nur viel Zeit achtet. Wir brauchen was anderes. Also haben wir uns Favors durchgelesen, und der Beispiel angriffen ist etwas, das auch von Intel beschrieben wird, man kann sehen, welche Arbeitsspeicherbereiche zugriffen werden, während die Enklave ausgeführt wird. Weil das Form vom Betriebssystem bewacht wird. Wir haben zu belegt, das ist ein selteres Seitenkanal, und wir haben den Code angeschaut und einen sehr einfachen Forlup, der innerhalb von einer Seite passt und einen kurzen String, der in einer Seite passt und vier Kilobytes Arbeitsspeicherregionen sind nicht sondern nicht interessant. Weil der Code und die Daten auf eine Seite passen und das ist die temporäre Zugang zum Seitenkanal. Das heißt, es ist nicht genau genug. Und hier haben wir einen interessanten Framework gearbeitet, ein bisschen Interab, und das ist eine bekannte Open Source Framework, und das heißt LibSGX Step und kann in eine Enklave jedes Ausführungschritt unterbrechen. Und jetzt schauen wir mal, was wir damit gemacht haben für den Forlup aus und nach jedem Interab schauen wir, ob die Enklave in den String der Datenaufruf hat. Und wir zählen einfach wie viele Schritte es gemacht wird und dann haben wir einen deterministischen qualitativ vorfaltigen Angriff. Das heißt, wir haben einen Oracle, das uns alle Nullbytes in der Enklave findet. Wir wissen nicht, wie viel Sicht das ist. Ja, anscheinend ist es hilfreich. Es ist immer gut zu wissen, ob irgendwo Null im Arbeitsspeichel ist. Und wir haben jetzt ein Beispiel, wo der ASMI, die Hardware-Beschleunigung von Intelliprozessoren für IEI durchbrechen. Das arbeitet ausschließlich auf Register. Wir können das mit Pointer machen mit Arbeitsspeicher. Aber es gibt einen anderen Trick, den wir hier benutzen. Wenn die Enklave aufgebrochen wird wird es irgendwo im Arbeitsspeichel gespeichert und wir können die Enklave abbrechen. Wir sagen, dass sie ihren Arbeitsspeicher in die und dann können wir den Nullbyte Oracle laufen lassen und dass sie dabei finden, ob der Nullbyte im SSR-Status ist. Wir wollen nicht die genauen Sachen anschauen, aber immer wenn da im Status eine Null ist vor der letzten IS-Runde dann wird der Schritt durch die S-Box im Keyboard multipliziert werden und dann kriegt man den Cypher Text. Aber wir wissen den Cypher Text und wir können zurückgehen und wir können den Null vom XOR berechnen und wir können hierhin berechnen und das heißt, wir können hier ein Keybyte berechnen. Wir machen das ganze 16-mal bis wir in jede Byte der Status vor der letzten Runde befunden haben und die gesamten Schlüssel der letzten Runde und wenn man einen Rundenschlüssel hat dann kriegt man den ganzen Schlüssel und wenn wir den Rundenschlüssel haben dann kann man rückwärts gehen. Hört sich sehr komplex an aber es ist ein sehr schneller Anteil wenn man es darauf sieht, hier wird der Angriff durchgeführt und wir sehen in wenigen Sekunden 512 Aufrufe von IS später haben wir den ganzen Schlüssel und es ist sehr toll weil eine der Sachen bei IS und I nichts im Arbeitsspeicher hat aber in dieser Situation bedeutet es dass es trotzdem Sachen in den Arbeitsspeicher legt. Wir haben unterschiedliche andere Angriffsektoren gefunden die in den Forschungskot als auch in Produktionskot und die haben das Samtensicherheitslücken die wir schon häufiger gefunden haben vom Benutzerkot bis zum Kernelskot und wir haben auch ein paar neue Sicherheitslücken gefunden in die Endpaderaspekte benutzt, die wir hier erklärt haben es gab auch noch ein Problem mit Outcalls die was wir denn draus geben wird, wenn man als ein System ausprobieren möchte und wenn man dort falsche Ergebnisse zurückgibt kann man immer noch außerhalb des Bereiches gehen und es gab auch viele und dann haben wir noch ein paar Probleme gefunden mit Padding Sachen wo Daten durch das Padding ausgeführt wurden und wir haben eine echte Welt gelernt es ist immer wichtig wie es die Hände waschen ist es genau so wichtig ist dass man die Punkte überprüft dass der Status überprüft wird das ist eine der Sachen die wir hierbei mitnehmen ja um in Klafen zu bock sicher zu machen muss man den Hardware fixen aber man muss auch ABI und API Sectorisierung betreffen es ist ziemlich komplex das zu machen wie wir in unserem Vortrag gesehen haben es gibt eine große Angriffstelle weil das Angriffsmodell sehr komplex ist wenn man nach jedem Angriff abbrechen kann und was an der Forschungsperspektive ist das müssen wir da genau gemeinsam Kundenplägen haben und nicht einfach Bucks suchen haben wir schon ein paar mal darüber geredet wie man mit Form Bürze und Körner ein bisschen darüber nachdenken was eine Inklave machen kann darüber was ein Körner machen soll es gibt auch ein paar relevante Unterschiede die wir uns anschauen müssen und wie ich gesagt habe Allerzer Code ist Open Source das heißt ihr könnt sie unten im Github finden und ihr könnt auch im Vortrag eine Frage stellen nachdem der Vortrag angeschaut hat ja hallo ich bin wieder da die Fragen schön es euch zu sehen das ist eigentlich interessant ich denke diese Forschung hat über die Jahre gebaut und es gibt also ich denke die Variabilität von unserem Initialpapier habe ich eigentlich schon starten in meinen Masterpieces zu sehen und zu collecten und wir haben nicht wirklich gesehen eine große Bildung bis ich David und seine Kollegen an einem Event in London die Reisekonferenz und dann haben wir starten zu koalibrieren und zu schauen ob es ein bisschen mehr systematisch ist also habe ich starten mit dieser ganzen Liste von Vulnerabilitäten und dann mit David haben wir etwas mehr systematische Analyse und das war auch ein bisschen von Pandora's Box ich darf es sagen von dem Moment an diese gleichen Ärzte und dann auch Fritz, die unsere Team in Leuven started working together with us on more of these low levels and that's Pandora's Box in itself, I would say eine der Sachen die wir dabei gemerkt haben ist x86 ist sehr komplex und die ganze Komplexität die wir haben kann missbraucht werden bei einem Angreifer es ist mehr so ein Fractal ihr löftet eine Kiste und ihr findet mehr Fragen aus der Kiste und ja im Endeffekt ich glaube es ist gut zu sagen, diese Vorschung ist nicht die letzte Hauptwort auf die ganze sondern es ist ein Schritt systematisch auf die Probleme zu schauen auf eine nie endenden Version es gibt eine Frage aus dem Internet gibt es irgendwelche Umstände in den IS wo seine Registrier in den Speicher speichert oder ist das exklusiv in SGX soll ich das nochmal wiederholen ich verstehe die Frage selbst nicht so ganz also ich glaube die Frage ist diese IS-Attacke die ich angeschaut habe die hängt praktisch davon ab dass wir, dass man praktisch an die Inhalts des Hauptschweichers kommen dass also die Registrier in Hauptschweichen geschrieben werden das ist jetzt also spezifisch für diese Angriffe ich würde allerdings sagen die Lektion die wir in den letzten 5 Jahren gelernt haben ist, dass das generelle Konzept von TPU da ist das auf die eine oder andere Art bei TPU Register immer irgendwo in Speicher enden also ein Betriebssystem dazu springen können einen Contextswitch zu machen dann landst du die Registrierprecher immer im Hauptschweicher und dann dann sobald das passiert, können wir einen ähnlichen Eingriff auswerten aber vielleicht möchte David etwas darüber sagen über Betriebssysteme ja, nicht wirklich eine Sache die also eine Sache die uns bei X-Hilf ist, dass wir da sehr genau eine Rolle haben, über Interwaft und so weiter weil wir praktisch von außerhalb der Entlage da reinspringen wir können also genau sagen wo hier was ein genau welchen Punkt der ein Interwaft im Betriebssystem gefolgt wird das heißt aber sobald man einen Contextswitch hat muss die TPU halt nun mal irgendwo die Registrierprecher in der eine oder andere Anweise vielleicht nicht so genau kontrollierbar wie im Falle von X-GX aber trotzdem es gibt hier die Frage wie sieht es mit anderen CPU-Architekturen aus außer Intel habt ihr euch die mal angeschaut ich sage auch dazu also Intel X-GX ist so die größte die mit der großen Software-Infrastruktur die mit den meisten One-Times, die wir reinschauen konnten aber es gibt natürlich auch andere zum Beispiel wir haben diese Eternity es ist bei Sankos entwickelt worden und für die gibt es natürlich ähnliche Probleme man braucht immer eine Software-Schicht um im Klaren zu interagieren, da rein zu gehen, da raus zu gehen und David hat auch in unserer TE etwas gefunden es ist also praktisch nicht nur ein Problem mit Intel aber was wir definitiv herausgefunden haben, dass es viel einfacher ist an all diese Edge-Case, all diese Randfälle zu denken in dem Fall bei einfachen Architekturen bei der Komplexen 86er-Architektur und das Problem hat also auch das Problem dass die die Erstentrennungslautbrechen wieder rauskommen sobald einfache Designs verbreitet sind, wird viel einfacher sein, die ganzen Randfälle für einfachere Designs auch rauszuwerfen was ist eine vernünftige Alternative gibt es überhaupt eine vernünftige Alternative zu TE soll ich was sagen was soll ich sagen ja wir können vielleicht unsere Perspektive mal beschreiben wir denken die Frage brauchen wir brauchen wir eine Alternative oder brauchen wir etwas es ist symptomatischerweise die Aufrufe zu validieren wir können vielleicht schauen wie wir diese Probleme können, aber davon abgesehen gibt es sehr interessante Forschung über die entsprechenden Sicherheitslücken dass die die nicht so nicht so unendlich sind für TE, aber wenn man z.B. HP-Unterstützung dafür hat z.B. Jerry Prick die praktisch an einen Freund der Metadata ran schreibt und das könnte dafür sorgen dass wir diese Zeigerangriffe automatisch über die Hardware anfangen können das ist vielleicht eine Idee von ganz oben ich glaube als Alternative zu TE immer man das eigene System partitionieren will verschiedene Abschnitte was ich denke ist eine gute Idee die wir nun mal Online Services bauen dann TE nun mal das System was sehr häufig benutzt würde in Mobiltelefonen oder Bankkarten die auch Geschützungsumgebungen sind das Problem ist über Beginn, sobald man da ein ganz auf Funktionalität reinwerfen dann wird nämlich die vertrauenswürdige Kurtbasis größer und größer dann kommen mehr und mehr Bugs rein die Frage ist brauchen wir eine Alternative oder kennen wir den die Aufgabe unser System zu partitionieren vielleicht ein ganzer Mann hier wir können z.B. Archivuren bauen mit bestimmten Fähigkeiten aufbauen und die dann unterschiedlich isolieren z.B. TLS stack in unserem Web App Server vielen Dank an allen Leute die dieses geheime Passwort da gesehen haben das natürlich nur für Dekorationszwecke hier ist also das ist nicht fundamental kaputt S.J.X. nicht den hier S.J.X. sondern es gibt ja nochmal sehr viele von denen und total kaputt können wir vielleicht nicht sagen die Frage ist für S.J.X. denn auf dem Signal Laufen, Crypto Coins laufen und dergleichen ist das jetzt fundamental kaputt oder würdet ihr eher sagen so ich denke davon ab was man jetzt fundamental kaputt bezeichnet in der Vergangenheit hat es durchaus volle Einbrüche in den Krieg gegeben die sind aber mittlerweile wieder repariert worden das heißt das forschen auf kurze Sicht entsprechende Einfluss auf dieses wie haben wird man findet eine Sicherheitslücke dann wird der Entwickler informiert der baut entsprechende Work-Awards rein und danach muss man gucken ob man irgendein Grundlegende für das Problem findet wenn also eine Firma S.J.X. nutzt gibt es einem natürlich nicht einmal Sicherheit in jedem einzelnen Fall sondern muss auch wie man hier in diesem Talk gesehen haben wo viele verschiedene Dinge gucken Mikrochord-Patches die ganzen anderen Sicherheitslücken wieder durch reinkommen und die Frage bleibt natürlich immer noch welche von den Problemen kennen wir dann noch nicht aber vielleicht möchte David noch einfach zu seiner letzten Arbeit sagen ja ich glaube was Jules sagt oder meine Antwort auf die Frage ist hängt tatsächlich von eurem Angreifermodell die Leute sind S.J.X. auf eine Weile oben weint man nicht mehr nötig zu machen dass man den Cloud Provider vertrauen muss was innerhalb von einem Cloud Provider in einer S.J.X. entgegen dann heißt das ich dem Cloud Provider nicht mehr vertrauen muss gibt einem Vizientzug gegen entsprechende physischen Zugriff und dann verkurzt einem weiteren Angriff verablichen wenn man Haft-Kübers-Grufe dazu hat kann man entsprechende Angriffen machen wenn man die Zugriff auf die Bannungsregler auf den Mainboard hat kann man da entsprechende Spitschung auf der Spannungsversorgung machen wie ihr vielleicht in anderen Invented-Kontexten dann kann man in Haft-Kübers-Grufe und auf die über die Weise kann man diverse böse Dinge tun zum Beispiel um Schlüssel rauszuholen um den Kontrollfluss zu übernehmen ja, hängt also abhängig von deinem Angreifermodell würde ich nicht unbedingt sagen dass es in jedem Fall komplett sinnlos ist aber bringt auch kein vollständigen Schutt jemand der vollständigen Zugriff hat ich muss leider diesen Talk verenden was mir ärgert aber eine sehr schnelle Antwort was war jetzt mit dem Passwort aber eigentlich läuft es ein es war ein leeres ein leeres ein leeres Passwort und ich habe natürlich ein Passwort draufgeschrieben das macht man halt so so, vielen Dank vielen Dank wir haben uns wir machen jetzt die Transition zu der Herat News Show