 Hallo, du hörst gleich mit einem Skalpell an QNICS vom 34. Chaos-Communication-Kongress in der Übersetzung von OS 10.000 und Philippe. Wir machen hier eine ganz tiefe Analyse des QNICS Betriebssystems. Willkommen an John und Ali. Willkommen. Wir analysieren und brechen die Verhinderungsmethoden zur Ausnutzung. Ich bin von der Universität Twente in den Niederlanden, wo ich Infrastrukturschutz studiere. Mein Name ist Ali und ich bin Dr. Rand in Eindhoven und ich bin hier ein Besucher in Bochum und meine Forschung konzentrieren sich auf embedded binaries. Also wir fangen mit einer Übersicht von QNICS an, dann schauen wir uns die Sicherheitsarchitektur an Zufassgeneratoren. Was ist QNICS? QNICS ist so etwas, QNICS ist POSIX kompatibel, es ist ein privates, also nicht Open Source, es ist später von Blackberry gekauft worden, bis 6.6 ist es 32-Spit, ab QNICS 7 dieses Jahr ist es 64-Spit. Am bekanntesten ist es, weil es in Blackberry 10 ist oder in Blackberry Tablet drin ist. Aber das ist nur oben die Spitze des Icebacks. Es ist viel weiter verbreitet in der Automobilindustrie, in Fertainment hat es über 50% des Marktes und es ist in den selbstfahrenden Autos. Also Delphi nutzt QNICS als die Basis. Die zweite Nutze ist in großen Routern, in Cisco-Routern, hier in dem CRS 12000 und ASR 9000. Auf der rechten Seite hat man gesehen, warum es ein interessantes Sicherheitsziel ist. Es ist in Industriekontrollsystemen, in Kernkraftwerken, in Militärsystemen, in Kontrollsystemen für Raketen. Und da ist es natürlich klar, dass das Sicherheitsimplikationen hat. Letztes Jahr haben wir auch ein bisschen was von diesem Thema angesprochen. Wir haben über den Zufassgenerator gesprochen und wir in VXWorks funktioniert. Und hier in diesem Tag schauen wir uns den Userspace und Kernespace von QNICS 7 an. Und wir schauen uns an, was die Problemverhinderungen, die Mechanismen, die Exploit-Mitigation in QNICS 7 sind. Machst du mal? QNICS Sicherheitsarchitektur. QNICS ist ein Mikro-Kernel, ein echter Mikro-Kernel. Es bedeutet, dass die meisten komponenten Sicherheitskommenten außerhalb des Kernels sind. Also Sachen, die man im Kernel erwartet, sind nicht mehr im Kernel drin. Sachen, wie die Treiber fühlen und Stacks sind außerhalb des Kernels. Das man hat ist ein sehr kleiner Mikro-Kernel und das hat ein paar Vorteile. Der größte Vorteil ist, dass man eine höhere Verlässlichkeit des Systems hat. Also dass das System weniger crasht. Da gibt es weniger Seil, woran man sich aufhängen kann, weil es wenig im Kernel gibt, den man angreifen kann. Und Mikro-Kernels kriegen höhere Sicherheitslevel von der NSA zum Beispiel. Das ist der Mikro-Kernel. Aber wenn man alle diese Sachen außerhalb des Kernels packt, wie arbeiten die dann? Was man hier hat, ist eine Message-Verbindung, irgendwie so etwas ähnlich zu einer Netzwerkkommunikation. Und die Anwendung möchte mit dem Dateisystem kommunizieren. Es schickt eine Nachricht zu dem Mikro-Kernel. Der Mikro-Kernel leitet es weiter zu der Zielanwendung. Und das wird beantwortet und dann wird es wieder zurück zur Anwendung geschickt. Und das ist die Nachrichtenverbindung. Und die Aufgabe des Kernels ist halt diese Nachrichten weiterzuleiten. Aber ein interessantes daran ist an diesem Konex-IPC-Masch-System. Das hat ein System, wo es mehrere Mikro-Kernels gibt. Und diese beiden, zum Beispiel zwei Mikro-Kernel, können über das Netzwerk kommunizieren. Konex unterstützt auch Sys-Calls. Und dabei ist es deutlich weniger funktional, weniger als 90. Konex ist also posic-kompatibel. Man kann die Standard-Bibliotheken verwenden. Und das hier ist jetzt nun Konex-Compiler. Und dieser Compiler verwandelt das dann zu diesen Nachrichten weiterleiten. Für die Nachrichtenmann hat den Nutzer-Bereich und den Kernel-Bereich. Und es gibt eine User-Space-Trennung. Und da gibt es keinen Prozess, wie die sich miteinander kommunizieren können. Um das halt ein bisschen Sicherheit. Zum Beispiel privaten Speicher. Aber es hat auch Kommunikationsmöglichkeiten wie Unix. Und dies ist ein Unix-Memory-Design. Also, man hat ein Programm-Image. Und basically L-Floater in dem Mikro-Kernel basically load it. Und dann hat man, wie gesagt, ein Mikro-Librator, in dem man hat. Aber in dem Kernel-Space, Kernel-Raum, die Adresse startet an einer schattischen Adresse. Und die haben differen Stacks. Also, lass uns mal aufs Prozessmanagement schauen. Das ist ein bisschen anders. Es gibt ein Prozess, der heißt Prochentio. Und der ist der Prozessmanager. Und die anderen Prozesse sind im User-Space. PID1 ist der Prozessmanager. Und er spricht mit dem Mikro-Kernel genau wie andere Prozesse. Aber er hat ein Flag, was also hier dieses NT-PF Ring 0 ist, wenn er den Syscall aufruft. QNX unterstützt alles, was Prozesse anbietet. QNX uns das L-Format. Wenn das Filesystem auf einem blockerorientierten Gerät, dann werden Code und Daten in den Hauptfrächer geladen. Wenn das Filesystem ein memory mapped ist, dann wird das direkt im Speicher genutzt. QNX bietet auch Sandboxing an. Das heißt, so ähnlich wie Linux-Capabilities gibt es den Prochmanager-Ability. Und das heißt, man kann bestimmte Fähigkeiten erlangen, bevor man Route-Fähigkeit, Route-Ortonisierungen abgibt. Es gibt domain range inheritable locked. Und das sind also die Attribute, die eine Capability haben kann. Und die Systemintegratoren entscheiden, wie sie diese Funktionalität einsetzen wollen. Das nächste, was QNX unterstützt, ist User-Management. Es gibt ein Passwort-File, es gibt ein Shadow-File, es gibt ein Groups-File. Und es gibt Utilities, so was wir loggen, Switch-User. Und es gibt Mandatory Access-Controllers. Es gibt eine zwangene Zugriffskontrolle. QNX 6 unterstützt hash Algorithmen. Wie hier steht, Schad 256, 512. Und es gibt auch Rückwärtskompatibilität mit MD5. Das heißt, man kann die Geräte, wo die Passworte in dieser Form gespeichert sind. Und deswegen gibt es also eine lange Zeit, die die Attacker das noch nutzen können. In QNX 7 oder in einem aktualisierten 6.6 gibt es auch moderne, wie im PDFK2. Die Geschichte von QNX Security sieht wie folgt aus. Blackberry Mobile hat angefangen mit dieser Sicherheitsforschung zu dem Thema. In 2016 gab es von Alles Pluggedirt einen interessanten Talk zu IPC in QNX. Ich empfehle, dass ihr euch das anschaut. Und dann gab es zwischen 2000 bis 2008 verschiedene Löcher in dem Betriebssystem. Aber das Interessanteste war von WikiLeaks CIA Vault 7. Und da steht drin, dass die CIA, die CIA wollte QNX eindringen. Sie hatte es in 2014 noch nicht geschafft. Es gab also keine vorausgegangene Arbeit dazu, wie man das Ding härten kann. Und wir haben über die Zufahrszahlengeneratoren von QNX 6.6 und 7 gesprochen. Also das ist jetzt unser Thema Zufahrszahlengeneratoren. Warum schauen wir uns den Zufahrszahlengeneratoren an? Der hat eine breitere Einfluss, der ist die Grundlage für das breitere kryptografische Ecosystem. Die Stärke der Härtung des Betriebssystems wird durch die Qualität des PRNG beeinflusst. Wenn man also Adressraumverzufallung macht, dann muss natürlich der Zufahrszahlengenerator gut sein. Sonst kann man es wieder erraten, dann hätte man es sparen können. Also nochmal zusammenfassend, wir haben QNX 6.6 erzählt und zwar gibt es das Defrandem. Das haben wir letztes Jahr erzählt. Also der Zufahrszahlengenerator war basiert auf Jaro und zwar auf einem frühen Design davon. Der hat nicht wirklich um die Initialisierung gekümmert und hat eine relativ niedrige Entropy und hat eine Zufahrszahlenquelle, die auch vom Systemintegrator, der das QNX einsetzt, abhängt, wie das gefüttert wird. Und in QNX 7, nachdem wir also diesen Artikel oder den Talk gehalten haben, ist alles viel besser geworden. QNX 7 nutzt neue Quellen für Entropy. Sie haben sich sehr sorgfältig um die Initialisierung gekümmert und die Qualität der Zahlen ist, der Algorithmus ist besser. Der Systemintegrator hat immer noch ein paar Sachen, die er beeinflusst, und das kann auch einen Einfluss auf die Zubahrzahlen haben, aber insgesamt ist es ganz gut. Lass uns anschauen, was sich hier geändert hat. Ihr müsst nicht alles sehen, nur die grünen Teile sind wirklich wichtig. Da hat sich was geändert. Um das Problem der Entropy während des Buttens in Ordnung zu bringen, gibt es ein File, in dem schonmal Entropy vorgespeichert ist. Während des Buttens wird dieses File genutzt. Und wenn es sich aufbraucht, dann kann es während der Laufzeit Erneuert vollgefüllt werden. Und daneben gibt es auch Benutzer eingereichte Quellen von Zufall. Die nehmen also GetUID und GetPID und GetTimeOfDay. Es ist alles vorhersehbar. Und das Einzige, das wirklich ganz gut ist, ist die RC4 Zufallfunktion, die eigentlich ganz gut ist. Aber im Kernel gibt es auch einen Zufallstahlengenerator. Und der ist neu in Cuny7. Und das ist eine Funktion, die heißt RandomValue. Zufallstahl. Und das wird genutzt für die Adressrahmen Verzufallung und um auf den Stack Sachen zu legen. Um zu erkennen, wenn der Stack manipuliert wird. Momentan kann er in Nanosekunden die Zeit nutzen. Und all diese Sachen kommen in einen zuerst zahlen Generator rein. Und der geht dann durch SHA-256 durch. Und dann wird das in acht Blöcke zerschnitten und der erste Block wird als ein Salt verwendet. Und die weiteren werden als Zufallswerte genutzt. Und jedes Mal, wenn man einen neuen Zufallstahlentwert braucht, dann gibt es eine neue Interaktion. So, und jedes Mal ändert sich diese 32-Spit. Das ist so, wie der Zufallstahlengenerator im Kernel funktioniert. Und jetzt schauen wir uns an. Lass uns in die Exploit-Medikation gucken. Das, was man in den Standardbetriebssystemen Windows, Unix usw. nutzt. Die sind nicht einfach so vermymelgefallen. Man gibt es eine lange Geschichte von Löcken, die man dafür genutzt hat. Und sowas gibt es halt nicht für QNX. Und das heißt, da gibt es vieles Interessantes zu sehen. Deshalb haben wir uns das angeguckt. Von QNX, Version 6.4. Da könnt ihr sehen, da gibt es diese Space Layout, Randomization und Stack Canaries. Und die kann man ausnutzen, wenn der Administrator, die nicht angeschaltet hat. Wir machen jetzt weiter mit Data Execution Data Ausführungsverhinderung. Es gibt zwei Möglichkeiten für den CPU. Das ist einmal die Harvard Design und einmal das Verneumert Design. Und um das die Ausführung zu verhindern, muss man die Harvard Design oder Verneumert Design machen. Und in diesem Fall hat man jetzt ein spezielles Bit, hier das NX Bit, das die Ausführung regelt. QNX DEP hat verschiedene Enforzen, Unterstützung für verschiedene Prozessoren. Das hat auf jeden Fall keine Unterstützung für dieses Untermips. Das Problem mit QNX DEP ist, dass die Standard-Einstellungen nicht sicher sind. Als z.B. selbst wenn der Hieb nicht ausführbar ist, bleibt der Stack weiter ausführbar. Der Standard-Knu-Header wird ignoriert bei diesem und man kann die Stack Ausführung verhindern mit einem bestimmten Zeichen darin. Aber mit diesen neuen Firmenware-Appel kann man das jetzt nicht mehr einführen. Und das Problem ist weiter in QNX 6.6 und 6.7 verfügbar, also danach müsst ihr dann gucken. Das Nächste ist die Adressenraum-Layout-Zufallausführung. Auf der rechten Seite könnt ihr so eine Standard-Ausführung des ASLR sehen. Das hier verhindert den Angriff, in dem es zufällig ewig läuft und so kann man das nicht auslesen. Es hat wieder einen speziellen Fleck, der nicht standardmäßig nicht gesetzt ist. Es ist nicht eine sehr feine Form, sondern viele Speicherabjekte sind zufällig. Ein Problem in der Praxis ist, dass die Toolchain nicht zufallsbasiert ist. Dadurch ist dieser Coach-Speicher nicht in den meisten, die man im Betrieb sieht, nicht randomisiert. Ich erspare euch jetzt die Details. Das wird meist ausgeführt durch Aufrufe von M-App im Micro-Körnel. Auf der linken Seite seht ihr die Stack-Randomize-Funktion. Die erste Funktion ist M-App-Find-VA. Das macht das, indem es den Zufallswert hinzufügt, der subtrahiert von der Adresse. Und dann schiebt es nach links und extrahiert den unteren 24-Bit. Das heißt, wir kriegen maximal 12-Bit Entropie zu einer beliebigen Adresse, egal wie gut die Zufallzahl vorher war. Das zweite Ergebnis von diesen Funktionen ist, die zweite Funktion ist M-App-Find-VA. Das macht das genauso. Den nimmt ihr unteren 32-Bit von einem Zufallzahngenerator, dann wird es um 4 nach links geschoben und holt dann die unteren 11 raus. Und das bedeutet, da gibt es maximal 7-Bits Entropie. Das wird dadurch ein bisschen abgefedert, dass es mit der vorherigen Funktion kombiniert wird, aber praktisch gesehen hat es einen großen Einfluss. Die oberen Grenzen sind sehr optimistisch, weil die einen schlechten Zufallzahngenerator haben. Die nutzen direkt Clock-Cycles, und das ist Architekturspezifisch. Auf der rechten Seite sieht man, wie die Clock-Cycles funktionieren. Das macht bei unterschiedlichen Systemen unterschiedlich. Das Erste, was man da so sich denkt, ist, wenn ich von einem Angreifer fernhalten will, wie der Speicher aussieht, dann muss ich da hier gute Zufallzahlen verwenden. Aber hier in diesem Kontext müsste eine Zufallzahn reinkommen, das tut sie nicht. Oder die Clock-Cycles müssen geheimer Wert sein, aber das ist ja nicht. Also man könnte vielleicht einen Reconstruction-Attack an Decking ansetzen, und das müsste funktionieren, aber das ist eigentlich Overkill. Es gibt einfache Möglichkeiten. Wir haben verschiedene Prozesse über Boot-Sessions gemessen. Dann haben wir das NIST-Entropy-Tool verwendet, um die minimale Entropy zu messen. Und wenn man da drin sucht in diesen 256-Bits, dann sollten 256-Bits Entropy rauskommen, das tun sie aber nicht. Und wir haben also jetzt hier gefunden, dass also im Durchschnitt 4,47 rauskommen, wo 256 kommen sollten. Das Niedrigste waren 3 für die Bibliotheken und das Höchste waren, keine Ahnung. Linux hat da sehr, sehr hohe Werte im Vergleich. Warum ist das jetzt ein Problem? Das ist ein Problem, weil ich einen Proofforce-Angriff darauf machen könnte. Wenn ich einen Netzwerkendemen habe, der eine Architektur einen Fog durchführt, da kommt ein Call rein und dann mache ich eine Kopie von dem kompletten Prozess und bearbeite das dann da drin. Und wenn diese Kopie gemacht wird nach ASLR, ist es eine genaue Kopie und das Layout ist genauso. Und jedes Mal, wenn ich eine Kopie mache, dann sieht es genauso aus wie es ist original. Damit kann ich also immer wieder den gleichen Request hinschicken und kann in einer sinnvollen Zeit ausprobieren, solange verschiedene Werte bis es crashed. Auf der linken Seite habe ich einen angreifbaren Dienst gefunden. Es ist ein Overflow und auf der rechten Seite probiert es über das Netz, in dem ich in 23 Sekunden genau diesen Fehler finde und woher im Speicher wohnt. Natürlich ist das interessant, aber Information Leaks, das heißt also, Dinge da drin zu finden, ist noch viel interessanter. Das ist wunderbar für lokale Schwächen und davon gibt es ganz viele in QNX. Der erste, den wir gefunden haben, ist der hier, der PROC LS. QNX, so viele QNX, hat einen Prozess-Filesystem und für jeden Prozess kann ich über das Device-Filesystem mit denen sprechen und kann mit denen interagieren. Was man hier sehen kann, unabhängig, wer man ist, kann jeder die lesen und das macht es sehr einfach, womit ich eine Anwendung, mit der ich über Berechtigungsgrenzen hinschauen kann, wo der andere Prozess wohnt. Das PIDN Utility bringt diese Funktionalität mit und macht das schon für mich und das kommt auf ganz vielen Systemen standardmäßig mit. Das zweite, wo ich Information Leaks habe, ist in dieser LD, die BAK-Umgebungsvariable. Wenn ich sage, ich will alles haben und dann kriegt man sehr viel die BAK-Information, wo die Adressen von den gemeinsamen genutzten Bibliotheken liegen und in Linux und GSD ist diese Option nur speziell berechtigten Benutzern vorbehalten. In QNX, da gibt es keinen Check, da kann jeder diese Information für das gesamte System haben. Und das macht die Ausbeutung dieser Prozesse viel einfacher. Nachdem wir das berichtet haben, ist QNX 7 sehr stark verbessert worden. Die nutzen ASLR, die nutzen einen neuen Zuverzahngenerator im Kernel und das ist gut. Aber es macht es nicht viel stärker. Trotz des neuen ASLR und obwohl sie 64-Bit Adressen nehmen, haben sie es vergessen, diese Bitmasken zu entfernen. Und damit bleibt die Entropie, die da übrig bleibt, die gleiche wie sie vorher war. Der Programmcode ist häufig in die unteren Bereiche des Speichers geladen. Jetzt haben sie den LD Debug gefixt, aber sie haben nicht vollkommen den ProcFS in Ordnung gebracht. Man kann also hier oben sehen, dass man das PIDN nicht mehr nutzen kann. Aber wenn man selber eine Anwendung schreibt, die mit dem ProcFS spricht, dann kann man immer noch diese Information rausholen. Die nächste Erhärtungsmaßnahme sind Stack Canaries. Das ist ein Schutz gegen traditionelle Stack Overflows. Ich nehme eine Zuverzzahl, die behalte ich zufällig und die stecke ich auf mein Stack zwischen den lokalen Variablen und meine Rücksprung Adresse. Und wenn jetzt der Angreifer es schafft, das die Adresse zu überschreiben, ist auch der Canary überschrieben und damit können wir es feststellen und einen Händler aufrufen, der eine Ausbeute verhindert. Also in Linux und BSD ist das auf der Compiler Seite und Qnix nutzt auch GCC, das heißt genau wie die beiden. Und die Betriebssysteme Seite ist spezialisiert. Im User Space macht er das über Lib C. Qnix nutzt eine Spezialfunktion, um die Cookies herzustellen und da hat es dann wieder seinen eigenen Zuverzzahngenerator und kombiniert das mit der Stackvariable und den Zyklen. Das hängt davon ab, wie geheim die Clock Cycles sind und das sind sie nicht. Und das Qnix 6 SSP hat einen schwachen Zuverzzahngenerator, und zwar hier dieses 7,29 Bit, das ist ganz schlecht. Die hätten mindestens 24 Bit haben müssen, weil es einen 0 Bit gibt und wenn sie einen vollen Canary genommen hätten, hätten sie 32 Bit haben können. Und das ist ein Problem, weil man das einfach Brute Forst kann, alle Möglichkeiten durchprobieren kann. Aber in der Praxis ist das eben noch weiter schlimmer, weil der Micro-Colonel nicht geladen oder nicht gegen Lib C gelingt ist. Das Micro-Colonel ist geschützt, aber die werden nie initialisiert und damit sind sie immer 0 und damit hätte ich es auch weglassen können. Wir haben diese Probleme an Blackberry gemeldet. Die haben jetzt die Stack Canaries standardmäßig eingeschaltet. Sie haben ein 64 Bit Betriebssystem und für Userspace haben sie Sie holen sich die Zufasszahl aus dem Kernel und stecken in Userspace, um dort dann die Initialisierung durchzuführen. Also die Stack Canaries sind jetzt in allen Bereichen vollkommen in Ordnung. Und jetzt kommt die letzte Maßnahme, die wir besprechen, um das zu ernten. Auf der linken Seite sieht man, wie das funktioniert. Man hat eine Funktion, die ist in der gemeinsamen Bibliothek. Sie wird nachgeschaut, die Adresse wird speichert. Und diese Daten, wo das Zeug wohnt, ist offensichtlich ein gutes Ziel zum Angriff. Wenn der Control Flows da vorbeikommt und ich habe das geschafft, das zu beeinflussen, dann geht es da ein, wo ich hin will. Der Schutz geht, indem diese Tabellen in der Reihenfolge geändert werden und Read Only gemacht werden, so dass niemand diese Einträge überschreiben kann. Jetzt haben wir ein Problem und das Problem kommt von Lazy Binding. Das heißt, Symbole werden nicht während des Ladens nachgeschaut, sondern sie werden erst beim ersten Aufruf nachgeschaut. Und da muss ich halt schauen, dass das nicht passiert. Also die machen Lazy Binding, schalten sie aus und dann machen sie das am Anfang beim Laden. In Qnix 6 haben sie das versucht und das ist auch sehr schön, aber leider funktioniert es nicht richtig. Auf der linken Seite sieht man, wie es aussehen könnte und sollte. Und die sind Read Only. Auf der rechten Seite ist die Qnix Implementierung des gleichen Dings. Und man sieht, dass nur einige von diesen Dingen umsortiert sind und dass das nicht in der richtigen Reihenfolge ist und damit ist es nicht geschützt. Die haben in die Linker-Sections nicht ordentlich sortiert, bevor sie es gemacht haben und das ist das eigentliche Problem. Auf der rechten Seite kann man in diese Tabelle reinschreiben und ein Stack Vault herbeifüllen. Wir haben auch die Möglichkeit gefunden, das auszuschalten. Das heißt also, man kann von außen diese Härtung ohne jegliche Privilegierung auszuschalten. Und wenn ich ein Binary habe, was ZUID ist, dann kann ich das damit ganz wunderbar angreifen. Das wurde verbessert zwischen Qnix 6 und Qnix 7. Wir haben das alles, was wir heute diskutiert haben, auch an Blackberry kommuniziert. Es sind noch einige von diesen Themenproblemen, noch in 6,6. Und noch eine Warnung an Angreifern, Verteidiger. Viele von diesen Patches brauchen eine lange Zeit, um diese Geräte zu erreichen. Insbesondere in ein embedded system eingebauten System. So kann es sein, dass diese Probleme noch für eine lange Zeit bestehen. Zusammenfassend. Die Toolchain-Zeit ist meistens in Ordnung. Das ist auch nicht so sehr ein Qnix-Problem, sondern ein embedded Problem. Es kann nicht einfach von 1 zu 1 übertragen werden. So gibt es viele architektonische Unterschiede. Und so gibt es halt hausgemachte Sachen, die halt nicht so gut sind wie der Standard. Und was man ja auch merkt, ist, dass keine Aufmerksamkeit von Sicherheitsforschern auf das hier gebracht worden ist. Und noch eine weitere Warnung wieder. Der Zufallsgenerator ist ein embedded System, das ist auch wie vor ein Problem. Und noch eine gute Notiz zum Schluss, dass Qnix versucht, immer noch ein allgemeines Betriebssystem zu sein. Und die haben eine sehr große Anbieterreaktionszeit. Und am Ende würde ich einfach mehr Aufmerksamkeit zu embedded systems Betriebssystemen rufen. Weil das halt in Kars- und kritische Struktur- und Militärsystemen eingebaut wird. Und in der Zukunft könnt ihr noch mehr von uns erwarten in Brüssel oder auf der nächsten Black Cat. Und wir freuen uns jetzt auf Fragen. Vielen Dank. Vielen Dank an Appasi und Ali. Jetzt haben wir noch ein bisschen Zeit für Fragen. Stellt euch hinter die Mikrofone. Als derjenige, der die erste Kernel-Exploitation auf Qnix gemacht hat, fühlte ich mich ausgelassen. Was ist dein Name? Nick ist der Name. Noch andere Fragen? Mit dem Problem, wo der Stack-Cannery für den Kernel nicht richtig eingeschaltet war, war das ein Problem, dass das überhaupt nicht gemacht wurde, oder dass es geplant war, aber was schief gegangen ist? Es wurde niemals initialisiert in der Mikro-Körnel. Und der Mikro-Körnel ist im BNS platziert und das ist sehr früh gebutet. Die haben es benutzt, aber es ist niemals initialisiert. Vielen Dank für einen fantastischen Talk. Damit verabschieden sich aus der Übersetzer-Kabine Oliver und