 In diesem Talk geht es darum, wie Bootloader kaputt gemacht werden, wie man sie knacken kann. Also jetzt eine herzliche Runde Applaus für Eher von Spundel und Josef Tartaro, beide von IOactive. Willkommen zu Boot2Root, also wie man Bootloader kaputt macht mit Beispielen. Ich bin Josef Tartaro und mache Dinge kaputt für IOactive. Das ist mein zweites Mal auf dem Kongress und ich freue mich wirklich wieder hier zu sein. Hi, ich bin Ilya. Das ist schon mein 18er oder 19er Kongress und ich freue mich natürlich auch wieder hier zu sein. Ich habe schon einige Male hier geredet und ich freue mich sehr, zusammen mit Josef jetzt diesen Talk zu machen und wir haben schon mal beim letzten Kongress über Bootloader geredet und jetzt wollen wir euch mal ein Update geben, was wir so gesehen haben und was wir erreicht haben. Also als Publikum stellen wir uns vor, die üblichen Embedded System Entwickler, dann einfach generell Leute, die sich für RT-Sicherheit interessieren, besonders bei Embedded System und Leute, die sich generell halt für Sicherheit interessieren und viele unserer Folien sind halt einfach ein Haufen Source Code, das heißt, wenn ihr euch nicht vorstellen könnt, eine Stunde Quake Code anzugucken, dann solltet ihr vielleicht wieder rausgehen, das ist nicht unbedingt euer Talk. Es ist jetzt nicht besonders flashy, wir wollen nicht irgendwie zeigen, schaut her, das sind all die Fehler, die wir gefunden haben, das ist jetzt auch nicht, wir wollen auch nicht über Flatvektoren reden, beziehungsweise der Angriffe, die wir glauben, dass erfolgreich sind. Das sind eher Beispiele von Sachen, wo wir sagen, da schaut keiner hin und das ist heute mal vielleicht auch mal anfangsbrauch zu schauen. Also das ist unser Programm, was wir heute durchgehen wollen. Die Frage ist, wofür braucht man eigentlich Bootlouder, warum sind sie wichtig, was sind Features, die sie haben, was ist die Angriffe, die sie bieten und das ist jetzt eine relativ breite Interpretation von dem, was man ein Bootlouder versteht. Das heißt bei uns alles, was im Prinzip in der Bootkette drin ist, wenn du damit keine Erfahrungen damit hast oder wenn du, wenn ihr euch das vorstellen könnt aus der Betriebssystemsicht, dass es die normale Welt gibt, die in die sichere Welt guckt, dann müsst ihr euch diese Sprünge angucken, die einen Angreifer benutzen kann, um an sichere Daten ranzukommen. Und warum? Ja, Bootlouder sind halt einfach kritisch in der Sicherheit von Geräten, die ist meistens die Quelle für die Sicherheit bei der Chain of Trust und man muss extrem, die Entwickler sind meistens relativ schlecht darin, das abzusichern und die Attack, die Oberfläche für die Angriffe klein zu halten und die zum Beispiel haben viele von denen ein Netzwerkstack, den man eigentlich gar nicht braucht, Dateisysteme, die man eigentlich nicht erwarten würde, die keinen Sinn machen. Eigentlich würde es alles Sinn machen, das rauszunehmen, wenn man weniger Angriff hat, aber das machen sie halt nicht. Und die vergessen total, dass man auch, wie wir es in den Studien betreiben kann, die haben wir überhaupt nicht auf dem Schirm, dass es irgendwie Leute gibt, die sich die Spöße im Sinne haben, weil sowas und die Geschichte hinter dieser Sprüße, die in diesem Vortrag ist, dass wir ein Baseball-Spiel angeguckt haben mit jemandem und ich ihm das Spiel nahe bringen wollte und dann habe ich mein Handy rausgezogen. Und ich habe zehn Minuten irgendwie zehn Bugs gefunden, die irgendwie dabei kamen beim Boden und dann haben wir gesagt, okay, vielleicht sollten wir uns das mal genauer anschauen und das war dann so ein, dann haben wir auch noch eine Inspiration gehabt durch den früheren Vortrag von Ilya, da hatte er sich mit verschiedenen BSDs angeschaut und dann habe ich gesagt, okay, vielleicht schauen wir uns einfach mal verschiedene Bootloader an und wie immer, wir wollen natürlich auch den Leuten danken, die sich da schon vorher drüber Gedanken gemacht haben, wir sind natürlich nicht die ersten sich das angeschaut haben, das ist die Liste der Leute, die vorher schon mal was gemacht haben und die uns inspiriert haben und wenn ihr euch dafür interessiert, dann schlagen wir euch vor, dass ihr euch das anschaut, was diese Leute gemacht haben und was sie so geschrieben haben. Viele von denen haben Paper rausgegeben, haben irgendwie Vorträge gemacht. So, die Frage ist, wo sind denn Bootloader und die Antwort ist einfach überall, also ob es jetzt dein Desktop ist, deine Spielkonsole, dein Server, alles, dein Handy und die Sicherheit hängt ganz kritisch von diesen Bootloadern ab, weil sie soweit vorne in der Kette sind und man damit alles machen kann. Und was wollen wir uns damit fassen, was gibt es denn für häufige gängige Bootloader, ob es die U-Boot, Core Bootgrab, CBO, CFE ist nicht besonders bekannt, IPXE ist eine ganze Familie von Technologien und wir haben nur Sachen angeschaut, die auch auf GitHub sind, wo wir in der realen Welt, in der realen Welt ist es so, dass die Geräte, die sowas einsetzen, das nicht einfach unverändert benutzen, sondern zu stark verändert sind und die haben eigene Treiber, eigene Patches und wir wollen nicht irgendwie bewerten, wie häufig die Fehler sind und wie wahrscheinlich es ist, dass man sie ausnutzen kann, aber das ist nicht der Sinn unseres Vortrag. Wir wollen einfach nur den Leuten zeigen, den wir wollen den Entwicklern aufzeigen, wo sie sich darüber Gedanken machen sollten und über Features über die sie sich Gedanken machen sollten. Also U-Boot, das ist ein sehr weit verbreiteter Bootloader, gibt es auch sehr vielen verschiedenen Geräten, sehr anpassbare Konfigurationen für ganz viele verschiedene Boards und es gibt dann auch ein Gemungsvariablen, es gibt eine sehr mächtige Shell und es gibt tatsächlich dann sogar Probleme mit Shell Injection Angriffen. Also ja, einfach auch viele Treiber für viele Geräte und das heißt, das ist ja erstmal eine sehr gute Basis, um Nachlücken zu finden. Nachlücken zu suchen. Welche Features hat U-Boot so? Einmal der Netzwerk-Stack, der verschiedene Protokolle pausen kann, Dateis-Theme und U-Boot lädt auch die Images für die nächste Bootstufe aus ganz vielen verschiedenen Quellen und das ist vor allem in vielen Embedded-Geräten verbreitet. Core-Boot, ich entschuldige mich hier schon vorab, das ist jetzt alles ein bisschen trocken, aber es wird später nützlich. Core-Boot richtet sich eher an modernere Betriebssthemen, es gibt keinen Legacy-Bios und sie haben im Prinzip eine Methode, die die anderen nicht so zu anderen Nut bringen, nämlich dass sie sehr wenig Features implementieren und das funktioniert dann so, dass man von Core-Boot aus lieber einen weiteren Boot loader lädt. Also Core-Boot selber baut nicht so viel ein. Das wird zum Beispiel in Chromebooks benutzt, viele interessante Teile in Core-Boot kommen auch von Google und sind halt dann auch SNM-Modus. Da gibt es noch Grab, ich denke, das kennen die meisten hier. Wo Thomson sehr primär geht, ist die Multi-Boot-Spitzifikation. Grab unterstützt sehr viele Dateis-Theme, also das ist die Hauptangreiffläche, aber der interessant Teil hier ist, dass es auch OE-Fi-signierte Versionen von Grab gibt und das ist wichtig für secure Boot, wo Grab auch verwendet wird. Das heißt, wenn wir hier eine Sicherstücke finden, dann kann man das eben auch in einem Secure-Boot-System zur Anwendung bringen. Dann gibt es noch C-Bios, das ist das Standard-Bios für Core-E-Mu und KVM, das unterstützt die ganzen Bios-Aufrufe, die dann auch von Core-Boot und so weiter verwendet werden oder die Verwendung von Core-Boot zu laden. Es hat Trusted Platform-Modius-Support und kann dann noch weitere Aufrufen. Dann gibt es noch CFE, das wird in vielen Netzwerkeräten verwendet und eine der offensichtlichen Angriffsflächen sind hier dann der Netzwerk-Stack. iPixi ist auch wieder sehr netzwerkbasiert, Protokoll-Parsing und es gibt hier auch eine OE-Fi-signierte Version und das ist dann auch wieder interessant hinsichtlich Secure-Boot. Und dann auch Tiano-Core. Hier muss man jetzt wirklich nicht viel erklären. Es gab hier sehr viele Präsentationen zu in den letzten 15 Jahren, in denen Leute das komplett auseinander genommen haben und Tiano-Core wurde wirklich schon sehr viel auditiert und man kann hier schon davon ausgehen, dass Tiano-Core besser ist als vieles andere da draußen und es gibt noch mal viele Implementierungen, die auf Tiano-Core selber aufbauen. Zum Beispiel Qualcomm's LBL oder XBL, also es gibt quasi die Basis Tiano-Core-Code-Basis und dann gibt es dann auch sehr viele Plattform-Fizifische oben drauf. Dann gibt es noch Verwandt mit Bootloadern, so was wie Trust Zone. Da sollten wir vielleicht mal kurz erwähnen, dass es grundsätzlich ein bisschen interessantes Split gibt zwischen normaler Welt und Secure-Boot, also sicherer Welt gibt und diese Übergänge dazwischen und die dann genutzt werden, um an bestimmte Geheimnisse heranzukommen und aus Sicht des Host-Betriebssystems ist das zum Beispiel interessant, weil man ein V-Ram und so weiter bearbeiten kann. Das bedeutet, dass wenn wir rebooten, dann der Bootloader diese Variablen wieder ausliest, die wir gerade zurückgeschrieben haben. Hier ist noch mal eine Link-Liste zur Einstiegs-Dokumentation, wie man die Software baut, wo man sehr bekommen kann. Hier das Konzept von Secure-Boot, seine Vertrauenskeste, dann hat man verschiedene Loader, die die nächste Stufe dann verifizieren, dann hat man TPM im Development, dann hat man noch dann hat man noch Envy-Ram, was Boot-Konfigurationen setzt. Das Boot-Ram selber ist etwas, was ihr wahrscheinlich vorhin mal gesehen habt. Es ist sehr wichtig, weil es nicht gepatched werden kann. Das heißt, es braucht eine neue Hardware-Version, wenn Schwächen gefunden werden. Und es ist so früh, dass es alles komprimivieren würde. Es ist sehr grundlegend. Es initialisiert Hardware-Speicher. Man findet zum Beispiel Implementierung von Fast-Boot oder USB-Stacks, und dann verifiziert es die Signatur von der nächsten Stufe, und dann kommt die nächste Stufe. Das ist die Initialisierung vom Rest, also Netzwerk-Stack, und dann kommt man zu Sachen wie Trusted-Boot, oder Measure-Boot, und dann eine Verifikation und eine Ermessung und Logging. Und das mindert nichts, sondern ist notiviert nur. Einige Hardware-Umgebungen sind ein bisschen unterschiedlich. Es gibt von ARM Trust Zone, dann gibt es von Windows noch, VTL One und Zero, und teilweise Sachen. Und irgendwann wird dann das Betriebssystem geladen, und der Betriebssystem wird dann geladen und verifiziert und fängt dann an zu laufen. Früher Beobachtungen, alles, was wir uns angeschaut haben, was Open Source ist, da gibt es keine Separation von Privilegien. Wenn man eine Komponente komprimitiert hat, dann hat man alles komprimitiert. Einige komprimitierte Bootloader, wie zum Beispiel von Apple, die machen ein bisschen Privilegien-Separierung, und das heißt, wenn man nur ein Modul komprimitiert, dann macht man das nämlich mit allem. Wir haben das uns nicht genau angeschaut. Das ist die Liste der Angriffsfektoren, die die Leute interessieren sollten. Es gibt Invi-RAM, Datasysteme, Netzwerkstecks, Protokollstecks, verschiedene Busse, SMM, DMA und Hardware-Sachen. Das Interessente an Busen ist, dass embedded Designer, dass sie im Heldet Designer all den Sachen vertrauen, die Enthuser nicht benutzen. Das heißt, USB wird nicht vertraut, aber weiter hinten nichts mehr. Das heißt, zum Beispiel, dem TPM wird einfach vertraut. Invi-RAM, das sind die verschiedenen Umgebungsvariablen, die konfiguriert werden können für den nächsten Bootzyklus. Das ist grundsätzlich User-Datenverarbeitung. Wenn man sich hier einige Bootloader anschaut, sind das hier die interessante Funktionen. Umgebungs-Boot verwendet man EnvironmentGate und dann sieht man, wie hier eine Umgebungsvariable nehmen und schaut, was sie damit tun. Das hier ist ein Beispiel. Da ist ein EnvironmentGate für Boot PCI. Prüft das Absatz existiert und dann wird das in die Länge checken und dann in eine Variable schreiben, ohne zu checken, ob das überhaupt reinpasst. Dann haben wir uns überlegt, dass wir das vielleicht ausnutzen sollten und haben damit rumgespielt. Dann hat das merkwürdige Paket übergesendet. Ein paar merkwürdige Boot-Piesachen und dann gibt es irgendwie vier Rohr-Pakete. Aber es war nicht sehr realistisch. Das hat begangen, in die QEMO-NetworkStack zu gehen. Das heißt, Sie haben das eher vermieden. Aber es ist sehr einfach, in diese Sachen reinzuschauen und Explotations anzuschauen. Aber es gibt keine Minderungen oder so. Wie man sieht, gibt es hier so ein gewisses Pattern. Wir haben hier 128 Buffer und es ist passiert immer das Gleiche. Das ist genau das, wofür wir geredet haben. Der Code ist einfach nicht besonders gut. Es gibt keine Checks. Das ist der Witzigste, den wir gefunden haben. Hier geht es um Boot-Pie, WCI-Stuff, Zeug. Jetzt haben wir überlegt, jetzt lassen Sie aber noch einen anderen Backgefunden. Dann haben wir gesagt, vielleicht wollen wir einen anderen Stacksmash noch finden. Das ist einfach das perfekte Beispiel dafür. Wenn ich hier die Variable hole, dann holen wir uns einfach die erste Element von der Variable und dann wird es nur kopiert. Sofort da. Immer wieder das selbe. Hier nur noch ein schnelles Beispiel. Das wollen wir jetzt einmal mal vorführen. Hier. Das Angriffsszenario hier ist, ihr habt ein Gerät, das könnt ihr physisch verändern. Ihr habt Zugriff drauf. Und hier ist jetzt das Beispiel NVRAM, das man da sieht. Dann haben wir einfach 200 Bytes aufgeschmissen. Und dann haben wir eine Funktion aufgerufen, wo die Adresse da war. Und das hier machen wir jetzt mit den JFFS zu. Das Data-System. Also müssen wir hier FS-Load machen. Und fertig, mehr ist es nicht. Natürlich, wenn ihr das noch nie angeschaut habt, es macht Spaß, sich das mal anzuschauen, solltet ihr mal probieren. Warum nicht? Okay. Das war jetzt die NVRAM Angriffsfläche, die wir hatten, was natürlich Spaß mal drum zu spielen. Aber wenn es um Angriffsflächen geht, die einen interessieren, wie Joe sagt, ist es relativ einfach, das hier zu übersehen. Und weil da immer so viele Stringkopierfunktionen vorkommen und es macht einen Haufen Spaß, aber es gibt nicht nur NVRAM und es gibt noch viele andere Angriffsflächen in so einer vertrauenswürdigen Boot-Umgebung. Und es wird sich interessant, dass sich natürlich Dateisysteme zum Booten braucht man das einfach, ohne es geht es kaum. Und man kann alles Mögliche damit anstellen. Und oft sind die Dateisysteme selbst weder überprüft auf die Signatur oder auf Integrität. Das ist eine wunderbare Angriffsfläche, die einfach, weil man da als User auch einfach rankommt, relativ häufig ist das FAT-Dateisystem, wenn deine Boot-Umgebung das unterstützt, also dass man den USB-Stick zum Booten benutzt, dann wird FAT vorhanden sein. Und je nachdem welches es ist, hat man entweder ein Proprietärsformat oder das X2 oder... Aber natürlich sind die Dateisysteme Pauser die besten, die man sich anschauen kann. Und natürlich leben Dateien in den Dateisystemen, das ist ja der Zweck. Und je nachdem wie die Umgebung aussieht, aber die manche von den Dateien werden wahrscheinlich Integritätsüberprüft, aber viele werden es wahrscheinlich nicht sein. Und viele von den Dateipausern sind deswegen auch interessant. Also wenn man ein Produkt baut mit sowas, sollte man direkt errat ich euch dringend, dass ihr das irgendwie fasst, damit ihr Fehler findet. Aber wir wollen jetzt einfach mal ein paar Beispiele zeigen von Fehlern, die wir gefunden haben in verschiedenen Bootloadern. Wir fangen mit X2 an. Und dann gehen wir über Stacksmash-Attacken. Und die anderen sind einfach Beispiele, wo auch Fehler sein können, die ihr aber nicht angeschaut haben. Das ist jetzt die Crop X2-Implementierung. Das ist jetzt der SimLink-Code. Also es schaut über das Dateisystem, findet einen SimLink, und dann geht es darum, wie man das phasen muss. Dann sagt es, okay, ich bin ein SimLink, und dann sagt Crop, oh, ich werde jetzt mal die Größe, die du mir sagst, allokieren im Speicher und noch eins draufmachen. Und das ist ein klassischer Stack-Overflow, den wir hier machen können. Also wenn man zum Beispiel 0 nimmt, oder wie gesagt, dann kriegt man einen Pointer auf eine 0 Größe. Und dann liest er sogar den Dateisystem Content an der Stelle aus. Und dann habt ihr natürlich sofort Speicher-Korruption geschafft. Und das kann man sofort ausnutzen, weil wenn es auf der Datei ist, dann wird es aufhören zu lesen. Wenn du 4 Gigabyte lesen willst, dann würde es nur das Soweit lesen, wie du brauchst. Und das ist das Ideale, um eine Speicher-Korruption hinzukriegen. Also das hier ist der Bitmap-Splash-Screen-Parser von Tjanoko. Und es ist ein relativ einfaches Format. Am Ende ist es eine 4-Bit Bitmap und es gibt eine Palette von 4 x 4, also 16 bytes in den Farben. Und wenn man eine 4-Bit Palette hat, dann wird er auch nur das lesen können. Aber du sagst ihm, wie groß die Palette ist. Und wenn ihr jetzt, ich weiß, ihr habt eine 16-byte Palette, aber ich gebe dir eine 256-byte Palette und dann liest ihr das in ein 16-byte Buffer. Und das ist natürlich total kaputt, weil im Prinzip ist es genau der gleiche Problem. Und das ist jetzt nur die Spitze des Eisbergs. Da gibt es noch ganz viele, viele mehr. Es hat wirklich nicht lange gedauert, das zu finden. Aber lassen Sie einfach mal weitergehen. Natürlich, nachdem wir jetzt lokales Zeug für skalisches Zeug angeschaut hat, ist das Remote Vulnerabilities. Also Entfernung in Sachen, die man Remote ausnutzen kann. Und natürlich, moderne Systeme brauchen auch ein DCBI Stack, um mit dem Netzwerk zu reden. Und da gibt es ganz viele Services, die auch veröffentlicht sind. Also zum Beispiel Booten mit Boot P und DHCP, DNS natürlich, Netzwerk-Datei-Systeme wie Eisgasie und NFS. Dann wollen wir wahrscheinlich IP Stack, um irgendwie Tunnel aufzubauen. Dann braucht man HTTPS und TFTP zum Booten. Und natürlich, wenig überraschend, da gibt es Code für. Und dann fragst du dich, okay, was ist denn der Angriffsvektor hier? Und bei TCP-IP, wenn du versuchst, was auf den Stack abzulegen, dann viel Glück, weil du wirst es kaputt machen. Aber wenn man sich hier einfach mal zurücksehnt und überlegt, was man will. Also was man sich anschauen kann, was alles bei TCP-IP-Passen kaputtgehen kann, also da gibt es viele Schleifen und so. Und wenn man dann die Protokolle anschaut, oben drauf aufbauen, wie DHCP und DNS, da gibt es natürlich die Standard-Netzwerk-Attacken, die man ausnutzen kann, zum Beispiel Leastealing oder Cash-Päusening. Also wenn man sich da nicht, oder wenn man sich vor IDs nicht schützt, also wenn man stadsche IDs verwendet oder IDs nicht validiert oder so, dann kann man solche Päusening-Stealing- oder Mende-Mittel-Attacken machen. Und was wir natürlich auch immer gerne sehen, sind Speicherkorruptions-Bugs. Also wenn man Netzwerk-Daten annimmt, die dann passen und das falsch macht, dann kompiert man den Speicher. Eine andere Sorte von Bugs, die man häufig übersieht, sind Informationslecks. Also das manifestiert sich halt in verschiedenen Art und Weisen. Zum Beispiel bei Hardbleed ist ein gutes Beispiel. Da rast auch ein ganz einfaches Primitiv. Also grundsätzlich geht es so, dass man ein Paket generiert, da drauf wird dann geantwortet. Und wenn man zum Beispiel dann unizialisierte Daten in der Antwort sendet, dann hat man eine Informationsleck. Also sowas sieht man recht häufig. Und wenn ihr eben nach solchen Bugs sucht, zum Beispiel im Boot-Environment, oder wenn ihr ein Produkt in der Richtung baut, dann kann ich nur noch mal empfehlen, das zu fassen. Es gibt einige spezialisierte Netzwerk-Fuzzer. Es gibt da zum Beispiel ICIC, das ist schon ziemlich alt, das ist natürlich effektiv. Und es tendiert dazu tatsächlich, vieler Nazi im Netzwerk-Sex zu finden. Hier ist zum Beispiel ein Beispiel in U-Boot. Das ist der U-Boot-DNS-Code. Und TID ist hier die DNS-ID. Und sie nutzen tatsächlich die DNS-ID 1, statisch für jedes DNS-Paket, das sie raus senden. Das heißt, wenn man hier eine U-Boot-Umgebung einfach man in der Mitte hin möchte, dann weiß man die DNS-ID einfach schon, und man ist einfach immer korrekt. Also ziemlich einfach. Das hier ist Koffee von Broadcom. Das ist der CP-Parser von denen. Und es hat hier diesen sogenannten Junk-Stack-Puffer. Und hier wird dann zum Beispiel die Länge aus diesem Puffer gelesen. Und hier kann man dann zum Beispiel Nulloctal 255 lesen. Und dann haben wir hier schon die Stack-Korruption. Und der TCP-Parser ist ziemlich ähnlich. Und der TFTP-Parser genauso. Es hat auch wieder hier so einen Puffer. Und der wird benutzt, um den RX-Puffer da reinzukupieren. Und hier können dann, hier kann auch wieder in Amerika schon austreten, weil wir mehr Beizereinkupieren als Platz im Puffer sind. Also das ist natürlich auch wieder total schicker Code. Hier ist der Koffee ICMP-Händler. Und das hier ist ein Use of the Free oder Double Free Bug. Es sendet einen Ping. Und ihr seht dann hier die Schleife, in der es Pakete annimmt, bis es das Richtige findet. Aber weil es eben eine Schleife mit einem Timeout ist, hat es dann immerhin noch diese Timer- und Abbruchbedingungen. Und es kann aber auch passieren, dass, wenn es dann gleichzeitig auch Timeout mit irgendwas, dann kann das Datum zweimal freigegeben werden. So, dann ist hier noch der IP-Händler im Koffee Bootloader. Wenn, ich denke mal, die meisten von euch haben so etwas schon mal gesehen, dann hat er ja die Headerlänge und die komplette Länge. Und Koffee muss das natürlich wissen. Aber keines von den beiden Feldern wird validiert. Und das heißt, wenn man anfängt, ja, daran rumzuspielen, dann geht Koffee sehr schnell kaputt. Also das war die Übersicht zu den relativ trivialen TCP-Bugs, die man so in den typischen Bootloadern findet. Aber stellen wir uns mal vor, wir haben uns darum gekümmert. Und was kann denn jetzt noch so schiefgehen? Wo machen wir auch noch Netzwerk? Und da kommt dann natürlich WLAN in den Kopf. 802.11. Also ich weiß nicht, ob das jetzt... Also viele von den Bootloadern haben das Feature noch gar nicht. Aber ich gehe davon aus, dass die meisten Bootloader das irgendwann bekommen werden. Und dabei werden wir natürlich auch wieder Bugs bauen. Was ich hier aber bei ABBA erwähnen möchte, ist, dass wenn wir uns das Frame-Parsing von 802.11 anschauen, dann hängt das so ein bisschen von dem physischen Interface, also dem Radio, ab. Also es hängt so ein bisschen davon. Also die Validierung ist abhängig davon, welches Radio-Modell wir haben. Also nicht jedes Radio-Modell validiert die Frames gleichmäßig. Und das heißt, wenn sich der Code jetzt auf einen bestimmten Validierungsverfahren und ein Modell verlässt, dann funktioniert das vielleicht nicht mehr in einem anderen. Und das ist dann die Angrausfläche. Dann haben wir uns zum Beispiel der iPixie angeschaut. Und natürlich, sobald man irgendwas mit WLAN macht, dann sucht man nach einer SSID. Und ja, es hat dann hier eben diesen Puffer für die maximale Länge einer SSID, 255x plus 1. Und es geht dann hier eben durch die IDs durch, die es sieht. Und wenn es die IDs in das IE findet, dann zieht es diese, kopiert es diese SSID aus dem IE raus in diesen Puffer und verursacht ihr auch für die Memory Corruption, weil ich ja auch wieder die Größe nicht beeinstimmen. Okay, so, das nächste ist Bluetooth. Joe und ich haben uns ein paar proprietary Bluetooth-Bootloader angeschaut, die Bluetooth-Support haben. Aber leider können wir über diese Bucks nicht reden, weil wir unter NDS stehen. Wir haben Open Source-Equivalente gesucht. Deswegen können wir keine Beispiele nennen von Bluetooth-Bucks in Open Source-Bootloadern. Aber ich möchte allgemein darüber reden, was wir gesehen haben oder wo wahrscheinlich Bucks sein werden, wenn jemand das in Bootloader macht. Also, wenn man Bluetooth in den Bootloader macht, dann ist das wahrscheinlich HID, also Baus oder Tastatur. Aber allgemein, wenn man sich den Bluetooth-Stack anschaut oder wenn man sich nach Passing-Bucks sucht, dann gibt es drei wiederkehrende Themen oder Muster, die wir gesehen haben in den Bluetooth-Stacks, die es gibt. Und das ist, wenn man sich die unteren Layer anschaut. Das ist meistens, hat was mit Frames oder mit Frame Längen zu tun, oder zum Beispiel sehr großen Frames. Ein Frame kann bis zu 65.000 Bikes lang sein. Und wenn man sehr große Frames erzeugt, also fast zu maximal, dann bricht man die. Oder wenn man sehr kurze Frames erzeugt, oder kürzer als einige Sachen erwarten. Und dann gibt es noch Spaß mit Fragmentierung. Und dann gibt es sehr kurze... Und wenn man dann mit Fragmentierung rum spielt, dann sind mehrere Bluetooth-Stacks kaputt gegangen. Ich wünschte, ich könnte das euch zeigen. Oder ich konnte leider keine in den Open-Source-Bootlern finden. Okay, irgendwie gehen wir weiter zu USB. Das ist eine sehr häufige Attack-Service. Wenn ihr die Attacken der letzten Wochen gelesen habt, dann ist es ein paar Geräten aufgetaucht. Zumindest bis letztens war das sehr wenig berichtet. Jedes Mal, wenn ich zu einem Bootloader anschaue, dann ist das erste in VRAM und das zweite ist USB. Und USB ist interessant, weil viele Bootloader USB unterstützen. Sie benutzen es für Storage und Internet-Dummels. Aber eigentlich ist es für Storage. Oder dann macht man z.B. so eine Art Recovery-Boot von USB. Wenn man sich anschaut, wie USB funktioniert, auf sehr, sehr weit unten, dann ist es eher nicht wie TCI, sondern paketbasiert. Das heißt, wenn ein Gerät mit einem Host redet, dann wird das Gerät nach einem Descriptor gefragt. Und diese Descriptoren sagen Dinge über das Gerät. Und abhängig davon der Menge der Descriptoren und den Antworten, dann kann der Host herausfinden, welchen Wasch für eine Art Geräte bist und welche Geräteklasse ist und was für eine funktionelle Täter ist. Und viele dieser Descriptoren werden gepasst und werden falsch gepasst. Und im Allgemeinen sehen wir viel Overflows oder Double Fetches. Descriptoren funktionen so, dass es gibt eine Variable-Länge des Inhalts. Und man fragt erst nach dem Header und dann abhängig von der Länge des Headers fragt man danach. Aber das USB-Protokoll kann nicht nur den Payload holen, sondern man muss alles holen. Und das heißt, in vielen Implementierungen holt man sich den Header und tut das in den Buffer. Und dann holt man sich bei das wieder und überschreibt dann den ursprünglichen Buffer. Das heißt, man überschreibt die originale Headerlänge. Das heißt, man kann zum Beispiel das erste Mal eine gute Länge zurückgeben und das zweite Mal das was Falsche. Und wenn der Host nicht verifiziert, dass beide Länge sind, dann passieren schlimme Dinge. Normale Overflows passieren, weil niemand ein USB-Device vermutet. Das hier ist ein Beispiel in Grub. Das heißt, es holt einen Descriptor. Der Descriptor sagt, hier ist mein Konfiguration. Und es gibt eine fort definiertes Array mit verschiedenen Konfigurationen, die Grub hat. Und das nimmt aber an, dass die Anzahl der Konfiguration kleiner oder so groß ist wie das Array. Das heißt, wenn man statt zwei 65 Konfigurationen übergibt, dann beschreibt es 65 Konfigurationen in Buffer, der nur zwei unterstützt. Tiana Core hatte für ähnlich Bucks. Das heißt, hier holt er sich einen Descriptor. Und dann sagt er, jetzt gibt mir das alles. Und das der originale Descriptor war ein sehr kleines Struct. Und deswegen, das würde Speicher-Smash'n und Struct-Corruption verursachen. Und das hier, hier hat man nur den Buffer vergrößert. Und wenn man nur den Buffer in 65 macht, das heißt, jede Länge, die man ihm gibt, würde da reinpassen. Okay. Das hier ist ein Beispiel in CBIAS. Das hier ist das klassische Double Fetch. Das heißt, das macht den Header, macht den Alloc. Dann holt es den Header wieder mit den Inhalten. Und das verifiziert nicht, dass das gleich ist. Das heißt, wenn das die Funktion aufgerufen wird, kann man der Länge ja nicht trauen. Wie gesagt, USB ist eine der wichtigsten Angriffsflächen für Secret Reboot. Und ich möchte zwei neue Incidents sagen, wo das genutzt wurde letztens. Das hier ist NVIDIA TAGRA. Das heißt, man gibt ihm eine Länge, die nicht verifiziert wird. Und dann ein Mem-Copy. Und dann gibt es Speicher-Corruption. Und das letztens iPhone Checkmate ist keine direkte Memory-Corruption. Wenn man genug mit dem Zustand rum spielt, dann wird das nicht mehr synchron. Und das heißt, das gibt irgendwie ist Freed, aber nicht lebendig. Okay, damit sind wir mit USB durch. Natürlich ist es so, dass es eigentlich jeder Bus, den man am Gerät hat. Wenn deine Bootkette nutzt, dann ist er auch ein interessanter Angriffsvektor. Also hier ist es SPI, SDIO, I2C. Sogar die TPM ist interessant. Wenn keine Antwort, die man vom TPM kriegt, kann man trauen, weil wenn jemand übernimmt, dann war es das halt. Also wenn du dein TPM nicht validiert, kannst du auch mit Memory, also mit Speicherverletzungen umgehen. CPM redet hier mit TPM. Das benutzt eine Struktur, und die hat weniger Platz, seit man erwartet. Und die ziehen dann noch ein bisschen was ab von dem Strukt von der Länge weniger, als sie erwarten. Und das verursacht dann ein Integer-Underflow, sodass du eine riesengroße hast. Und diese Größe gibt sie direkt zu Malog und die Overflow dann auch. Und dann kopieren sie es woanders hin, und dann hat man wieder Speicherkorruption. Das ist im Prinzip eine doppelte Fehler. Einmal ist die Größe falsch, und das zweite Mal ist, dass Malog noch einen internen Integer-Overflow hat. Und das ist jetzt die interne Code von Malog. Es ist ziemlich komplex und ziemlich kompliziert. Ich lasse euch das jetzt mal als Aufgabe für euch als Publikum, wo der Integer-Overflow genau ist. Es ist schwer zu erkennen, weil hier viel Shifting gemacht wird, aber am Ende ist es hier drin. Noch eine Angestlöche, die interessant ist, aber nicht so oft betrachtet wird. Außer bei UEFI ist System Management Mode über die letzten anderthalb Dekaden. Also in den letzten 15 Jahren gab es unzählige Vorträge über SMM-Handler, die angegriffen wurden. Aber das ist halt viel in UEFI und viel in X86, und es war so ein Katzenmaus-Spiel, wo irgendjemand was kaputt macht. Mir macht es wieder jemand ganz, und dann macht es wieder kaputt, und so weiter, und so weiter. Und das ging jetzt, die läuft jetzt im Prinzip ab 15, 16 Jahren. Und Leute finden immer noch Fehler, aber inzwischen ist es relativ gut. Also das kriegt man nicht mehr so oft kaputt. Und es gibt leider immer noch ein bisschen Third-Party-Zeug, dass immer noch kaputt geht, also irgendwelche independent vendors. Aber jedes Mal, wenn du deinen neuen Bootloader implementierst, dann machst du die gleichen Fehler wieder, weil du wirst es ja nicht wiederverwenden, und du wirst wieder genau die gleichen Fehler machen. Das wird euch auch wieder mehrere Versuche brauchen, kosten, und deswegen müsste dich die ganzen Schmerzen auch wieder durch. Du brauchst wahrscheinlich auch 10, 15 Jahre durch. Und das ist jetzt, was Corbwood macht. Und man muss ihn zu guter halten, dass sie Range-Checks machen, dass sie das überprüfen. Und dann hier ist einfach nur eine Null-Funktion im Prinzip, also bringt halt einfach gar nichts. Auch wenn sie erkannt haben, dass es eigentlich nötig wäre. So, und jetzt habe ich schon über viele Busse geredet. Das, was das für mich unterscheidet, von anderen Sachen ist, wenn man DMA macht, also direkt in Schweihärzzugriff durch die Geräte. Sobald du DMA hast, solange es das schon gibt, dann war es das halt immer, du hast immer irgendwie ein Problem. Also wenn du eine IOMMU hast, da gibt es verschiedene Geräte, die die unterstützen, also von AMD, Intel und ARM, dann kann man das einigermaßen regulieren und man kann das irgendwie auch handhaben, wenn es sicher ist. Und dann hat man eine relativ gute Grenze für die Vertrauen, die man im Coach hängt. Also wenn ihr ein Gerät habt, das eine IOMMU hat, dann seid ihr im Prinzip da in eurem Feld schon weit voraus, weil das ist dann relativ sicher. Natürlich gibt es verschiedene IOMMUs, vielleicht gibt es ja trotzdem noch Sachen, die man da machen kann, Intel, AMD. Also die haben verschiedene Sicherheitsfeatures und die unterscheiden sich auch in der Art und Weise, wie sie funktionieren. Aber DMA ist nicht mehr so das Problem von früher, dass in dem Moment, wo es da ist, man sofort attackieren kann. Das heißt nicht, dass es automatisch geht, weil sobald man da irgendwie trotzdem noch ein Vektor hat, muss man sich dagegen verteidigen. Aber am Ende des Tages hat man das Hauptproblem, dass die Treiber, die dafür geschrieben wurden, aus einer Zeit kommen, bevor das irgendwie eine Übergabepunkt für das Vertrauen war, also eine klar definierte Grenze dafür. Das heißt, die Treiber haben oft noch Probleme. Das heißt, in dem Moment, wo man die IOMMU verwendet, muss man halt die ganzen Treiber umschreiben, sodass sie diese Grenze des Vertrauens respektieren. Und das ist halt schwierig. Und wenn man das macht und wenn man das hinkriegt und ich gebe zu, dass das sehr schwer ist, dann hat man immer noch das Problem, weil IOMMU halt eben keine Grenze ist, dann hat man immer noch ein Speicherfenster für das Gerät. Dann muss man aufpassen, dass man das immer wieder sauber macht den Speicher vor, weil sonst gibt man Speicher an das Gerät frei, was eigentlich einem anderen Programm gehört. Und selbst wenn man das richtig macht, dann hat man immer noch eine Abhängigkeit auf die IOMMU, weil man muss annehmen, dass die perfekt ist, sonst hat man Probleme. Und ich bin bis dahin noch nicht vorgedrungen, aber einer meiner Pläne für die Zukunft ist, dass ich mich an die IOMMU ran mache und dass ich dann irgendwie Fehler in der Winde, und ich habe sehr die Vermutung, dass da irgendwie Logikfehler sind und Zeit-Channel-Attacken und vielleicht sogar Hardware-Implementierungsfehler. So, jetzt sind wir an einem Punkt angekommen, wo es am Ende des Tages eine Designfrage ist, dann nicht einfach an die Implementierung. Also, wenn die jetzt schon IOMMU haben und dann damit schon ihrem Feld voraus sind und sicherer, dann wenn man in die Spezifikation guckt, dann gibt es keinen sauberen Übergabepunkt und da gibt es wieder einen Schicht zur nächsten. Also, wenn man direkt auf einen physischen Speichel gucken kann und dann wird es nicht überprüft, dann ist das ein Problem. Und ich weiß nicht, ob der nächste, wenn ich das abgebe an das Betriebssystem, ob der das sauber macht, dann kann es sein, dass das neue Betriebssystem zum Beispiel diese Grenze nicht sauber respektiert und dann ist das alles für ein Arsch. Also, einige Hersteller sind sich dieses Problems auch bekannt. Apple hat das zum Beispiel auch bei sich behoben. Aber eigentlich braucht es hier für eine Spezifikation und es dauert dann einfach immer, diese Spezifikation zu schreiben, zu etablieren, zu implementieren und so weiter. Also, so, jetzt gehe ich ja nochmal an Joe zurück. Ja, also Hardware ist jetzt nicht wirklich im Bereich, was wir in der Präsentation abdecken wollen, aber es wäre schon naiv, dass wir es nicht mal erwähnen würden. Deswegen gehen wir einmal kurz drüber. Also, was meinen wir damit? Glitching, Seitenkanäle, all das Zeug. Was gibt es bei Glitching so? Zum Beispiel Fault Injections. Also, das Induzieren von Fehlern in den Berechnungen zum Beispiel. Das ist zum Beispiel interessant bei Signature checks von Code. Und ein Beispiel, das erst kürzlich bekannt wurde, war ein Angriff auf die PS4-Syscon. Diesen Blockpost könnt ihr auf jeden Fall mal anschauen. Das ist sehr gut. Und ja, im Groben ist es im Prinzip eine Steife, die checkt, sollten wir in Debug Mode gehen, ja oder nein. Und man kann eben Fehlberechnungen reduzieren, die dann da ein falsches Ergebnis liefert. Dann gibt es natürlich Seitenkanäle mit Timing-Diskrepanten oder, wie das mit dem Stromverbrauch aussieht, oder auch um allgemeinen spekulative Ausführungsprobleme. Im Grunde genommen geht es dabei immer darum, dass wir Geheimnisse in irgendeiner Form herausgeben, die wir eigentlich nicht herausgeben wollen. Und dann gibt es natürlich Chip Security. Also, das ist natürlich nur bei sehr mächtigen Angreifen moderieren relevant. Also, Angreifer, die sehr viel Equipment haben, teures Equipment zum Beispiel, den Bootraum auszulesen über optische Extraktionen, dann kann man denen anfangen zu auditieren und so weiter. Also, das war definitiv nicht im Bereich, was wir uns ja anschauen möchten. Aber sollte man mal darüber nachdenken. Also, ja, im Moment haben das einfach noch nicht so viele Leute dieses Equipment. Aber ich gehe mal davon aus, dass Leute wie John Master und so weiter, die jetzt solches Equipment in ihrer Garage haben, das wird sich eigentlich immer nur weiter verbreiten und immer mehr Leute werden das Zug auf so was haben. Das wird billiger werden. Und das ermöglicht dann vielleicht einer größeren Menge von Leuten, der Code zu auditieren. Und senkt dann hier vielleicht die Hemmschwelle für diese Attacken. Also, es geht dann vielleicht nur noch um 10.000 bis 15.000 Euro Investment anstatt einer Million. Ja, dann geht es noch um Code-Integrität. Das machen Leute auch sehr, sehr häufig falsch. Es ist auch relativ schwer richtig zu machen. Zum Beispiel relativ schlechte oder schwache Krypto-Algorithmen. Dann gibt es so Geschichten wie Blacklisting-Probleme. Also, wenn zum Beispiel Listen auf einmal voll sind, weil man zu viel geblacklisted hat. Es gibt zum Beispiel in einem signierten Grub-Binary ein Problem, dass das dann die Blackliste voll war. Und da kann man dann ein Secure-Boot aushebeln, wenn man einfach etwas hat, das nicht in dieser Blackliste drin ist. Das ist ein inhärentes Problem, weil wenn die Blacklisten einmal voll sind, dann kann man da nichts mehr Neueste eintragen. Und dann gibt es noch solche Ansätze, die nur Teile von über 100 Teilen signieren. Das heißt, man kann dann andere Teile noch modifizieren. Oder die prüfen dann vielleicht nur irgendwelche Signaturen, dass sie existieren, aber validieren sie nicht wirklich, also eigentlich wirklich dummes Zeug. Und was kann man hier jetzt so zusammenfassen? Das ist im Prinzip nur die Spitze des Eisbergs. Also, wir haben auf viele Sachen noch gar nicht so lange drauf geschaut. Also, um das nochmal klarzustellen, wir haben die Sachen jetzt nicht wirklich auditiert, sondern wir haben wirklich eigentlich einfach nur miteinander geplaudert und halt jedes einzelne Projekt angeschaut, zum Beispiel CBoyers. Okay, schauen wir jetzt da gerade, finden wir einen Bug, haben wir eine Stunde gesucht und einen gefunden. Und wir wollten halt einfach für jeden Starkpunkt hier, den wir aufgezählt haben und entsprechendes Beispiel auch im Code haben. Das heißt, wir haben so aufgehört, sobald wir einen Punkt hatten und hatten dabei einfach ein bisschen Spaß. Also, habt auch Spaß, sucht da auch Nachsachen. Und da ist einfach viel Code, der relativ schlechte Qualität hat. Das ist eigentlich schon ziemlich verrückt. Und es ist klar, dass nicht besonders viele Leute da drauf schauen. Was natürlich auch nervig ist, ist, dass relativ schnell in die NDA-Hölle kommt, also in die Verschwiegenheitserklärungshölle. Und ja, gerade wenn es zum Beispiel in Richtung Qualcomm geht oder sowas, dann muss man im Prinzip seine erstgeborenen Opfern um da dran zu kommen. Und also, das ist schon ziemlich doof. Dann ja, vielleicht was wir so als Ratschlag mitgeben möchten. Leute sollten grundsätzlich ihre Boot-Umgebungs-Images so klein wie möglich halten, Features ausschalten, die sie nicht brauchen. Also, wenn ihr kein Netzwerk-Sack braucht, warum habt ihr es da drin, das gleiche Geld für den USB? Das erhöht alles nur die Angriffsfläche. Neuer Produkt. Und was in den ganzen Embedded-Geräten, die auf den überall Linux läuft, natürlich auch auf der Punkt, das ist das, viele von denen mehr Treiber drin haben, als unsere Desktop zu Hause, das macht alles wirklich keinen Sinn. Also schmeißt auch da die Treiber raus, wenn ihr könnt. Ja, was kann man sonst noch so dagegen unternehmen? Also, in vielen von diesen Umgebungen geht nicht immer alles. Aber ja, was wir ja auch schon heute Morgen gesehen hatten. Also, man kann da nicht ASLR oder sowas zur Anwendung bringen. Aber es gibt einen Link zu einem Github-Repository, wo ein Intel-Angestellter viele Standard-Mitigation implementiert hat für Tiano-Core. Und auch hier sieht man wieder, dass Tiano-Core ziemlich weit vorne mit dabei ist, was an typischen Mitigations angewandt werden kann. Okay, jetzt noch einen Aufruf. Wir hoffen, dass war inspirierend für ein paar von euch, wenn ihr das noch nicht angeschaut habt, dass es nur immer so eine Blackbox war, wo ihr nicht sicher wart. Und ja, baut ein paar von Ihnen selber, spielt mit denen. Habt Spaß. Und ohne die Mitigations, dann kann man mit einfachen Angriffen arbeiten. Aber es ist klar, dass viele Leute das alles revieren müssen. Leute sollten anfangen, Schwindstellen zu fassen. Und dass all das sollte mit grundlegendem Fussing gefunden werden. Und man kann einfach Tinsen nehmen und einen klassischen Diskriptor verwenden. Und nimmt einfach ein Gerät und schaut, wie es kaputt geht. Aber das ist so ziemlich alles. Gut, das war dann die deutsche Übersetzung vom Talk Boot to Roots am 36. Chaos Communication Congress. Eure Übersetzer waren Problems, Frames und Kaste. Und wir freuen uns über Feedback entweder per Mail an hello at c3lingo.org oder über Twitter mit dem Hashtag C3T. Und jetzt kommt noch das Q&A. Wurde die Grub, das knapscht Wittstern, schon gefext? Also ich glaube, das wurde noch nicht behoben. Und ja, das war einfach aus dem offiziellen Grub Repository. Okay, stellt euch bitte an den Mikrofon an. Mikrofon 2. Wenn man jetzt einen sicheren Laptop machen möchte, dann nimmt man Core Boot, nimmt man einen statischen Kernel. Das heißt, alles ist einkompiliert, keine Module. Aber was ist mit der angewusstes Fläche, wenn jemand versucht, den Bootvorgang zu unterbrechen? Zum Beispiel für DMA-Zugriff, wenn man mit einem Broadcom-Netzwerk-Device interferiert. Das ist eine spezielle Firmware, hat die den Traffic optimiert und da ein Buffer-Overflow kommt und das Problem mit dem Bus gibt. Also, wo redest du jetzt über Angrausfläche, die wir aus Gerätesicht haben können oder von Geräten bekommen? Wenn man Core Boot oder Linux nimmt, das man alles kompiliert, alles, was man haben möchte, ist im Kernel. Das bootet einfach. Und der Kernel ist im Core Boot und das heißt im Fläch. Aber man kann Probleme bekommen, wenn man die Werte einfach in den Speicherspucken. Das heißt, man kann die eben echt stark bekommen. Ja, das sind tatsächliches Problem. Und so eine der Sachen, wo man sagen muss, dass wenn man DMA so benutzt, wie es halt schon immer war, dann ist das eben genau diese Game Over-Situation. Aber wenn wir eben IOMMUs haben, was heute verfügbar ist, dann kann man eben die IOMMU auch nutzen und kompromettieren, konfigurieren. Und das bedeutet, dass wenn dann ein Gerät kompomentiert ist, dann kann das Gerät am Bus nicht mehr einfach alles übernehmen. Also ich hoffe, das beantwortet seine Frage. Ist das das Maximum, was man tun kann gegen diese Attacken? Zum Beispiel, wenn man einen sehr sicheren Laptop machen möchte. Also zum Beispiel einen gehärteten Laptop. Ich glaube schon, dass das eigentlich das Beste ist, was man so machen kann. Man kann halt nochmal schauen, was über den Bus kommt. Aber das ist so das, was mir einfällt. Man minimiert halt die Angriffsfläche so weit, wie es geht. Und dann bleibt eigentlich nicht mehr so viel übrig. Das heißt, man braucht keinen Code-Fleshing, weil man alles im Flash hat? Das heißt, wenn man ein Code-Boot im Linux-Körnel im Flash hat. Okay, wir bringen die Diskussion mal nach den Talk weiter. Signal Angel. Was ist euer Lieblings-Disassembler, den ihr beim Reverse-Engineering verwendet? Also wir reverse-engineeren den nicht, sondern kopieren das in Boot, sondern gucken uns einfach den Quellcode an. In diesem bestimmten Fall war das eigentlich alles ein Whitebox-Angriff. Also wir brauchten einfach keine Disassembler. Vielleicht ein bisschen GDB oder so. Generell, wenn wir reverse-Engineering machen, dann benutzen wir eigentlich IDAR. Wir haben ein bisschen mit Gitrarum gespielt. Es sieht alles ganz vielversprechend aus, vor allem weil es Andu also rückengig machen, unterstützt. Aber ja, normalerweise IDAR. Ich habe zwei Fragen. Was ist eure Meinung für die armen Trusted Fanfare-Activität-Tour? Ich muss damit arbeiten. Und ich bin ein bisschen schockiert. In meiner Meinung nach ist es ein bisschen zu kompliziert. Die zweite Frage ist, sollten wir die Boot-Jumps hinterfragen? Was ich gesehen habe in einem speziellen Projekt, habe ich mir gedacht, dass das Boot-Jump sehr kaputt ist. Und die Frage ist dann, ist es wirklich notwendig, dass man die anderen Sachen angreift? Also das sind wirklich gute Fragen. Was war nochmal deine erste Frage? Was denkt ihr über die armen Trusted Fanfare? Ich hatte damit schon ein paar Mal zu tun. Aber ich darf da leider nachts überreden, weil ich auch wieder NDS unterschrieben habe. Aber ich teile deine Meinung, dass da drin Sachen sind, die problematisch sind. Und was wir auch auf einer der Folien erwähnt hatten, war, dass wenn man in der Hardware schon im Bug hat, dann braucht man die Hardware-Visionen, um das zu fixen. Und das ist in der Regel relativ schlecht machbar für bestehende Deployments. Und was man zum Beispiel dann machen kann, ist, dass man im Boot-Rom ein Feature hat, um den Boot-Rom selber zu patchen. Also irgendwas, irgendeine Möglichkeit, den Boot-Rom zu überschreiben. Aber man kann immer noch nicht das reparieren, was in Boot-Rom selber ist, aber man kann halt die Menge an Code noch mal reduzieren, die nicht patchbar ist. Aber an irgendeiner Stelle muss es einen Punkt geben, der nicht mehr verändert werden kann. Ich fände es cool, wenn es da was Besseres gäbe, aber mir fällt da nichts Besseres ein. Was ich dazu noch zu sagen hätte, wäre, dass das im Prinzip auch wieder mit dem zusammenhängt, was wir so über Reverse-Engineering gesagt hatten. Also wenn Leute da anfangen, das zu reverse-engineeren, dann passieren komische Sachen und oft geht viel mehr damit kaputt, als man eigentlich erwarten würde. Und aus meiner Sicht würde es einfach Sinn machen, da auf ein offeneres Entwicklungsmodell zu setzen, anstatt das in irgendwelchen dunklen Ecken zu verstecken. Also ich verstehe nicht, warum Leute da immer so geheimnis-tour auf sind. Also... Falls ihr den richtigen Kontext habt, wäre mein Wunsch, dass man die schreibbare Chips hat, sodass ich sie selbst beschreiben kann und meinen eigenen Butterm beschreiben kann, sodass ich eine Methode habe, um Sachen zu beweisen, um die Angrifffläche zu minimieren. Na gut, und dann werden da halt 2 weitere Armkurs drauf sein, die wieder alles umgehen, was du gerade gemacht hast. Fragen was im Internet? Seid ihr von guten oder freien Buddha-Fassern? Nein, also da fällt mir jetzt nicht wirklich was ein. Wenn man ein paar Stellen erwähnt, bei alles was irgendwie um Dateien gehend oder so, da kann man AFL benutzen, das ist irgendwie das, was heute alle benutzen. Ja, dann werden Netzwerk-Fassern erwähnt, Wi-Fi-Fasser und so weiter. Also ich denke, der beste Weg, um so was zu machen, ist, die interessanten Komponenten manuell rauszuextrahieren und dann einen Harness, also quasi einen manuellen Testtreiber drumherum zu bauen und dann den Fasserdat aufzuwerfen, sodass man nicht immer den kompletten Bootprozess simulieren muss beim Fasseng. Hallo. Könnte man solche Fehler vermeiden, indem man eine andere Programmi-Sprache nimmt, die sicherer ist, zum Beispiel mehr Checks bei der Programmi-Compile-Time wie zum Beispiel Rust? Gibt es alternative Projekte, die andere Sprachen als C benutzen? Also ich glaube, das ist schon recht. Wir könnten vor allem die Speicherkorruption-Probleme beheben, wenn wir zum Beispiel so etwas wie Rust verwenden würden. Aber es gibt dabei Rust auch immer mal wieder Probleme, aber das sind darrige ziemliche Randfälle, irgendwelche Bugs in Verify oder so was. Also hinsichtlich Speicherkorruption geht einiges oder alles weg, aber von der Architektur her, vom Software-Design her bleiben immer noch Probleme und da haben wir auch viele Beispiele. Es gab zum Beispiel gestern ein Beispiel, gestern zu einer Go-Runt-Time, die auf einem Armgerät läuft. Und ja, das ist tatsächlich ein Bereich, an dem gerade erst angefangen wird, zu arbeiten. Es ist auf jeden Fall eine interessante Entwicklung, Entwicklungsrichtung. Aber derzeit sieht es mir immer noch ein bisschen zu früh aus und zu sagen, um dann definitiv das Urteil zu finden. Also hinsichtlich Speicherkorruption, ja. Aber es gibt halt immer noch Logikfehler, Hardwarefehler und so weiter. Also das ist jetzt nicht die einzige Lösung. Es gibt aber ist ein Schritt in die richtige Richtung.