 Let's have a big hand for Ilya Van Sprundel. So, Applaus bitte für Ilya Van Sprundel und dann geht's los. Wunderbar, hallo. Ja. Also der Vortrag ist, hier sind alle BSDs gleich. Eine Übersicht über die BSD-Current-Valentubilities. Ich bin Ilya Van Sprundel und arbeite für Elective. Und ich habe, ich bin seit anderthalb Jahren in Amerika, aber ich werde bald wieder nach Belgien zurückziehen. Und ich bin ein IT-Security-Konzaltend. Ich mache Sachen kaputt und werde dafür bezahlt. Und ich bin seit dem 19. C3 auf dem Kongress und schon einige Zeit hier. Ich habe auch schon ein paar Vorträge gehalten und das ist mein Siebtes. Und ja, also mein Interesse, es geht um drei oder vier Teile in diesem Talk und einige Daten noch, die ich zeigen werde. Und es gab halt nur wenig und deswegen habe ich es getestet. Und nachdem ich es getestet habe, präsentiere ich jetzt die Ergebnisse und die Zusammenfassung. Also es ist ein Vergleich der der aktuellen BSD-Flavors. Die Zuschauer erwartet da ein, einige einiges Wissen vom Unix-Körnel, nicht zu tief, aber ein bisschen. Und Leute, die vorhin schon was von mir gehört haben, ich mache Low-Level-Security und bin ein BSD-Geek. Und Links-Geist mögen das aber vielleicht auch. Und einige haben vielleicht auch Aus-Security. Alle, die sich damit beschäftigen, denen gefällt es wahrscheinlich auch. So, ich möchte noch über einige Leute danken. Ich stehe auf den Schultern von anderen, von Riesen. Und einige Leute gibt es, die interessante Sachen gemacht haben, auch im Vergleich der BSDs über die letzten anderthalb oder zwei Jahrzehnte. Und einige sind davon vielleicht hier auch im Kongress. Und einige, ja, Silvia und Thunwa. Also diese Präsentation fängt an mit einem Post auf einer Meldendiste vor vielen Jahren von Theodor Rath. Und wenn er nicht, wer er ist, das ist der Main Guide, der hauptsächlich OpenBSD macht. Und vor zwölf Jahren war das hier, habe ich das gelesen. Und das ist mir im Kopf gesteckt geblieben. Und es war im Wesentlichen so, wenn die Linux-Leute sich so viel um Qualität, wenn ihnen Qualität so wichtig wäre, wie sie behaupten, dann hätten sie nicht so viele Local-House-Colonel-Security-Löcher im letzten Jahr. Und, ja, wie viel sind das jetzt? Schon 20 dieses Jahr. Und ich glaube, das war, ja, 20, stimmt das wirklich? Gibt es Daten? Kommen wir uns die Daten dazu angucken? Und im Wesentlichen habe ich dann geguckt, was in den letzten 20, fast 20 Jahren, wie hier welche Kernel-Vulnerabilities es gab und in welchem Jahr und habt denn alles aufgezeichnet? Und es geht, fängt an, bei 1999. Und wenn man sich das anguckt hier, die ersten drei, vier Jahre ist, na ja, das ist wenig, 20 oder so. Und dann 2003, 2005 geht das massiv hoch und mehrere Hundert zum Teil. Und diese, dies ist von Juli in diesem Jahr. Also 2017 ist nicht ganz richtig. Im Juli 2017 war es 347 und 400 habe ich eben nochmal geguckt, über 400 jetzt. Und was man hier sieht, diese Zahlen sind, ja, die wachsen und werden immer größer. Und es gibt nicht dieselben Übersichten hier für die BSDs. Es gibt so generell für alle BSDs und ich wollte die spezifisch vergleichen, die einzelnen verschiedenen BSDs. Also habe ich FreeBestay auf dem BSD und der BSD Zahlen untersucht und habe eine schöne Tabelle gemacht hier. Und wenn man diese Tafeln hier anguckt für die BSDs, dann sieht man, dass die ersten Jahre sind ungefähr ähnlich wie Linux. Und dann die Linux explodiert dann irgendwie. Aber BSD bleibt mehr oder weniger das gleiche, etwas über 10, sonst meistens einstellig nur. Und 17 ist das Höchste, glaube ich. Und das war letztes Jahr. Und wenn man diese Zahlen anguckt, also das sieht so aus, dass Theo mehr oder weniger recht hatte, aber 20 eher ein niedriger zu niedrig angesetzt war. Aber für BSD und Linux, die Zahlen sind nicht gleich, nicht auf dem gleichen Niveau. Also, was ich mich gefragt habe, sind überhaupt so vergleichbar. Und es gibt eine, wenn man die BSDs anguckt, dann gibt es kleine Gruppen hier nebenbei, Linux sind ganz viele und nur wenige machen es nur selbst und so. Und da habe ich mich gefragt, ob das wirklich der Grund ist, warum diese Zahlen so sind oder ob es, wie Theo gesagt hat, wirklich an der Code-Qualität liegt. Und ja, es gibt dieses Many Eye Balls-Ding. Und na ja, ich weiß schon, wir werden viele drauf gucken, aber es ist was Wahres dran. Und ich vielleicht mal gucken, ob in diesem Fall wirklich was Wahres dran ist. Aber die einzige Möglichkeit, das rauszufinden, ist wirklich, selbst zu testen und zu gucken, wie der Code wirklich aussieht. Und na ja, natürlich, es gibt einen, der das gemacht hat. Vor 15 Jahren, Silvio, und auf Black Hat hat er das vorgestellt, 2003, 2003, vor 14 Jahren. Und was hat ein Audit gemacht, BSD-Könnels und Linux-Könnels und hat Schlussfolgerungen gezogen und was er gesagt hat, war, na ja, es gibt keinen so großen Unterschied zwischen den Linux-Könnels und den BSD-Könnels im Punkto Security Audits. Wir sind gleich kaputt und es ist gleich leicht, Bugs zu finden. Man findet die gleichen Bugs. Und so, das war vor 14 Jahren. Und haben sich die Sachen geändert seitdem und hatten nur ein paar kurze Zeiten BSD und länger an Linux verbracht. Und wenn man BSD länger anguckt, wird man mehr Fehler finden. Oder wird es eine Obergrenze geben. Und wenn man diese Präsentation anguckt vor 15 Jahren, dann hat er vor allem die meisten gefunden, triviale Sachen gefunden und Infoliks, Integer Overflows und ja, also, das sind die Sachen, die man leicht findet. Aber schwieriger sind vielleicht Race Conditions oder so. Und die Daten sind interessant, aber ein bisschen veraltet und etwas zu beschränkt. Und für die Zeit war das perfekt. Und für heute ist es nicht mehr ganz gut genug. Und also, um wirklich rauszufinden, ob diese Zahlen, woher die kommen und warum die so sind, muss ich einfach selber nachgucken. Und ich habe April, Mai, Juni in diesem Jahr BSD-Könnelcode mir angeguckt. Und ich weiß nicht genau, wie lang ich mit jedem Einzelnen verbracht habe. Und ich würde sagen ungefähr gleich. Und was ich vor allem im Wesentlichen gemacht habe, ich habe mich gefragt, wenn ich Fehler suche, wo wären die Fehler vor allem? Und wo würden die Leute die Fehler machen? Und ich habe eine Liste gemacht, wo ich gucken wollte. Und die sind nicht überraschend. Und das übliche ist natürlich SysCalls und den TCP-IP-Stack. Und dann gucke ich noch mit Treiber an, Compatibility Code, Trap Handlers, die Fallsysteme, andere Netzwerkschichten. Und ich habe ungefähr drei Monate mir das angeguckt. Und ich überspringe jetzt einige von den Sachen, bei einem von denen, aber ich diskutiere das ein bisschen. Zeige kurz, was es ist hier. Und ich habe ein paar Demos auch. Und wenn ich damit durch bin, dann werde ich die Ergebnisse und Schlussfolgerungen euch zeigen. So, fangen wir mal gerade an. Und das ist die Hauptattackservice. Natürlich SysCalls. Das ist sicherlich nicht überraschend. Und natürlich, zuerst guckt man SysCalls an. Das ist das, wo wirklich der Dichuser-Land mit dem Kernel kommuniziert. Und das Erste, was man sehen kann, ist, dass unter den beiden drei großen BSDs gibt es unterschiedlich viele System-Calls. Free BSD hat deutlich über 500. Net BSD hat fast 500. Und Open BSD hat 300. Und ein paar zerquetschte. Und da kann man schon sehen, dass es einen großen Unterschied gibt zwischen den drei. Und trotzdem, meine Annahme war trotzdem, diese sind so offensichtlich und so gut getestet, da sind wahrscheinlich eher weniger Fehler drin. Und dann habe ich mal geguckt und geguckt und durchsucht. Und natürlich habe ich ein System-Call gefahren. Das ist das Sendsys-Log. Und hier gibt es die Anzahl der Bytes. Und das wird an den Melok übergeben. Und es ist uralter BSD-Code. Und da wird eine nicht gecheckte Länge übergeben für Speichanforderungen und natürlich was passiert. Man gibt diese unter den Stützes ab. Und ich habe eine Demo. Ich weiß nicht, ob man das sehen kann, ob das auf dem Bildschirm funktioniert. So, einen Moment. Okay, ja, der ist es. Das ist, ja, ich weiß nicht, ob man das sehen kann. Also, es ist OpenBSD, das ist mein eigenes System hier. Und boom, und da ist der Kernelpanic. Ja, okay. Ja, das war das Sendsys-Log Kernelpanic. Und was passiert ist, dass das System-Call und man gibt einen bestimmten Wert aus dem User-Land. Und das macht einen Kernelpanic mit Melok. Und ich habe spätere auch angeguckt. Und es ist schon, es ist inzwischen gefixt. Aber es ist erst kürzlich, kürzlich drin. Und hier ist ein zweites Beispiel. Das ist ein FreeBSD, das ist KLD-Start. Und es gibt eine Information über Kerneltreiber. Und man hat diesen Startbuffer aus dem Stack und den Füllteen und schickt den zurück ganz User-Land. Und man hat hier ein Problem. Ich habe es in FreeBSD 11 gefunden, aber es ist schon seit über 10 Jahren drin. Und die Struktur wird nicht komplett initialisiert. Und dann wird die zurück ganz User-Land geschickt. Und mal gucken, ob ich dafür auch ein Demo habe, das zu zeigen. Das hier ist KLD-Init. Und diese ganzen Bytes hier laufen über den Bildschirm. Das ist der Fehler Nummer zwei. Und es gibt eine ganze Anzahl von Fehlern dieser Art. Und meine feuerige Annahme war falsch, als ich gesagt habe, dass ich sagen würde, System Calls sind so gut getestet, dass das sind wahrscheinlich gar nicht so viele Fehler drin. Aber das war total falsch. Und man findet Fehler in den System Calls in den BSDs. Ja, und ziemlich schnell und ziemlich einfach kann man die finden, die gar nicht zu absonderlich sind und ganz einfach straightforward. Und neue System Calls, aber auch alte Sachen, zum Beispiel zehn Jahre alt schon in FreeBSD und hat auch so einen trivialen Info-Leak-Bug. So, jetzt wissen wir, dass Fehler in den System Calls sind, die einfach zu finden sind. Und dann gehen wir weiter zu einem TCPIP-Stack. Und dies hier ist, meine Annahme war erst mal, das ist wunderbar getestet und es werden wenige Fehler drin saugen. Der TCPIP-Stack von BSD ist seit jahren seit langer Zeit gewachsen. Der ist super getestet und extrem unwahrscheinlich, dass ich da Bugs finden würde. Und TCPIP und ICMP und IP-Stack und Ethernet. Und es gibt seit ewigen Zeiten und deswegen habe ich gedacht, es ist unwahrscheinlich, dass ich daraus finde. Also habe ich geguckt und ich habe in Open im TCPIP-Stack gefunden. Und das ist etwas durcheinander hier und etwas umständlich. Aber es wird etwas übergeben und gepasst und zurückgegeben. Und wenn man genau den richtigen Tag und die richtige Fehlermeldung hat, dann passiert dieses Ding in den BSDs, wie es funktioniert in dem Stack, es sind M-Buffs und im Wesentlichen das Bumpermanagement für Daten ein und Ausgabe. Und es gibt ganz viel. Und die Idee ist, wenn man es nicht richtig benutzt, dann kann sehr viel ganz schief gehen. Und in diesem Fall, dieses hier ist M-Pulldown, die Funktion. Und wenn M-Pulldown nicht funktioniert, dann wird der Puffer freigegeben, der M-Buff. Und wenn, und dann gibt es irgendwie ein Fehlercode. Und dann wird der M-Buff freigegeben. Aber wenn es fehlt, dann wird der M-Buff zweimal freigegeben. Und das ist der Code. Und es ist relativ einfach, den auszulösen. Und es sind OpenBSD 6.1 und ist seit 2004 da. Und ich habe das, als ich diesen gefunden habe, habe ich NetBSD auch gefunden. Und NetBSD hatte denselben Fehler, aber die hatten den gefixt. Aber haben den OpenBSD-Geist nicht Bescheid gesagt, dass sie den selben haben und haben den nur selber gefixt. Und OpenBSD wusste nichts davon. Und dieser Bug war relativ einfach zu finden. Das heißt, meine Annahme war auch falsch. Um Bugs im TCP-IP-Stack sind mit einige Häufigkeit da. Insbesondere neuer Code, aber auch M-Buff-Handling ist kompliziert und fehleranfällig. Und die halbe Zeit wird der M-Buff freigegeben, wenn es versagt und manchmal nicht und so ungefähr eine Hälfte der Zeit. Und das ist dann sehr umständlich. Und man muss genau wissen, was man tut. Und es gibt eine ganze Anzahl von Fällen, wo das nicht funktioniert und es nicht richtig gemacht wird. So, jetzt gehe ich nochmal zurück. Später komme ich bei dem Wi-Fi-Stack noch auf M-Buff-Fehler zurück. Und TCP-IP hat jedenfalls auch Fehler. Und jetzt mache ich mal weiter mit den Treibern. Es stellt sich heraus, dass es sehr viele Treiber inzwischen in BSD gibt für alles Mögliche. Unix hat das Ding, wo alles eine Datei ist. Du öffnest das und dann kannst du da Sachen drauf machen. Open ist natürlich das, wo du am meisten gucken möchtest, wo du die meisten Angriffe stattfinden. Das ist die IO-Kontrolle, wo die IO-Kommand stattfinden. Und wenn man das dann auslöst, dann... Passiert das und da sind aber mehrere andere. Dann lass uns sehen, ob ich euch die Demo zeigen kann. Das ist immer noch im Laufen. Es wird nicht wirklich abstützen. Das ist net BSD. Und dann der Kryptoflohn. Und sobald ich das ausführle, kriege ich eine Memory-Corruption. Das ist ein BSD-Treiber für FreeBSD. Es zeigt euch Kernelsymbol für FreeBSD. Es hat das Interessante dringend, die für den Open-Syscalls ein. Und der Treiber. Das ist ein BSD-Treiber für FreeBSD. Das ist ein BSD-Treiber für FreeBSD. Das ist ein BSD-Treiber für FreeBSD. Das ist ein BSD-Treiber für FreeBSD. Und der Treiber zeigt einen bestimmten Detail an Poynter und zeigt auf diesen Prozess. Und hier benutzen sie ihn einfach. Und wenn ich den Detail öffne und die zum anderen Prozess weiterleite... Und wenn ich den Detail öffne und die zum anderen Prozess weiterleite... Und wenn ich den Detail öffne und den Detail öffne und den Detail öffne... Und der eine Prozess das nicht endet, dann ist er ein Poynter zu dem einen Prozess. Aber der eine Prozess ist tot. Das ist ein abgelaufener Poynter. Ja, du siehst einen Wild-Poynter, ich kann ihn anywhere zu reden und zu reiten. Und ich kann keine Demo live zeigen, weil es drei, vier Tage braucht Besicht in den Baktausführer. Und das hier ist der Screenshot davon. Das ist das, was dann am Ende passiert. Wie oben guckt, das sind dann neun Tage und eine Stunde. Das ist das Dauertes, um das zu treffen. All right, so that's it for the driver stuff. And there are many, many, many more driver examples, but I figured two's enough. So Compact Coat is the thing in the BSDs, where basically they allow the OS to sort of emulate a different OS. So if you have a free, then you put on a free BSD Linux compatibility layer and you put on a free BSD Linux for my strip libraries and stuff installed, then you put on a free BSD Linux and you put more or less perfectly on your free BSD. Dann kann man das ohne Probleme auf seinem Free BSD oder was auch immer laufen lassen. Und die haben das für verschiedene Betriebssysteme. Und gerade in Net BSD hat ein bisschen davon, und Free BSD hat ein paar und Open. Und für die verschiedenen, das sind die ältere Versionen von dem Betriebssystem. Und all das Zeug geht dann halt durch diese Schicht. Das hat eine ganze Menge an System Calls zu simulieren. Und das ist ein netter Quatsch. Das ist ein Zitat, die people, die die layers schichten, benutzen, sorgen kümmern sich nicht darum. Und deshalb sind die häufig ziemlich schlecht. Und dieses uralter Code, das hat seit 20 Jahren fast niemand mehr benutzt und aber sie unterstützen es immer noch, und das sind Streams, IOS Streams. Die sind wie Sockets, aber anders und eigentlich benutzen die nicht. Aber in den System 5 Release Forecode benutzt Net BSD das immer noch. Hier haben wir diese Funktion NetAdder to SockAdder. Und da ist ein Pointer, wo irgendwas drinstehen könnte und es gibt irgendeinen Wert und benutzt den als Offset und dann liest die Daten von da und es ist eigentlich dann ein beliebiger Pointer und man kann irgendwo aus dem Speicher irgendwas lesen und offensichtlich kann das ein Kernel Crash oder ein Kernel Info-Leak vor Sachen, aber das richtig interessant ist, in den Commons steht, ja, das ist wirklich widerlich und die wissen, dass es schlechter Code ist. Und seit 1996 ist der Net BSD Kernel der Code und ja, das ist schon seit 20 Jahren und es gibt sich einige Leute im Raum hier, die jünger sind als dieser Bug. Und ja, das ist wirklich richtig schlechter Code und ja, was Theodorat gesagt hat, der Code wird schnell schlecht und verdirbt sehr schlecht, weil er nicht gewartet wird. Und wir haben es in Net BSD Leuten gesagt und wir haben den gefixt und ja, das sollte niemals nochmals bei default aktiviert sein, das ist ein Minenfeld und die Kernel-Konfiguration ist so geändert, dass bei default jetzt das deaktiviert ist und ja. Das Nächste ist Trap Handler und Trap Handler sind wesentlich das Ding, wo irgendwas, ein exception oder fault, irgendwas Division durch Null oder Breakpoint oder ungültiger Speicherzugriff oder alle möglichen anderen Sachen und das ist, wenn die Hardware kommt und sagt, dieser Fehler ist passiert und jetzt musst du dich darum kümmern. Manche können auch von USerland ausgelöst werden und manche durch den Kernel, manche durch die Hardware und der Code, der das macht, ist sehr, sehr hässlich normalerweise, ist fürchterlich, den Code zu lesen und ich kann mir nicht vorstellen, wie irgendjemand den schreibt, aber es ist sehr spezifisch für Intel und für MIPS und für ARM, ist alles verschieden und alter Intel und neue Intel sind auch verschieden und viele Änderungen und ich habe wirklich keine Lust gehabt diesen Code wirklich durchzugucken und ich mag es, wenn ich noch bei Sinnen bin und naja, aber wie macht man Fussing auf exceptions? Und ich weiß nicht, wie man das macht, aber wenn ich einfach nur einfach zufällige Instruktionen ausführe und irgendwann kommt bestimmt irgendeine exception und ich meine, wenn ich zufällig sage, dann mache ich total zufällig, super zufällig und was ich eigentlich mache, ich lese aus DevU Random und dann macht das File außen, macht da außen executable und gibt das ein Prozess und lasst es ausführen und irgendwann stirbt der und ganz schnell normalerweise, aber mache immer ein Loop und es erzeugt alle möglichen seltsamen Traps, die der Kernel dann behandeln muss. Und natürlich, wenn man das auf FreeBSD macht, dann findet man einige Fehler, einige Bugs und ich habe nicht Sinnen benutzt, aber ein Cell Null-D-Ref und obwohl ich gar nicht Sinnen benutzt habe und einen Null-D-Referenzierung und das Seltsam ist, es ist so zufällig und man weiß nicht, wann es, wann ist ein Fehler trifft, aber dies ist eigentlich der gesamte Code, den man dafür braucht und das ist wirklich alles, was dazu braucht. Und ja, solcher Code einfach auf BSD laufen lassen und dann findet man schon einige, einige Bugs. Also das sind die Trap-Handler und damit war ich zufrieden und mehr wollte ich damit nicht mehr zu tun haben. Das Nächste sind die Dateisysteme und Fallsystems und die, das ist eigentlich das einfache, ist an den Dateisystemen, naja man mountet irgendwie ein Fall, irgendwas und dann ist das Teil des Fallsystems und das ist die Angriffsfläche, aber in letzten Jahren gibt es wesentlich neue, neue Angriffsfläche für die Fallsystems und das gibt über Fuse im Wesentlichen. Fuse in Userland Fallsystems und was das bedeutet ist, plötzlich haben diese Unix-Layers, haben eigentlich immer nur aus, aus dem Kernel vertrauenswürdige Informationen angenommen und jetzt können die mehr oder weniger vertrauenswürdige Informationen, weil es aus dem Kernel kam und plötzlich kommt alle diese Daten für das Fallsystem-Layer kommen aus einem Userland-Prozess und jetzt kann man nicht mehr davon ausgehen, dass die Daten vertrauenswürdig sind und die Fuse-Implenationen der verschiedenen BSDs sind alle verschieden und Fuse und BSD, das ist natürlich alles bestimmt dasselbe überall und als ich rausgestellt habe, das stimmt überhaupt nicht, alle drei BSDs haben die Fuse-Implenation alle komplett unabhängig voneinander implementiert, es gibt keinen gemeinsamen Code und sind völlig verschieden und mein, als ich es aufgeschaut habe, das Net-BSD ist das kompletteste, hat die meisten Features, Free-BSD ist das, wo die Argumente am besten kontrolliert und constrained sind und Open-BSD ist irgendwie, hat die minimale, die kleinste Funktionalität und die wenigsten Features implementiert, verglichen mit den beiden anderen. Und wenn man Fuse anguckt, unterstützt Eier-Control, aber keine De-Implimentationen implementiert das, aber das meiste andere ist implementiert Read-Write, Redirectory, Get-Attributes, Set-Attributes und Zeug wie das. Und dies ist Open-BSD, Get-CWD-Scandia, ein Bit von einem System Call aufgerufen und die gehen um den File-System-Layer und holen dieses Attribut und man hat dann diese Struktur, und in der VA-Struktur ist das meiste, ist zuverlässig, weil es aus dem Kernel kommt, aber in Fuse ist VA nicht mehr vertrauenswürdig, weil es aus dem Fuse-Avent kommt und dann nimmt man die Länge daraus und übergibt sie an Merlock und ist eine unbekannte Wert für Merlock und das ist natürlich ein Bug und wenn man noch etwas weiter guckt, da gibt es dann CWD und es ist ein anderer auf dem File-System-Layer und man bekommt diese UIL-Struktur und früher, wenn man das gemacht hat, dann kam das, war das File-System-Daten, aber es kam aus dem Kernel, File-System-Dreiber und es war mehr oder weniger vertrauenswürdig und dies ist einfach nur eine Pufferlänge und weil der Inhalt aus dem User-Land kommt, kann man dem nicht mehr vertrauen und wenn man das passt, dann die Länge eines Eintracks im Directory nimmt man an, dass es gültig ist mehr oder weniger und benutzt das dann für ein Memm-Move und das kann einem auch zum Problem führen und das ist das Problem mit Fuse und das ist in Linux vermutlich auch, aber ich habe es mir nicht genau angeguckt und wenn man Sachen mit Fuse macht, dann muss man den File-System-Layer modifizieren, weil es annimmt, dass die Daten, die aus dem File-System kommen, gültig sind, aber das stimmt halt heute nicht mehr. Für die anderen BSDs, die hatten ganz ähnliche Fehler und dieser spezielle Bug ist seit 2006 da, aber Fuse ist noch gar nicht so alt, das heißt, es ist erst seit kurzer Zeit eigentlich ein Problem und wenn man den File-System-Handler selbst anguckt, dann der Teilsystem, den man meint, das ist das X2, der X2-Layer für FreeBSD und ich habe kurz angeguckt, nicht erschöpfen gesucht, aber einfach nur dieses Be-Read gesucht und ich habe den String gesucht und wenn es den String nicht findet, dann macht es gleich ein Panic und das heißt, ja, und wenn es einfach nur ein String nicht findet, macht es gleich ein Kernel Panic und das ist natürlich, ja, und die File-System-Layer in BSDs sind nicht wie sie sein sollten und wenn man das dann Fuzzing macht, dann wird es auf interessante Arten total kaputt gehen und dies ist wirklich ziemlich kaputt und ja, es geht davon aus, dass die File-Systeme heil sind und es gibt seit 7 oder 8 Jahren oder so und wenn man die File-Systeme weiter unter Druck setzt, dann findet man sicher noch mehr. So, ja, networking beyond TCPIP-Stack, Netzwerk weiter als der Stack in diesem Blutes- und Wi-Fi, aber ich habe wirklich nur Wi-Fi hier. Wenn man dann die Wi-Fi-Angriffsfläche guckt, dann gibt es zwei Sachen, die man gucken muss, dann ist das einmal der Stack selber und dann die Wi-Fi-Tribe. Und dann früher gab es dann das ein Stack-Up und der Treiber geht dadurch, aber heutzutage kommt der Treiber mit seinem eigenen Stack und jetzt ist es ein Stack für all die Treiber. So, ja, der Stack ist, sort of, it looks like the TCP-Stack. I mean, the Stack looks, it's all in buffs, it's in and out, it's stuff that gets passed. The Stack is all in buffs und das geht in, rein und raus. Die Haupt-Input-Funktion ist EE-0211-Input, und das ist das, was die Daten, das ist das, was für alle Wi-Fi-Triber gibt. Und das kümmert sich um die Epo-Keys, und das hat verschiedene Längen. Und diese Funktion validiert die Länge, um sich jetzt machen, dass es verschiedene Buffer sind, die sich zu den Grenzen ist, die tatsächlich Länge hat. Und das stellt sich heraus, dass das tatsächlich über das Ding hinaus liegt, über dem Buff hinaus, dies. Und wenn der Link dann länger ist, als der Payload-Link, dann geht es um den Nose. Und das kann bei Wi-Fi-Frames ausgelöscht werden. Und das kann bei Wi-Fi-Frames ausgelöscht werden. Und das kann bei Wi-Fi-Frames ausgelöscht werden. Und das kann mit dem T SPIP Stack-Part. Das war nicht 6.1, aber der Bug war schon neun Jahre hier. Die Wi-Fi-Tribers sind der interessantepart. Wi-Fi ist entweder PCI oder USB, aber USB ist anders, und es kommt zu der Frage, vertraut ihr euerm Wi-Fi Radio? Und von daraus kann man das Betriebssystem dann übernehmen. Wenn euer PCI, nehmen wir es an, dass es PCI ist und es wird falsch behandelt. Und USB-Protokoll sind eigentlich Paketbasiert und man müsste die Pakete sauber pasen. Stellt die heraus, dass der Colonel das nicht tatsächlich tut und das führt zu abstürzen. Und ich glaube ich nur fünf Beispiele. Das ist ein Treiber, wo es einen Längenfeld gibt und das geht dann zu, das ist ein Cluster, der 2000 bytes lang sein kann. Und das geht dann zu dem Cluster und prüft nicht weiter, ob das wirklich so lang ist. Und das ist ein anderer Wi-Fi Treiber. Und man sieht, dass man das und man nimmt das aus dem USB-Paket und kopiert das und zieht dem Buffer zu 2000 bytes und dann passiert das genau das gleiche. Und dann ist es noch ein gleicher anderer Treiber, wo man den Mem Copy nimmt und damit den Crash auslöst. Und da gibt es noch viel, viel mehr. Und OpenBSD, da gibt es ganz viel, da gibt es einen AdMil, da gibt es Netos, da gibt es sehr viele Wi-Vertreiber. Dieser Code vertraut den US-Paketen ziemlich und nimmt an, dass alles richtig ist. Und man hat wahrscheinlich lieber diesen Attack-Weg gedacht. Das ist mehr oder weniger für die Attack-Flächen, die ich habe. Da gibt es ein paar Sachen, an die ich noch angeguckt habe, über die ich noch reden möchte. Zwei Sachen, die aufgetaucht sind, da waren einige Bugs drin. Da waren einige einfach zu ersehenden Null-DRFs in dem BSD. Und wie man diesen Melok aufholt, dass man einfach einen Fleck weiterreicht. Und in dieser Fleck ist no weight. Das ist einfach, dass der Melok immer wartet und nicht wartet, wenn es scheitert. Und das meint, wenn es das nicht in einer bestimmten Zeit erledigen kann, dass er dann den wegschmeißt. Und wenn man, wenn das scheitert, dann kriegt man diesen Null-DRF. Und als Standard denkt man, dass es ein einfaches Pattern ist, der gemeine Weg, wie die Meloks aufgerufen werden, ist, dass es niemanden abstürzt. Aber man muss das, wenn man dieses Null-Waid-Fail ausführt. Und da gibt es einige Fälle, wo Melok Null-Waid-Can scheitern. Ich verstehe nicht, warum Leute das noch nicht. Und ich repariert habe. Ich kann nicht mehr erinnern, ob es 15 oder 20 Jahre in den BSD ist. Die BSDs haben ein Instrumentalist Rendering in ihrem Kernel drin. Das ist für die, die wissen, das sind quasi die Grafiktreiber in einem Kernel, wie der Kernel zu den Grafiktreibern redet. Und das ist alles dann DRM genannt oder DI. Und das kommt von den Open Desktop-Leuten und das ist eigentlich separat in, weggeworden. Das ist ein paar Jahre in den Linux-Körnel umgewandelt. Und das, dann haben die BSDs auch gemacht, sind es mehr, wenn der gleiche Code-Basis. Und daran wird nicht heutzutage nicht mehr viel gemacht. Und wenn man dann den, dass sie, die Probleme sieht, die die damit haben, wenn man Open BSD ist, verantwortlich, die DMI zu maintain. Und sie weigern sich, Code-Review-Standards zu lesen, dass nicht zu den BSD-Standards passt. Das bedeutet, dass sie das nicht anrühren werden. Das ist alles in Open BSD, Free BSD, Net BSD auch. Das ist mehr nervig, um durch die Bugs, die ich gefunden habe, durchzugehen. Ich könnte zwei, drei Stunden damit machen, aber es würde ziemlich langweilig werden. Was war mein Ergebnis? Aber so nach drei, ungefähr drei Monaten habe ich 30 Bugs in Free BSD gefunden, 25 in Open BSD und 60 in Net BSD. Es war ein großes Spektrum an vielen, dann gab es Technischen, Integrations- und Overflow- Issues, Logik-Bugs. Da gab es ganz verschiedene Fehler, ganz sehr unterschiedliche Fehler. Da war es, dass auf der falschen Struktur passiert war, dann schreibt Fehler im Code war. Das war alles, was man sich vorstellen können, was da drin ist. Das wurde auch bei Menschen gemacht und auch die haben Fehler ausgelöst, produziert. Ich habe Fehler zwischen den allen den BSDs, die ich genannt habe, gefunden. Sobald man zwei, drei von denen verstandert, wie die funktionieren, man kann einige Beobachtungen über die Code Qualität machen. Ich denke Open BSD ist der klare Gewinner, was die Code Qualität angeht. Aber Code Qualität ist nur ein Teil. Es ist auch die Code Qualität, die auch die Angriffsreproduktion, was Open BSD zu dem Winner führt. Open BSD hat die Angriffsfläche sehr weit reduziert. Sie haben keine ladbare Module, sie haben praktisch keinen Deadcode, keinen Bluetooth-Stack, der ist komplett rausgenommen, weil es zu schlecht war und kein Compatibility mehr und weniger System Calls und 200 weniger als Free BSD und sie haben viele alte Architekturen auch ausgeschmissen und das zusammen mit Code Qualität führt dazu, warum Open BSD doch so gut aussieht, verglichen mit den anderen. Und die einfachen Sachen, die einfach zu fixen sind, wo am meisten Fehler auftreten, Vorzeichenfehler und so was, das ist alles entfernt, im Wi-Fi-Treibern sind die immer noch drin Open BSD, aber die haben ihre Angriffsfläche so weit reduziert und da gibt es kaum Overflows, keine Vorzeichenfehler und weil sie einfach wissen, dass es so ist und haben ihren Developern gezeigt, wie es aussieht und bei jedem Commit wird reviewed von einem oder zwei Leuten mindestens und diese Leute wissen genau, wie diese musste aussehen und wie wir es und Integer Overflows passieren auf dieser Angriffsfläche einfach nicht mehr und gab weniger Informationsleaks aus dem Kernel. Net BSD ist der klare Verlierer hier und hat 60, mehr als die beiden anderen zusammen und Net BSD war am schlechten ganz viel Uralter Code, ganz viel Compatibility Code und ja, wenn man Legacy und Compatibility Code noch hat von 1996 und nicht mehr angeguckt hat, natürlich sind der Fehler drin und es gibt noch diese ISO-Protokolle und ich weiß nicht, ob die irgendjemand überhaupt noch benutzt, also das ist Code aus den 1980er von IBM und irgendwann ein Net BSD importiert und niemand weiß, was es macht und warum es da ist und viel von diesem ganz uralten Code und es ist weniger konsistent, die Security Code Qualität ist schlechter als auch bei den anderen, weniger konsistent und die haben ganz viele, viele, vorzeichen Fehler und Integer Overflow und so und also ist das die Unterschiede, der Unterschied im Code Qualität ist schon da, aber ich will Net BSD hier nicht runter machen und sowas, einen Betriebssystem zu bauen und zu warten ist sehr, sehr schwer und aber es ist schon ein großer Unterschied, wenn man sich die beiden anguckt, dann sieht man, dass in der Code Qualität wirklich hier eine große Unterschiede ist, wenn man diese Angriffsfläche sich anguckt und Free BSD ist irgendwo dazwischen so, ja, es ist schwer, das genau festzumachen, die Code Qualität ist nicht so schlecht wie Net BSD, aber es ist nicht so gut wie Open BSD und ich habe, als ich die Fehler gefunden habe, habe ich natürlich mit den Teams gesprochen, habe E-Mails geschrieben und sagte, hier sind die Bugs, die ich gefunden habe und die sollte vielleicht die mal eben beheben und Open BSD Leute und Theo hat dann geschrieben, ungefähr nach einer Woche oder so, tut mir leid, ich habe eine Woche gebraucht, ich war ja leider im Urlaub und alle diese Fehler sehen so aus, das ist wirklich ein Problem und dann hat er gesagt und den nächsten Tagen hatte dann nach und nach die Bugs alle gefixt und so und klar und nach weniger als einer Woche hatte alle gefixt eigentlich und ja und ein paar Wochen später waren die Open BSD Leute im Wesentlichen haben Patches gemacht und so und wenn jetzt Open BSD hast und die Bugs hast, hier sind die Patches und so und dann kannst du das, das ist wunderbar, so sollte das sein, es ist alles richtig gut, innerhalb von einer Woche, ein paar Tage sind die Fixes da, dann sind die Fixes und ein oder zwei Wochen danach sind alle Patches öffentlich verfügbar und es gibt die Advisories und so sollte das sein und so sollte der Security-Prozess stattfinden, Open BSD hat alles richtig gemacht so, weil ich das sehen kann. Free BSD und es fängt ähnlich an, ich habe nach ungefähr ein paar Tagen, nach einer Woche habe ich eine Antwort gekriegt und dann habe ich eine Antwort gekriegt und wir haben die in unsere Backdatenbank getan und das war am 15. Juli und das ist aus der E-Mail und sie haben das alles rausgestrichen, was noch nicht gefixt ist und ein paar wenige sind gefixt und seit der E-Mail ist noch nicht viel passiert, das ist jetzt fünf Monate später, zwei Releases sind wieder released worden, zwei sind gefixt, ein dritter ist und ich habe einen C-Vez-Commit dafür gesehen, dass es gefixt die anderen weiß ich nicht, ich glaube die sind noch nicht behoben, ich habe C-Vez noch mal nachgeguckt und anscheinend sind die immer noch in der Schwebe irgendwie und noch nicht wirklich gefixt und so sieht das im Moment bei Free BSD aus. So, Net BSD, am Anfang, ich habe Ihnen diese Fehler geschickt, zuerst habe ich Ihnen eine Liste von 60 Fehlern geschickt und die haben über Nacht die Fehler alle behoben. Ernsthaft? Wirklich. Und das ist unglaublich eindrucksvoll und ich weiß nicht wie man das machen kann, aber das war ein paar Developer, oh lass uns das gerade jetzt eben alles fixen hier, wir machen das gerade fertig, das war super eindrucksvoll und das ganze System Five Release Force Hub System ist dann raus und die haben wesentlichen E-Mail geschrieben, wir haben jetzt SWR Five BodyFold abgeschaltet, das sollte da nie drin sein sollen und das war im Juli 2017 vor fünf Monaten und ich will erzählen was seitdem passiert ist überhaupt nichts. Im C-Vez sind die Fehler behoben, keine Patches, keine Advisories, was das bedeutet ist, wenn man, wenn Net BSD läuft alle 60 Bugs sind noch da und man kann ins C-Vez gehen und kann sehen was der Fehler ist und ich wünschte sie hätten das weiter verfolgt mit Patches und Advisories und das ist, die haben super angefangen und dann haben sie es irgendwie verloren und nicht weiter gemacht. Jetzt zurück zum Anfang und ob das vergleichbar ist alles und die Bugs sind immer noch einfach zu finden im Colonel, selbst in Open BSD, selbst Open BSD ist auch, ich habe einige Sachen in Open BSD nicht gesehen, aber es war nicht wirklich schwer die Sachen zu finden und es ist eine sehr unterschiedliche Qualität zwischen denen und es liegt daran wer es geschrieben hat und wie alt es ist unter welchen Umständen es geschrieben wurde. Die konsistenteste Qualität war in Open BSD und es liegt daran, dass sie einen rigorosen Review Prozess haben und jeder CVS Check-in wird reviewed und dass ein Prozess anscheinend funktioniert, außerdem DRM-Stuff und die DRM Sachen sind genauso schrottig wie bei allen anderen und weil sie es nicht wirklich anfassen wollen. Was anderes ist noch, was ich noch denke, was passieren sollte, ich habe einige Bugs gefunden, wo ich gedacht habe dieser Bugs in Open BSD, aber nicht BSD gefixt oder umgekehrt und das ist nicht BSD und Open BSD hat es vor 15 Jahren gefixt und so, diese Sachen sind zum Teil passiert mit einer gewissen Häufigkeit und ich habe idealerweise sollten die Maintainer mehr miteinander sprechen und natürlich ist es einfacher gesagt als Getar, denn in den letzten 15, 20 Jahren sind die schon auseinander gegangen, die haben unterschiedliche Philosophien und so und es gibt bestimmte Egos auf manchen Seiten und das macht auch nicht immer Sinn als gleich zu machen, aber es gibt noch viel Gemeinsamkeiten zwischen den BSDs und wenn es um die Angriffsoberfläche geht, Angriffsfläche, dann wäre es wahrscheinlich sinnvoll, dass die mehr miteinander reden. Die andere Sache ist, wenn es um die Codebase gehen, nur um die Codebase, dann hat man schon Open BSDs 2,8 Millionen, net BSD 7,3 Millionen und Free BSD ist, ich weiß nicht, was es jetzt ist, Free BSD war ungefähr 9 Millionen Lines of Code und Open BSD kann natürlich weniger Fehler haben, weil sie weniger Code haben, aber man kann natürlich keine Fehler haben in Code, den man gar nicht hat und das andere ist natürlich, manches ist zufällig oder geplant, wenn man irgendwas nicht hat, dann hat man es nicht, aber was offensichtlich haben sie einige Entscheidungen getroffen, Code zu löschen und Open BSD hat das zum Beispiel gemacht, sie haben Bluetooth komplett gelöscht, sie haben den Linux Competibility Layer entfernt und so man verliert Funktionalität, aber gewinnt an Sicherheit und das ist natürlich eine Balance, die man finden muss und wenn man verliert Sachen, aber man hat weniger Bugs und noch mehr Folgerungen, mehr Schlussfolgerungen und das Ding mit den mehreren Augen, die das angucken und das ist wirklich ein Faktor und wenn wirklich mehr Leute was angucken, dann findet man mehr Bugs. Und ich glaube, ein der, warum man die Tabellen vergleichen kann, ist mehr Leute gucken den Linux Kernel an, deswegen finden sie mehr Bugs, Code Quality kann natürlich nicht alles erklären. Und ich meine, man kann sagen, was man will über den Linux Kernel, aber es sind so viel mehr Leute, die diesen Code angucken und natürlich finden sie mehr Bugs und das sieht man an die Zahlen und ja, das ist es im Wesentlichen. Das war erschreckend, super. Und ich bin überzeugt, dass ihr Fragen stellen wollt. Lassen, lassen mit den Fragen, mit dir da drüben einen Satz, einen Fragezeichen. Danke für deine tolle Arbeit und eine tolle Präsentation. Ich habe einige Fragen. Bissmann, interessiert das auszunutzen und du hast einen Crash. Und wie wäre es damit, damit eine privilegierende Kollision zu machen oder ähnlich? Ja, mein Plan war ursprünglich, alle Bugs zu berichten und dann habe ich nicht vorgesehen, Explods zu schreiben und das Einzige, was ich, wenn ich Explods schreiben wollte, dann würde ich, dann ich schreibe kein Explod für ein Bug, von dem ich weiß, dass er gefixt wird und einige Bugs da hätte ich Wochen oder Monate gebraucht, dafür kurz zu schreiben und ich glaube, das wäre nicht besonders sinnvoll gewesen, dafür Explods zu schreiben. Ich weiß, ja, das ist ein Schockerfaktor, den Explod zu machen und meine Annahmen, ich dachte, wenn ich mit Leuten wie Theo spreche, der wirklich sehr sensativ ist da, da brauche ich keinen Explod zu schreiben und wenn Explods zu zeigen, hilft normalerweise, Leute zu überzeugen, die Sicherheitsprobleme haben. Ja, die Fehlerbehebung ist super und Mitigation und da sollten wir uns darüber und halten und danach suchen, aber ich glaube, das hätte nicht viel beigetragen dazu. Das ist eine Frage aus dem Internet. Wie würdest du vorschlagen, die Kooperation zwischen PSD zu verbessern? Gute Frage, weiß ich auch nicht. Ich weiß, dass Theo einige Sachen gesagt hat und ich will nicht mit den Leuten reden wegen so und so und so und am Ende des Tages, am Ende müssen die Leute irgendwie doch miteinander sprechen und es gibt einige Unterschiede zwischen denen und wo sie wirklich unterschiedlich ist, da müssen sie nicht so viel darüber sprechen, aber ich weiß nicht wirklich, wie man es machen soll, um sie dazu zu bringen, dass sie miteinander reden, aber vielleicht die Maintainer für ein bestimmtes Subsystem zu finden, wenn man was fix, dann sagt man es dem Maintainer von dem entsprechenden anderen BSD und schreibt eine Mail und sagt, guckt vielleicht mal, wie das bei euch ist, ansonsten habe ich wirklich keine gute Antwort darauf. Gibt es eine andere Frage aus dem Internet? Nicht jetzt. Eine letzte Frage, wir haben fünf Minuten mehr. Ich sehe da hinten nichts, wirklich was. Auf der linken Seite, meine Frage ist die über die Durchführung. Hast du alles bei Hand gemacht oder automatisch? Ich kann die nicht sehen. Ah, ah, da, okay. Ja, ich habe, nein, nicht automatisiert, wirklich, sondern es war einfach nur ein Code-Review, ich habe den Code gelesen, im Editor aufgemacht und manchmal habe ich hier Grep benutzt, um bestimmte Muster zu suchen, aber sonst eigentlich fast nur ich, der ich den Code gelesen habe und das war es im Wegesen nicht in keine anderen Tools oder so. Ich nehme doch eine Frage mehr und hier, möchtest du? Jetzt deine große Chance. Was ist deine Motivation, drei Monate alles zu verwenden? Ja, ich weiß, Code-Review ist nicht jedermanns Sache, aber ich manche sagen, es ist langweiliger als Farbe beim Trocknen zuzugucken, aber mir macht das Spaß, ich lese gerne Code und ich finde, dass man viel davon lernen kann, wenn man Code liest und es gibt diesen interessanten Kick, kriege ich davon, wenn ich einen Back finde und ich lese den Code und denke, oh, und das ist nicht richtig hier und davon, das ist ein bisschen Teil der Antwort und im Wesentlichen macht mir das Spaß. Vielen Leuten nicht, weiß ich wohl, aber für mich war das kein Problem, ich hatte kein Problem damit und ich habe nicht ununterbrochend daran gearbeitet, immer mal wieder an Wochenende und so, aber es war nicht so schwer oder besonders schwierig, sondern ich gucke jetzt mal mal drei, vier Sachen die Systemcodes an. Ich fand es nicht so schwer, ich verstehe es nicht, jedermanns Sache ist, aber mir macht das Spaß. Vielen Dank für deine Arbeit. Vielen Dank, es übersehe ich irgendwo eine Frage, nein, jetzt ist eure Chance, da ist eine Frage aus dem Internet, aber wenn die BSD nichts kooperieren, ist es irgendwas in oben überhaupt, wo sie sich reinigen können? Das ist keine Frage, die nichts mit der Security zu tun hat und das weiß ich überhaupt nicht und da gibt es andere Leute, die diese Art BSD-Frage bestimmt viel besser beantworten können, ich habe keine Ahnung. Noch mal einen großen Applaus, bitte.