 Danke. Ich bin Trampel Hudson und ich erzähle euch von Van der Strike 2. Das ist eine Firmware Schwachstelle bei MacBooks. Sie habt es vielleicht schon in der Zeitung gelesen, als den unglaublich geheimen Firmware-Backdoor, die man remote installieren kann. Man kann es quasi nicht entdecken und man kann es auch kaum entfernen. Das ist ziemlich viel Vertreibung in diesen Pressemitteilungen, aber ein guter Teil davon ist wahr. Es ist wirklich hart zu finden und es ist auch schwer zu entfernen. Es wird auf dem SPI Flash Chip aufgespielt. Auf den meisten Systemen ist das im Prinzip das Kernstück des Vertrauens. Die ganze Sicherheit des Bootvorgangs hängt an der Integrität dieses einen Flash Chips. Weil dieser eine Chip im Prinzip die erste Anweisung enthält, die ausgeführt wird beim Booten, kann man im Prinzip alles andere, was danach kommt, umgehen, was an Sicherheitsvorgängungen getroffen wurde. Das eigentlich erschreckend an diesem Talk ist, dass es nicht neu ist, sondern es besteht aus fünf verschiedenen vorher schon bekannten Schwächen in UEFI, die ich und andere Mitarbeiter schon mal gefunden und berichtet haben. Das ist der wirkliche Schlüssel dieses Talks, dass diese Firmware schwachstellen, dass die auf diesen verschiedenen Systemen vorhanden sind, weil die einfach so viel Gleiches haben. Man könnte denken, dass dieses hübsche, hübsche MacBook nichts mit diesem Asus zu tun hat. Es hat ein unterschiedliches Motherboard, ein unterschiedliches Betriebssystem drauf. Selbst je restlicher hat wer es anders, aber unter der Verpackung hat man letztlich das gleiche System. Es sind die gleichen Codeschnipsel, es sind die gleichen Funktionen, die aufgerufen werden. Es sind die gleichen Schwachstellen, die auftauchen. Sogar die gleichen Compiler sind vorhanden. Und selbst in verschiedenen Varianten gibt es sehr viele Gleichheiten in verschiedenen Systemen. Und das geht zurück auf die älteste Geschichte des PCs. Das IBM 16-Bit System Bios wurde von Phoenix geklont. Und sehr viel wurde da reverse engineered. Und dann hat irgendwann Intel angefangen mit der extensible firmware, das EFI. Und in den frühen 2000ern, als Apple auf Intel gewechselt ist, haben auch diese EFI benutzt für das System. Und viele, viele Jahre später, Intel hat dieses EFI in das EFI-Forum integriert. Und deswegen heißt es jetzt UEFI. Es hat viele, viele Funktionen, sicheres Buden. Und sie haben natürlich mit der Entwicklung auch weitergemacht. Zuletzt, am 25. Dezember, also kurz nach Weihnachten, manche davon sind sicherheitsbezogen. Und da könnte halt so ein Punkt eine Schwachstelle sein, auch um die Zeit. Da sind immer noch viele, viele Zeilencode, die zwischen dem Apple-EFI und der klassischen UEFI gleich sind. Apple hat den UEFI-EDK2-Baum übernommen. Die haben die aktuelle Version genommen und haben das auf die jeweiligen Hardware-Plattformen übertragen. Wenn das UEFI-Forum diese Bugs behebt, dann heißt es nicht automatisch, dass alle Hersteller auch diese Patches bekommen. Und selbst wenn sie das auf neuen Motherboards übernommen haben, dann kann es immer noch passieren, dass diese Legacy Systems dies nicht übernehmen können. Und selbst wenn es ein neues Firmware-Update gibt, dann gibt es noch keine Garantie, dass die Nutzer dieses auch installieren. Und das ist was Apple tatsächlich vorangetrieben hat, dass sie Firmware-Updates für die Systeme bis 10 Jahre in der Vergangenheit übertragen. Einfach um sicherzugehen, dass die Sicherheitslücken geschlossen werden. Das war jetzt die Geschichtsstunde und es geht weiter mit Thunderstrike 2. Wie ich schon erwähnt habe, es sind fünf verschiedene Schwachstellen, die integriert wurden. Alle Details sind schon 2013, 2014, 2015, aber teilweise auch schon bis 2007 veröffentlicht worden. Eines ist Speed Racer. Das wurde letztes Jahr offiziell vorgestellt auf dem vergangenen Kongress. Es gibt eine Race-Condition in verschiedenen Threads. Der Grund dafür ist, im Prinzip schon verborgen, in dem der veralteten Hardware, dem Intel Control, wurde damals für ein System, das nur einen Thread gleichzeitig bearbeitet hat. Wenn man das Bioslock in Applebit nicht setzt, dann hat SMM die Chance, das zu erlauben. Das ist aber eine Race-Condition, weil der zweite Thread das Bios-Ride in Applebit gesetzt hat. Das kann man im Prinzip beliebig oft wiederholen. Dann kommt man an eine Situation, wo man das ausnutzen kann. In 2004 hat Intel dann eine Migration durchgeführt, auf den Controller habe. Da haben sie ein neues Bit eingeführt, das Bios Protect Bit. Auf einem korrekt konfigurierten System wird die Ja, die sind durch verschiedene Schritte gegangen und haben das auch weitergegeben und haben diese Details auch auf verschiedene Hersteller weitergegeben. Die meisten Firma-Hersteller waren betroffen, weil sie kein Update gemacht haben, um die Hardware-Sicherheit sicherzustellen. Apple tatsächlich sagte, wir sind gar nicht betroffen, also müssen wir da auch gar nichts fixen. Aber es waren dann tatsächlich doch nicht so. Und dann haben wir immer noch hier das Datenblatt, das das Bios Control Register auf die sie DCH steht. Es gibt einen Tool namens Read Memory, das ist ein Open Source Tool, das genutzt werden kann, um arbitrieren Speicher auszulesen. Das hat einen Wert von acht. Das Bios Right Protect Bit, als auch das Bios Right Enable Bit, das die irgendwie gesetzt werden können. Und das war nicht die vorgeschriebene Konfiguration. Das heißt, das System hat das Ganze umgeschrieben. Und dann kann man halt auf das Bios drauf schreiben. Man kann nicht auf das komplette Bios schreiben, dass es da immer noch gesicherte Bereiche gibt. Aber es heißt immer noch, dass man halt in einen bestimmten Bereich reinschreiben kann. Es kann auch auf jeden Bereich schreiben, der nicht gesichert ist. Und wenn man in diesem Teil der Firmware kaputt macht, dann kann man auch die Maschine kaputt machen. Und dann ist es nicht mehr möglich, das Gerät zu buden. Und wir haben das auch wieder mit Apple besprochen. Sie haben tatsächlich alle Systeme bis 10.6.8 gefixt. Und das war in 2008, also schon ziemlich lang, acht Jahre quasi. Und Apple stellt halt automatisch so Updates bereit für die Systeme. Und die meisten Systeme wurden auch auf den neuesten Stand gebracht, aber eben nicht alle. Das Problem ist aber, dass es nur in diesem Protected Range Bereich gefixt wurde. Dass der SMSBWP nicht gesetzt wurde, aber das BitRide Enable ist immer noch anfällig für irgendwas. Deshalb sind halt nur die Protected Range Registries da irgendwie entscheidend. Dann gibt es halt noch den Darth Venamis. Das haben wir auch letztes Jahr auf dem Kongress vorgestellt. Und was die festgestellt haben ist, wenn das System auf ein Suspended Sleep geht, dass diese Flash Protection Bits unlockt werden. Und wenn das Gerät dann aus dem Schlaf kommt, dann gibt es ein gewisses Fenster, in dem Schreibzugriff auf die Firma gegeben wird. Und auch da sind wir wieder an die Unternehmen gegangen, haben das an alle weitergegeben. Apple wurde da jetzt nicht informiert, aber die haben halt noch einen anderen Schritt gekriegt. Und wie können wir jetzt von dieser Sicherheitslücke da irgendwie was rausnehmen? Wie können wir da die Buschrips-Spezifikationen ändern? So geht normalerweise ein normaler Boot und so geht dieser Resume-Modus. In einem normalen Modus probiert das System halt aus, welche Geräte sind angeschlossen. Und da gibt es halt so ein Cheat-Sheet und welche Konfigurations-Dateien aufgerufen werden müssen. Und wenn man aus diesem Resume-Modus kommt, dann gibt es halt bestimmte Funktionen, die ebenfalls abgeprüft wurden. Aber es gibt einen Dispatch-Bereich, wo man halt eine Funktion einbauen kann. Und wieder mal, wir gehen mal wieder ins Read-Memory-Tool und dann lesen wir das BootScript. Das ist eine Variable gespeichert und dann lesen wir das aus. Und dann sehen wir die verschiedenen Mem-Speicher-Beschriftungen. Und hier ist der, der die Protected-Range-Registry beschriftet. Und das passiert aber relativ spät im BootScript. Und da gibt es auch schon ein Dispatch an die Funktion. Und das BootScript lebt in einem Teil des ungesicherten Speichers. Wir können das Read-Memory-Tool nutzen, um den Funktion-Pointer in das Script einzurbeiten. Und sobald das Gerät in den Schlaf geht, dann wacht es das System auf. Aber das Protected-Range-Registry ist nicht länger gespeichert. Das heißt, der Angreifer kann irgendwie überall in die Firma eingreifen, egal was er will. Und dann kannst du halt wirklich so relativ was in das System reinbringen und die Chain of Trust zerstören. Und wieder mal gab es da einen Kontakt an Apple. Und die haben dann jeweils ein unzufrieden Stellen des, ein Sperrproblem sozusagen vorgestellt und haben das dann halt verbessert laut diesem Update. Da gibt es aber noch eine zusätzliche Schlaffunktion, die wenn noch nicht gesehen haben, die da auch in diesem Patch behoben wurde. Bei dem letzten, bei Android 30 C3 gab es auch schon einen Vortrag, wo wir darüber geredet haben. Da geht es darum, dass die nach einem Suspend-Resume-Durchlauf nach dem Wiederaufwachen das Ganze entsperrt ist. Das im Prinzip geht es zurück auf eine Verwundbarkeit aus 2013, die heißt Snorlax. Da geht es darum, dass die Schreibblockaden nach einem Aufwachen nicht mehr gesetzt wurden. Das sind jetzt, jetzt haben wir festgestellt, dass neuere MacBooks einen neueren Intel-Chipsatz haben, der das dann unter der Hand im Prinzip gefixt hat. Der hat, entweder hat Intel eine bessere Referenzarchitektur rausgegeben oder Apple hat es selber behoben, aber im Prinzip sind alle neueren MacBooks nach 2012 dadurch immun geworden. Alte sind aber natürlich weiterhin verwundbar. Ähnlich war es in dem USB-C-Stecker der neuen MacBooks von 2015, die ebenfalls behoben wurden. Wie bereits erwähnt, Apple hat sich diesen Problem angenommen und durch besseres Locken diese beiden Schwächen abgestellt. Aber was sie gemacht haben, ist im Prinzip den Code, der die Schreibberechtigung in weggenommen hat, an andere Stelle verschoben. Aber das Resumescript, also das, was nach dem Wiederaufwachen laufen lassen wird, ist immer noch ungeschützt in vielen Systemen. Man kann es nutzen, um direkt die, die man tun kann, bevor das System in den Kernel gebotet. Nachdem die einfachen Wege um das Auszutricksen beruben wurden, gibt es noch eine Stelle, an der das wirklich aktiv entsperrt wird, das ist beim Update. Hier gibt es eine Reihe von Integerüberlauffehlern, die man ausnutzen kann. Viele dieser Schwächen treten auf, wenn das System in einem komplett verwundbaren Zustand ist bei einem Firmware Update. Er hat es auf einem HP Notebook ausprobiert, was man da sieht ist, der Link, den man in dem Userbuffer hat, wird vom Nutzer kontrolliert. Während dem Firmware Update wird das gepasst, die Firmware ist entsperrt und man hat vollen Schreibzugriff. Das hat so viele Systeme betroffen, dass es sogar den Pony Award gewonnen hat für die beste Zugriffsverletzung. Wie immer verantwortungsvolles Benachrichtigen der Firmen ist natürlich wichtig. Im Prinzip waren fast alle davon betroffen und die wurden auch informiert, alle bis auf Apple. Apple hat behauptet, dass weil sie nicht die Standard UEFI Update Methoden benutzen, sind sie nicht betroffen. Sie sagen halt, weil sie eine eigene haben, kann es sie nicht betreffen. Letztes Jahr in meinem Talk habe ich genau erklärt, wie Apple das macht, ich könnte es gerne danach lesen. Das Problem dabei ist, dass alles in UEFI wird mit Funktionspoint gemacht und 128 Bit UIDs. Wenn man diese UID reinpasst, in das BIOS kriegt man den Funktionsport zurück. Das heißt, man kann im Prinzip vielen alten Code nicht entfernen, weil es weiterhin noch Verweise darauf gibt, die man bei einem Dispatch berücksichtigen muss. Es stellt sich raus, dass diese verwundbare Update-Routine, auch wenn sie sie selber nicht benutzen, ist der Code immer noch da. Corrienzino nennt das BIOS-Totenbeschwörung. Kann man das im Prinzip ausnutzen und diesen Code ausführen lassen, auch wenn er eigentlich normal nicht verwendet wird. Wieder zwei verschiedene Laptops, MacBook und HP, aber sie haben im Prinzip den gleichen verwundbaren Stück Code. Man hat natürlich verschiedene Compiler, die verwendet wurden, verschiedene Optimierungslevel, aber man sieht genau, dass die gleiche verwundbare Routine immer noch da ist. Und als Resultat unserer Arbeit wurde das inzwischen bei SIRT als auch verwundbar markiert, ein Jahr nach der Originalveröffentlichung. Apple musste zugeben, dass sie doch betroffen sind und sie mussten dann auch dementsprechend ein Fix dafür ausrollen. Der Fix ist relativ interessant, wenn man sich den genau anschaut. Also unbenutzte Funktionen, alte Funktionen können verwundbaren Code enthalten. Das ist relativ wichtig, also dass man als Lehre daraus zieht, dass man nicht nur den neuen, sondern immer auch den alten selbst, den nicht benutzen Code mit anschauen muss, weil es doch noch sein kann, dass er ausgeführt wird, auch wenn man es nicht vorsieht. Okay, und jetzt der fünfte Verwundbarkeit, die wir haben, ist eine Sache, die im Prinzip aus der Zeit des Original 8086 kommt. Damals wurde immer in diesen extra Sockets geguckt, ob da zusätzliche nachgerüstbare Features installiert waren. Zum Beispiel auf dem ESA Expansion Bus, um zu sehen, ob da noch eine zusätzliche Grafikkarte zum Beispiel eingesetzt wurde. Dieser Code wurde leider ganz am Anfang noch in Ring Zero ausgeführt, noch bevor der Kernel läuft oder sogar das BIOS. In 2007 wurde gezeigt, wie man das ausnutzen kann, um alte Server mit bestimmten Netzwerkkarten zu übernehmen. 2012 hat es näher gezeigt, dass Thunderbolt auch dafür anfällig ist. Und letztes Jahr beim CCC, also beim Kongress, haben wir gezeigt, wie man bei einem Update der Firma das ausnutzen kann. Und dieses Jahr haben Sino und ich das auf der DevCon noch mal einen ganzen Satz Verwundbarkeiten dafür gezeigt. Ja, nach dieser Veröffentlichung auf dem CCT Kongress, hatte Apple einen Fix rausgebracht, um diesen ThunderStrike One Fehler zu behandeln. Seitdem lädt das System keine Option Rooms mehr während der Updates. Es ist aber immer noch wichtig, das zu wissen, dass das alles noch vorhanden war. Es war noch ein weiteres Update und selbst mit diesem Patch, wenn man ein Thunderbolt-Adapter hat, also der Thunderbolt ist ein Adapter, man kann diesen Option-Rom-Exploit mit ein paar Tastaturbefehlen aktivieren. Und wenn man eine Remote Shell auf einem Rechner einrichtet, dann kann man den physischen Speicher PCIe an Geräte und dann kann man immer noch diesen Option-Rom beschreiben. Das nächste Mal, wenn dieser Rechner läuft, wird er auch diesen Code ausführen und es ist immer noch ziemlich massiver Eingriff. Man kann immer noch diesen wichtigen Chip überwinden, der in dem System drin steckt. Es ist immer noch sehr gefährlich. Heute gab es schon einen Talk about state-considered-harmful, um wie viel beschreibbarer Content sich da auf diesem System befindet. Es ist echt beeindruckend, wie viele Firmware-Teile beschriftet werden können. Selbst ein Thunderbolt-Display hat ein entsprechendes Option-Rom, selbst Grafekontroller. Intel hat festgestellt, dass es ein riesiges Problem für den sicherem Boot-Prozess ist. Sie gehen davon aus, dass diese Option-Roms signiert sein müssen. Das geht aber auf Apple-System nicht, weil da Secure-Boot mit rein spielt. Also beim Secure-Boot kann da nichts passieren. Die OE viel schwach stellen, befinden sich oft auf verschiedenen Systemen und auch auf verschiedene Hardware, auf Laptops, auf fest installierten PLCs. Und es ist jetzt nicht begrenzt auf die Mac-Plattform. Viele wurden bisher schon gefixt von Apple. Und die neuen iMacs und die neueren Systeme haben dieses Option-Rom nicht mehr. Und Thunderbolt 3 könnte dann dieses Option-Rom auch entfernen. So all diese Schwachstellen wurden mittlerweile behoben. Und es war großartig, die in ein Proof-of-Concept-Demo zusammenzufügen. Und jetzt zeigen wir euch das mal, wie könnte das alles zusammenkommen. So, nicht so wie letztes Jahr, fangen wir dies Jahr mit einem Software-Exploit an. Ein Download beispielsweise, Adobe Flash, was auch immer. Was wir dann auf Root ausführen können. Und sobald es Root zu Griff hat, kann man ein Kernel-Modul einfügen, das durch den physischen Speicher geht, um mal in den Motherboard-Boot-Prozess reinzuschreiben. Und dann wird so nach PCIe-Devices gecheckt. Es kann sein, dass da Geräte mit Option-Rom dranhängen. Da kann man sich da reinhecken. Zum Beispiel, wenn da ein Thunderbolt-Island-Adapter drin ist, dann ist dieser jetzt auch infiziert. Und das nächste Mal, wenn man in den Rechner wieder hoch fährt, kann Thunder Strike 2 laufen aus dem Motherboard-Boot-Bereich. So, es ist ja nur dieses Blast-Spielen, also es ist jetzt nichts, was irgendwie Gefahr hat. Und das hier wird gestartet, bevor der OSX-Körner gestartet wird. Das kann sich zum Beispiel in der Virtualisierung verstecken, sonstwo. Und wenn man OSX neu installiert, ist es immer noch da. Wenn man die Festplatte austauscht, wird es nicht verschwinden. Es ist letztlich im Motherboard integriert damit. Wenn man das infizierte Gerät wecktut und diesen Thunderbolt-Adapter einschließt, an ein anderes System, und wenn dieser dann bootet, dann lädt er diesen Option-Rom vor dem Körner. Und das ist ein neuerer Rechner, der Prince Harming nicht betrifft. Aber es könnte halt dieses S3-Boot-Script angreifen. Und dann fängt das System ja ganz normal zu booten an. Sobald das Gerät in diesen Schlafmodus gibt, zum Beispiel wenn man den Deckel schließt, wird die CPU sich abschalten. Man muss den Rechner nicht anmachen. Ich wollte nur zeigen, wie toll das aussieht, wenn man die CPU runter fährt. Sobald das Gerät wieder aufwacht, wird dieses Script ausgeführt, bevor das Bootflash ausgeführt wird. Und dann wird Thunderstrike in den Bootflash im Motherboard eingefügt. Damit ist das Bootflash jetzt auch infiziert. So, aus der Nutzerperspektive sind es nur ein paar zusätzliche Sekunden, um aus diesem Sleep-Modus rauszukommen. Und das ist jetzt nichts Besonderes. Aber das nächste Mal, wenn dieses System sich hoch fährt, wird dieser Boot-Script angezeigt. Und ja, der Rechner ist infiziert, weitere Maschinen ist infiziert. Und das ist wirklich so eine harte virale Übertragung. Das hat jetzt das Betriebssystem überhaupt nicht berührt. Das läuft auf einem Level unter dem Betriebssystem sozusagen. Eine andere Sache ist, was dieses hier tut. Es wartet auf diesen PCIe Hard Plug. Wenn man einen sauberen Adapter anschließt, dann passiert das Gleiche mit dem Adapter, der wird dann jeweils wieder infiziert durch das Optionraum. Also von daher könnte sich dieser Virus sozusagen weiter auf andere Systeme übertragen, ohne dass man es wirklich merken kann. Ja, und wenn es nur ein Adapter ist. Dieses Proof of Concept zeigt, dass es einen gewissen Lebenszyklus von MyWare gibt, von dem Exploit, bis man dann tatsächlich was mit dem Bootflash machen kann. S3, Zustand, verschiedene Geschichten. Sobald es in diesem Bootflash Optionraum ist, läuft es komplett unter dem Betriebssystem. Die Virusscanner werden es nicht finden. Sie können es wahrscheinlich noch nicht mal sehen, weil sie normalerweise darauf getrimmt sind, bestimmte Scanning-Technologien anzuwenden. Sie können es ins Bootflash nicht reingucken. Die einzige Möglichkeit wäre da, so einen Clip draufzusetzen, um diesen Flash auszulesen. Aber alles, was man mit Software ausprobieren könnte, würde nicht auffallen. Tja, was können wir jetzt tun? Es sind so viele verschiedene Ideen, wie man mit solchen Rootkits umgehen kann oder vielmal Problemen. Es gibt viele kleine Schritte, die man unternehmen kann, also zum Beispiel einfach mal die Signaturen auf den Option-Rom zu checken. Das wäre schon sehr hilfreich, wenn man das mal anfangen würde. Wenn man alle von den Sperren benutzen würde, die es so gibt, zum Beispiel, dass das BIOS nicht beschreibbar ist, dass man sich in das S3-Schlaf-Schrift nicht einhängen kann. Diese ganzen Feature, die Intel dazu gefügt hat, wie die Lockbox, dann gibt es noch Chipsack. Und Hurnikus, das sind Tools, die helfen, solche Konfigurationen zu überprüfen, um sicherzustellen, dass die Systeme in einer sicheren Weise gestartet werden. Intel macht weiter mit auf der Hardware-Schiene. Also neuere CPUs haben die sogenannte Boot-Guard. Das ist ein Rom, das läuft bevor die erste Anweisung für den CPU ausgeführt wird. Das stellt kriptografisch sicher, dass das Rom nicht angepasst wurde, bevor es überhaupt startet. Das Problem ist, die Systeme, die Boot-Guard verwenden, sind fundamental inkonvertibel mit Core-Boot. Das heißt, für freie Software ist das wiederum schwierig. Meine Bitte an Systemhersteller wäre, wenn solche neuen Verwundbarkeiten gefunden werden, dann arbeitet doch bitte mit den Sicherheitsforschern, um festzustellen, ob ihr wirklich verletzt, angreifbar seid oder nicht. Die Firmen nehmen oft einfach einen Exploit, so wie er geschrieben wurde, und versuchen es dann auf ihren Maschinen, und es läuft dann halt oder es läuft nicht, und je nachdem behaupten sie dann, dass es bei ihnen nicht funktioniert, aber die Entwickler haben in der Regel nur wenige Testsysteme und können deswegen keinen so allgemeinen Test durchführen. Insofern zusammenarbeiten würde schon helfen, da könnte man solche Sachen rausfinden. Wir haben herausgefunden, dass in dem alten UEFI-Code viel, viel alter Code drinsteckt, der Schwächen enthalten könnte. Es kann sein, dass es je nachdem, wie man den Input wählt, man da reinspringen kann. Es ist extrem wichtig, dass man alles testet, nicht nur, also im Prinzip das gesamte Kreuzprodukt aus Systemen, neuem und alten Code. Es ist ziemlich schade, dass es an diesen wirklich schwerwiegenden Fehler gab, Snorlax, und das sich dann rausgestellt, dass es dann immer noch Systeme gab, die dagegen anfällig waren, obwohl er längst bekannt war. Und bitte, wenn ihr neue Schwächen habt, dann testet sie auch gegen alte Systeme, weil sonst ist es möglich, dass einfach die Alten weiter verwundbar sind. Und wenn ihr solche Schwächen fixt, dann behebt sie nicht einfach still, sondern sagt den Leuten auch, dass es angreifbar war. Welche Systeme verletzt war sind, welche corroben wurden. Das ist ziemlich gefährlich, weil es schwer zu sagen ist, nur nach dem Alter, ob das jetzt noch angreifbar ist oder nicht. Und es ist ziemlich gefährlich, nicht diese Gewissheit zu haben. Okay, und jetzt nehme ich die Fragen entgegen. Wenn ihr noch mehr Interesse daran habt an dem Thema, geht einfach auf meine Seite. Ich habe es euch hier hinterlegt. Ich nehme auch GpG signierte E-Mails entgegen. Ansonsten freue ich mich jetzt auf die Diskussion. Ich glaube, die Batterie ist alle. So, wir machen das jetzt mal ohne Mikrofon. Ah, das geht auch. So, danke schön. Für alle Leute, die draußen im Stream sind, werde ich ein bisschen Fragen klären. Dann kommen eine Frage aus dem Raum und eine Frage aus dem Internet, so immer im Wechsel sozusagen. Gibt es Fragen? Ja. Da ist eine Frage. Mikrofon 3. Hast du schon mal SPI Flash-Commands auf dem Flash-Chip gesehen oder wie wir das im Hintergrund gemacht mit verschiedenen SPI-Flash-Chips? Fragen Sie, ob das Betriebssystem regelmäßig Erraces durchführt? Na ja, wenn man Flash beschreiben will, da muss man erst mal gucken, wo es ist. Das geht jetzt hier nur um die NV-RAM-Variablen. Im Prinzip ist die Frage, warum lässt Apple den Flash überhaupt schreibbar? Im Prinzip speichern Sie da gewisse Einstellungen, die Sie über einen Boot hinweg transportieren wollen, wie zum Beispiel die Bitch im Helligkeit. Die liegen an einer Pin-Struktur. Man kann da immer noch was dranhängen. Wenn Sie einen Block voll haben, dann machen Sie einen vollen Löschzyklus. Haben wir eine Frage aus dem Internet? Ist da jemand? Ja, eine Frage gibt es. Wie unterscheidet sich BootGuard vom Trusted Platform Module? TPM ist. Es ist so, dass das TPM außerhalb der CPU sitzt und dadurch nur Hashes erzeugt werden und darauf basierend, was die CPU angefordert wird zu tun. Wenn jetzt die Merva das Flash übernommen hat, dann ist es in der Lage, so viele Werte auf einmal auf das TPM zu schicken, dass es nicht auf den Zustand der CPU schauen kann, sondern einfach nur das Hasht, was es kriegt. BootGuard verschiebt dieses Vertrauen in die CPU und dann sitzt es nicht mehr außerhalb. BootGuard führt erst Flash-Befäle nachdem es gecheckt wurde, so dass man sowas beim nächsten Booten entdecken könnte. Ich bin jetzt nicht mehr sicher, ob Sie diesen HardFail-Implementierung haben, aber TPM war eine interessante Idee, aber es gibt ungefähr ein Dutzend Paper dazu, wie man das umgeht. Okay, die nächste Frage vom Mikrofon 3. Ich hatte meine eigenen Stories mit Apple, um Feedback mit denen zu kriegen. Ich denke, dass ihr das so in gewisser wiederkehrende Art und Weise hatte, dass Sie sich mit euch besprochen haben und Sie haben es ausprobiert und Sie haben gesagt, ja, nie, das ist nicht passiert. Ich würde erwarten, dass dies hier so eine ganz gefährliche Ecke ist, wo Apple tatsächlich einen Dialog haben wollen würde mit euch. War es irgendwie Misskommunikation? Bei einigen von diesen Bugs hatten wir einen Dialog mit Apple und die haben mir sogar Betas geschickt, die ich dann auch ausprobieren konnte. Gelegentlich war es schon released worden, bevor wir überhaupt die Zeit hatten, das anzugucken. Manchmal ist der Dialog länger, als Sie warten wollen, um den Fix zu veröffentlichen. Ah, jetzt haben Sie gerade Sino in Kori's Firma erworben, sodass Sie jetzt wahrscheinlich genug Expertise haben, sodass die Security deutlich besser dastehen dürfte jetzt. So, eine weitere Frage aus dem Internet. Habt ihr ein Werkzeug, um den aktuellen Status des MacBooks zu checken, ob es gefährdet ist oder nicht? Also, das Problem dabei ist, rauszufinden, ob das System verwundbar ist oder schon infiziert ist, dass, wenn man eine Merva hat, die sich wirklich versteckt, kann sie im Prinzip sich in alle diese Wege reinhängen, um rauszufinden, was passiert ist, sodass man eigentlich keinen Mekat rauszufinden, ob es wirklich passiert ist. Man könnte versuchen, bei einem sauberen System, könnte man feststellen, ok, so müsste es aussehen, aber wenn man ein System hat, von dem man ausgeht, dass es vielleicht infiziert ist, dann ist es wirklich hart zu sagen, mit Sicherheit, dass es so ist. Eine weitere Frage aus dem Internet. Welche Plattform würde dir empfehlen, um dieses UEFI-Bootsystem umzugehen quasi? Nachdem UEFI jetzt auch in der Armwelt ankommt, bin ich nicht mal sicher, ob man überhaupt noch drumherum kommt. Für sich alleine genommen ist es eigentlich schon ganz cool. Es ist erweitbar, es ist praktisch, aber es ist sehr viel Code in der zu vertrauenen Codebasis und es hat sich gezeigt, dass das ziemlich problematisch ist in der Vergangenheit. Aber im Moment sieht es eher so aus, dass es in naher Zukunft die meiste Hardware auf UEFI läuft. Wir haben ein Open Source Laptop, Bunnies Laptop, mit Open Source Firmware. Bei dem hätten wir relativ gutes Vertrauen, da könnte man zumindest nachsehen. Wir wissen einfach nicht, was in der Intel Management Engine überhaupt passiert im Inneren. Selbst wenn Sie sichere Firmware hätten, hätten Sie immer noch einen Bineerblop, von dem Sie nichts wissen und alles Mögliche machen könnte. So, nochmal einen dicken Applaus für TRIMO.