ehemaliger Diplomant von mir ist. Und heute Professor,
zum Vortrag hierher gekommen ist. Konrad hat damals
seine Diplomarbeit über maschinelles Lernen im Bereich Introtion Detection geschrieben.
Und ich muss das einfach auch nochmal an dieser Stelle sagen.
Diese Diplomarbeit, die er geschrieben hat, war die erste Diplomarbeit,
die ich betreut habe, bei der jeder Satz eine Bedeutung hatte.
Das heißt, da gab es keine Sätze,
die die Bedeutung des Internet nimmt, ständig zu.
Also solche Sätze, die, sage ich immer,
meinst du dies, wie können wir uns alle sparen?
Also das weiß ja nie jeder
Und von daher, das war so eine Arbeit,
die wirklich sozusagen eine sehr herausgehobene Bedeutung hatte für mich,
weil sie auf der Meta-Ebene eine der besten war,
die ich jemals lesen durfte.
Sie sehen ja, was draus geworden ist,
wollte das Konrad hier oder muss einen Vortrag halten.
Es ist ja immer so, wenn er einlädt,
dann kann man auch nicht Nein sagen.
Das geht mir ja auch ständig so. Und wie das
halt so ist, manche Dinge brauchen ein bisschen länger.
Er war nämlich eigentlich schon mal eingeladen und musste damals leider
absagen aus gesundheitlichen Gründen.
Und dieser Fit. Und heute hält der Vortrag,
den er damals schon geplant hatte,
Graf Meining
zur Schwachstellensuche
Er ist jetzt, anders als es ursprünglich mal angekündigt war,
Mitglied der TU Braunschweig, denn da ist er erst seit drei Monaten.
Und von hinten nach vorne,
vor der Uni Braunschweig war B2 Professor an der Uni Göttingen.
In Braunschweig hat er jetzt sozusagen den Lehrstuhl mit W3. Und
davor war er zwei Jahre in der TU Berlin und beim Fraunhofer Först in Berlin.
Wir haben uns kennengelernt, auch in Berlin.
Ich war nämlich zu dem Zeitpunkt, als er Student war,
an der FU Berlin.
Und somit hat er sein Studium auch in Berlin gespielt,
damals an der Freiheit
Absolviert. Die Jahreszahlen bringe ich jetzt alle im Einzelnen nicht mehr zusammen,
aber es muss irgendwie nach der Jahrtausendwende gewesen sein,
denn ich war vor 2000 bis 2003 an der FU Berlin.
Er war dann fertig und dann ist er
zu Fraunhofer gegangen und in seinem Julian müsste jetzt Professor.
Seit fünf. Seit fünf Jahren, ihr seid Professor.
Also ein gutes Beispiel, dass man, wenn man viel
arbeitet und gute Ideen hat, auch super Ergebnisse erzielen kann.
Und ich denke, dass du über deinen Doktoranden selbst noch was erzählen bist.
Denn er ist sozusagen mitprämierter Denn sein Dr. Abend hat plötzlich einen Preis gewonnen.
Und die Dr. Väter und Mütter sind auch immer sehr stolz darauf,
wenn die Doktoranden solche tollen Auszeichnungen bekommen.
Stimmt's? Wahnsinnig stolz. Und in diesem Sinne,
schöne Tiefe verknüpfen bei dem Vortrag.
Ja, also vielen Dank für die Einladung.
Mit der Diplomarbeit konnte ich mich jetzt gar nicht so genau daran erinnern,
dass da jeder Satz so sitzt, aber gut,
das soll gar nicht das Thema sein.
Wir wollen heute über Schwachstellensuche sprechen. Also die Frage ist,
wie kann ich in Software Fehler finden,
die was mit Sicherheit zu tun haben
Annes hat netterweise schon viel über mich gesagt. Ich habe,
eigentlich ist es auf der Folie fast alles drauf.
Deshalb erkläre ich schnell die Fotos. Also in Braunschweig gibt es zwei tolle Gebäude,
das Altgebäude, und daneben so ein paar Villionen.
Und wer mal vorbeikommt und an diesen etwas nicht so schönen
Häusern vorbeischaut, der sieht dann die Uni.
Und hier habe ich immer so ein Foto,
dass da auch eine ganze Menge Studenten sind.
Ich glaube, das war sowas wie Nacht des Wissens oder so.
Da kommen natürlich immer alle Leute und gucken sich alles an.
Und dann natürlich, wenn dann die Vorlesung hier ist,
sitzen dann dann nur so vier, fünf Leute.
So, worum soll es gehen? Es soll um IT-Sicherheit gehen.
Dazu muss ich vielleicht ein bisschen erstmal was über IT-Sicherheit erzählen.
Und wie meine Forschung eigentlich mit IT-Sicherheit in Zusammenhang steht
Also, wenn man sich mit IT-Sicherheit beschäftigt,
dann weiß man als allererstes, es gibt so einen Kreislauf.
Das heißt, das ist nicht so, dass man etwas baut.
Es ist 100 Prozent sicher und dann ist man fertig.
Sondern es ist vielmehr so, man baut es und man macht dann Prävention.
Das heißt, man versucht, Fehler zu verhindern, Sicherheitsprobleme.
Und dann muss man aber auch dafür Sorge tragen,
dass wenn man irgendwo einen Fehler gemacht hat in seinem System,
dass man das ebenfalls feststellt.
Das ist die zweite Phase in diesem Kreislauf, die Erkennung.
Und wenn man etwas erkannt hat,
dann möchte man natürlich verstehen, was ist schiefgegangen,
das führt zur Analyse und da schließt sich so ein bisschen der Kreis.
Und so dreht sich dieser Kreis seit vielen Jahren in der Forschung,
aber auch in der Industrie hin und her.
Und eigentlich wäre alles schön, wenn nicht seit, ich sag mal,
zehn Jahren oder so dieser Kreis aus seiner Wucht gelaufen ist.
Ich habe das hier durch diesen Angreifer dargestellt.
Es gibt seit, ich würde sagen, 2000,
2002, 2003 immer mehr Shartcode, immer mehr Angriffe.
Das hängt mit vielen Dingen zusammen, vielleicht auch mit dem Wachstum des Internets,
mit der Verschmelzung von IT-Technik und unserem Leben, all diesen Faktoren.
Aber es hat sich gezeigt, dass dieses Prinzip,
ich analysiere, ich verhindere,
ich erkenne,
nicht mehr
richtig funktioniert
Ein Teil dazu tragen auch bei all die Angreifer,
die inzwischen keine Skript-Kiddies mehr sind,
sondern professionelle Hacker darf man nicht sagen, aber professionelle Kriminelle,
also Leute, die ihr Geld mit Straftaten verdienen und diese
Leute führen diese Taten auch auf einem sehr professionellen Level aus.
Also ich habe das Gefühl, der eine oder andere hat
auch Informatik studiert, der diese Angriffe macht.
Und bisher war das so, dass dieser Kreislauf eigentlich immer
von einem Menschen kontrolliert wurde. Also es gab jemanden,
der hat das sich überlegt, wie kann ich Angriffe verhindern,
wie kann ich Angriffe erkennen und wie kann ich sie verstehen.
Und je mehr Angriffe und Chartcode ich jetzt habe,
desto mehr Zeit muss investiert werden. Und das ist für diese
eine Person oder vielleicht sind es auch zwei oder zehn oder zwanzig,
aufwendig. Und es ist natürlich auch teuer,
denn immer wenn Menschen arbeiten, kostet es besonders viel Geld.
Das ist so ein bisschen der Fokus von meiner Forschung,
wenn man jetzt gemein wäre, könnte man sagen,
ich will Arbeitskräfte in der Sicherheitsindustrie reduzieren,
aber das stimmt natürlich gar nicht.
Ich will Arbeitskräfte in der Sicherheitsforschung schaffen und vielleicht Arbeitskräfte in
dieser langweiligen Analyse reduzieren. Und da ist die Idee,
wenn die Angriffe schon automatisiert sind,
kann ich nicht auch die IT-Sicherheit zu einem gewissen Grad automatisieren
Dass Sicherheitssysteme manchmal auch eine Entscheidung selber fällen. Nicht immer komplett automatisch,
aber dass sie zu einem gewissen Grad, gerade dann,
wenn es sehr langweilig wird, Dinge automatisch tun.
Und da setzen wir schon seit einer ganzen Zeit Algorithmen des maschinellen Lernens ein.
Also das, was man so als künstliche Intelligenz manchmal versteht.
Also Techniken, die dazu geeignet sind, Daten,
die man hat, zu analysieren, zu schauen,
was ist gut, was ist böse.
Und dann selbstständig eine Entscheidung fällen können. Und wir machen das
schon ziemlich lange und wir haben im Prinzip für alle diese
drei verschiedenen Stufen der Sicherheit inzwischen solche Ideen entwickeln können.
Also Systeme, die zum Beispiel fehlende Sicherheitschecks in Software
erfinden oder Systeme, die schädliche Webseiten versuchen zu erkennen.
Oder die versuchen schädlichen Android-Code auf dem Handy zu suchen.
Oder, das ist dann der Bereich Analyse,
die schauen, wie kann ich einen getarnten Code enttarnen?
Wie kann ich ihn zum Beispiel deopfuskieren,
wenn ich darüber weiß, wie etwas opfuskiert ist?
Ich würde Ihnen das gern alles sehr erzählen,
aber das würde sehr, sehr lange dauern.
Und deswegen sprechen wir nur über einen kleinen Bereich,
nämlich das Thema Modellierung von Schwachstellen mit Grafen
Das hat Hannes ja schon gesagt. Der Grund,
warum ich darüber so gerne spreche, ist,
dass das eine Technik ist, die unheimlich erfolgreich ist.
Aber ich habe die natürlich nicht erfunden, sondern einer meiner Doktoranden.
Es ist Fabian Jamaguchi. Ich habe hier, ich wollte nicht
so viel angeben, einfach nur dieses Logo von diesem Preis hingemacht.
Das ist aber eigentlich ein toller Preis,
den der Cast e.V. und die Gesellschaft für Informatik einmal
im Jahr für die beste Doktorarbeit im Bereich IT-Sicherheit vergeben.
Und den hat er nun just vor zwei Monaten gewonnen,
fast genau zu diesem Thema.
Er hat ein paar mehr Papiere gemacht,
aber das ist, glaube ich,
das erste,
wo es
so richtig toll funktioniert hat
Ich finde aber, man muss hier auch sagen,
in dieser Liste sind auch noch andere Namen,
also meinen mal rausgelassen, aber hier zum Beispiel Nico und Daniel,
das heißt so ein richtig gutes Papier,
das schreibt nicht immer nur ein Doktorand alleine,
sondern da gibt es natürlich die,
die vielleicht gerade erst angefangen haben oder im Fall von Daniel Arp,
will ihn jetzt nicht so herausstellen,
aber der vielleicht doch ein ganz anderes Thema hat,
aber der gesagt hat, das hat mich auch interessiert,
ich helfe dir einfach dabei,
ja.
Und deswegen möchte ich hier auch alle nennen und euch vielleicht auch hier im Raum
immer mal ermutigen. Man kann auch bei demjenigen mitforschen,
der nicht genau das gleiche Thema vertritt,
wenn man Lust und Ressourcen hat, meistens bringt man Dinge ein,
die einfach gut sind, man nämlich ein bisschen aus dem,
aus dem eigentlichen Loch herausschaut,
in dem der Experte schon drin ist.
So, jetzt wollen wir uns das anschauen.
Und dazu müssen wir natürlich erstmal uns überlegen,
ist es überhaupt sinnvoll, Schwachstellen zu finden?
Ist das ein Thema, wo man eine Forschungsarbeit drüber schreiben sollte?
Ich habe mal einen Vortrag gehalten vor einigen Jahren.
Da hat einer, ein Professor saß in der ersten Reihe
und der sagte, das ist alles totaler Quatsch.
Wenn man richtig testen würde, dann gäbe es gar keine Sicherheitsschwachstellen.
Und ich glaube, in der Theorie ist das richtig
Aber leider, das Internet und diese ganzen Software,
die wir verwenden, sind keine Theorie, sondern Realität.
Und wenn man sich jetzt hier anschaut,
das sind mal vier so eine ganz bekannten Schwachstellen.
Ich weiß nicht, kann sich hier jemand an Go-to-Fail erinnern?
Bitte die Arme heben, eine schwere Fehler in Apples, SSL-Implementierung.
Im Endeffekt konnte man alle Apple-Geräte eine Zeit lang abhören.
Nicht so schön. Hardbleed war sogar in der Tagesschau,
da frage ich gar nicht nach.
Shellschock hat davon jemand gehört. Auch ein toller Bug in
der Unix Shell Bash, ein kleiner Fehler.
Man konnte über so eine Umgebungsvariable Code einschleusen.
Was das Tolle bei dem Fehler ist,
der hat fast 30 Jahre lang in dieser Implementierung gelegen und
niemand hat ihn gefunden
Also, der ist älter als Fabian, der das sich damit dann beschäftigt hat.
Und das ist ein Fehler, der so alt ist.
Nicht die Software. Und da finde ich es natürlich,
wenn man sagt, ja,
man hätte nur besser testen müssen,
also wenn man 30 Jahre zum Testen Zeit hat, ja,
und die Bash ist ja wahrscheinlich hier in Hamburg auf tausenden oder Millionen von Computern installiert.
Ich weiß nicht, ob sie auf meinem iPhone drauf ist,
aber auf Android ist sie bestimmt auch.
Und dann passiert so ein Fehler, den man nicht gesehen hat,
dann ist das mit dem Testen schwierig.
Das ist ein bisschen neuer, Stage Ride,
hat davon jemand gehört
Auch unangenehm. Damit kann man im Prinzip durch eine präparierte MMS-Nachricht
Code in alle ungepatchten Android-Telefone einschleusen. Also mit anderen Worten,
es gibt eine ganze Reihe von solchen Fehlern, die kommen immer wieder vor.
Und die Frage ist, wie findet man sie? So,
und jetzt gibt es so ein paar leichte Fehler,
die sind eigentlich relativ problemlos zu finden. Also jeder,
der mal ein bisschen zäh programmiert hat, der weiß,
wenn der String Cat oder Sprint F benutzt,
dass das dann mit den Pointern und der Null da immer so ein bisschen tricky ist,
und dann muss man da immer L-Log machen,
dass man genug Speicher hat,
oder man muss auf dem Buffer was haben.
Und schnell ist da was kaputt. Also die Dinger
benutzt man nicht und dann sind schon viele Fehler weg
Was jetzt aber übrig bleibt, sind eben genau die Fehler,
die man nicht so einfach finden kann.
Und da gibt es natürlich in der Forschung eine ganze Reihe Ideen.
Ich habe schon gesagt, testen, wenn man das aus
der Sicherheitswelt sieht, dann würde man sagen, fuzzing.
Das ist also das Bombardieren von Software mit zufälligen oder mehr
oder weniger zufälligen Inputs, solange bis es irgendwann abstürzt.
Oder sowas wie Taint-Analyse oder symbolische Ausführung,
also richtig mächtige Tools aus dem Software-Engineering.
Die theoretisch alle Fehler finden können. Wenn man jetzt in
die Praxis schaut, wer findet denn
diese Fehler
Da muss man bei all den vier Fehlern und bei vielen anderen
auch sagen, die sind alle von Menschen gefunden worden.
Menschen, die sich den ganzen Tag lang den Zoos-Code oder
auch teilweise den Binär-Code angeschaut haben und per Hand und per
Kopf gesucht haben, wo es da was kaputt.
Und wenn man ganz genau sein möchte,
dann kann man noch den Satz von Reis zitieren,
der ja besagt, wenn man ein Programm hat,
dann kann man ein, ist es Unentscheifer,
ob da eine nicht triviale Eigenschaft erfüllt ist.
Und eine Schwachstelle ist natürlich eine nicht triviale Eigenschaft.
Das bedeutet, es wird nie ein Softwareprogramm geben,
was alle Schwachstellen finden kann
Es gibt ein Software-Programm, was einen Teil findet.
Es gibt vielleicht ein Software-Programm, was mit ein bisschen Interaktion-Schwachstellen findet,
aber so eine komplett automatische Lösung wird es nie gehen.
Und wenn man sich das jetzt bildlich vorstellen will,
dann ist das so ein bisschen wie bei Trüffeln.
Also hier oben habe ich die Schwachstellen quasi in der Wiese.
Das ist die Software, da liegen die drin.
Und das sind hier diese supercoolen Hacker mit ihren,
also ich weiß nicht, ob die hier jemand kennt,
aber das sind also die Leute mit diesen Twitter-Accounts,
mit 100.000 oder 200.000 Followern,
die also diese ganzen schwierigen Bugs finden
Und wir haben jetzt gedacht, wie kriegen wir denn unsere Forschung in dieses Feld rein?
Und da haben wir gesagt, wir versuchen, dass die bessere Nasen kriegen.
Das heißt, wir wollen nicht die ersetzen,
wir wollen auch nicht irgendwie nur so einfache Bugs finden,
sondern wir wollen Werkzeuge bauen, mit denen Experten Schwachstellen besser finden.
Führt auch dazu,
dass wir oft Anfragen von Leuten kriegen, die sagen,
ja, ich möchte jetzt auch Schwachstellen suchen und dann sagen müssen,
die erste Bedingung ist natürlich, dass du Experte bist.
Und dann kannst du die Werkzeuge verwenden.
Oder ein Schwein, wie in dem Fall jetzt hier
So, und diese Idee, die hat eigentlich Fabian in seiner Doktorarbeit,
das ist quasi so das größere Thema,
dass er sagt, Schwachstellen suchen muss etwas Assistiertes sein.
Und zwar assistiert durch ein Computersystem. Das heißt,
der Experte ist nicht mehr alleine, sondern er hat quasi einen Computer,
der ihn mit automatischen Tipps und Vorschlägen berät und sagt,
schau doch mal hier, schau doch mal hier,
Lockprint F so und so, das ist eine Funktion,
die sieht schon verdammt unsicher aus.
Und die Intelligenz,
ich habe es hier noch in Anführungsstrichen geschrieben,
die soll halt durch Methoden des maschinellen Lernens und in
dem Fall durch Graph Mining entstehen
Da gibt es eine ganze Reihe von Schwierigkeiten,
die werden wir heute alle noch kennenlernen.
Das fängt damit an, dass Programmcode natürlich etwas sehr kompliziertes ist.
Und es ist auch etwas sehr Diverses. In einem anderen Projekt,
davon habe ich nicht eine einzige Folie zu,
ich will es nur mal erzählen, da haben,
also es gibt so einen Google-Wettbewerb, wo man quasi etwas implementieren muss.
Und wenn es richtig funktioniert, dann kriegt man quasi die Punkte.
Und in diesem Wettbewerb haben 200 Leute teilgenommen.
Und wenn man sich jetzt die 200 Lösungen anschaut,
die alle das Problem richtig lösen, stellt man fest,
dass der Code von diesen 200 Leuten unterschiedlich ist.
Und zwar nicht nur ein bisschen, sondern gravierend,
sogar so sehe, dass man die 200 Leute an
ihrer Lösung unterscheiden kann
Das wäre jetzt noch ein anderer Vortrag. Aber was ich
damit sagen will, ist, Programmieren ist auch was unheimlich Individuelles.
Und es ist nicht so, dass man einfach sagt,
ja, wenn einer einen Browser schreibt,
dann sieht der Browser genauso aus, wie wenn jemand anders einen Browser schreibt.
Und ein Browser ist jetzt schon das krasseste Beispiel, was mir einfällt.
Das heißt, wir brauchen richtige Tools und wir müssen auch richtig verstehen,
was macht eigentlich der Experte, wenn er Schwachstellen sucht.
Und deswegen habe ich hier eine Schwachstelle mitgebracht.
Und wir kommen nicht drum rum, dass ich jetzt mal zeige,
was da eigentlich die Schwachstelle ist, damit klar wird,
was suchen wir eigentlich?
Also das ist eine Schwachstelle, die Stefan Esser 2013 in
Lipp SSH2 gefunden hat.
Wer kennt Stefan Esser
Stefan Esser ist einer von diesen, mit 200.000 Followern,
der auch täglich sein Essen postet und so.
Also einer dieser modernen Hacker, der also tatsächlich auch wirklich schwerwiegende Fehler findet.
Und der Fehler passiert hier in dieser roten Zeile,
aber wir schauen mal ein bisschen genau, was da passiert.
Es fängt an in dieser Zeile,
hier ist eine Funktion, die heißt Lip SSH 2,
NT-O-H-U-32. Wer mal ein bisschen zehn Netzwerk programmiert hat,
der weiß NT-O-H, bedeutet ein Network to Host Order.
Da geht es um Indianus. Weiß der eine oder andere
, was ich meine
Ist es im ersten Semester oder zweiten,
wenn man über Intager-Zahlen redet, wie die also kodiert sind.
Und hier wird also eine 32-Bit-Unsight-Intager-Zahl generiert und da steht ja auch U-In 32T.
Also es ist alles richtig, was man hier wissen muss,
ist dieses Data, das ist das, was der Angreifer dem Programm gibt.
Das heißt, der Angreifer kontrolliert, wie groß die Zahl ist, die hier steht.
So, das wäre jetzt an sich erstmal kein Sicherheitsproblem,
wenn nicht hier der Programmierer gesagt hat, naja,
bei so Namen in C,
da ist ja oft noch so eine Null,
da mache ich lieber plus eins.
Das heißt, ich allokiere ein Byte mehr,
als ich eigentlich brauche,
aus Sicherheitsgründen
Und das ist genau die Unsicherheit. Der Angreifer kann nämlich jetzt
so schlau sein und diese Zahl hier so groß machen,
dass sie quasi maximal groß ist. Das heißt,
alle Bits sind dann da auf eins in dieser 32 Bezahl.
Die ist dann zwei Milliarden, vier Milliarden, ne?
Vier Milliarden, noch was groß. Und wenn man dann
plus eins rechnet, dann wird daraus leider eine Null.
Da gibt es ein Inager-Overflow. Und das heißt, an
dieser Stelle wird null Speicher allokiert. Und wenn der Angreifer dann,
wenn das Programm dann diesen Mem-Corpy-Befehl hier ausführt,
Und hier wieder die Originalversion benutzt, ohne dass plus eins,
schreibt er also eine riesige Datenmenge an eine Speicheradresse, an der gar kein Speicher allokiert wurde.
Ganz klassischer Heep-Overflow. Ja, super gefährlich,
weil er in einer SSH-Implementierung ist und er ermöglicht es quasi,
dass man von außen auf einen SSH-Server geht und dann da Code ausführt.
Jetzt haben wir uns gefragt, okay, das ist ein toller Bug.
Wie hat er den gefunden? Hat er den mit
zum Beispiel mit sowas wie Blackbox oder Whitebox-Fuzzing gefunden?
Nein, Tate-Analyse oder symbolische Ausführung
Auch beliebt in der Softwaretechnik, formale Modellierung und Verifikation.
Auch nicht. Tatsächlich hat er diesen Bug mit einem regulären Ausdruck gefunden für Grab.
Wer kennt alles Grab? Okay, alle, super. Also Grab,
klassisches Tool, 30 Jahre alt oder noch älter,
vielleicht sogar, unterstützt, reguläre Ausdrücke.
Man kann damit suchen. Und das ist quasi den Ausdruck,
den Stefan Esser formuliert hat. Wenn man da reinschaut,
sieht man, dass dieser Ausdruck nicht nur so zufällige Zeichen sind,
sondern hier hat er tatsächlich das, was wir gerade gesehen haben, kodiert.
Also er sagt, es gibt eine Funktion,
die heißt irgendwie Alok
Da kann irgendwas dranhängen, was ihn nicht interessiert.
Hier hängt sogar noch mehr dran und in dieser Funktion Alok,
dann geht eine Klammer auf, dann kommt irgendwas,
kommt noch irgendwas und dann soll da aber ein Mal plus oder Minus sein und dann kommt wieder irgendwas.
Also mit anderen Worten, er sucht nach Aufrufen von Alok,
in denen innen gerechnet wird, weil er weiß,
dass sowas leider häufig passiert,
dass man da drin rechnet und das ist super gefährlich,
weil man sollte nicht an dieser Stelle rechnen,
sondern eher hier schon die Zahl berechnen und dann immer die gleiche benutzen.
So, hups
So, und dann haben wir uns gefragt, okay,
wenn der das so baut und können wir nicht das,
was das Grab-Konzept einfach ein bisschen schlauer machen und wir bauen jetzt ein richtiges Grab,
was wirklich dafür gedacht ist, Schwachstellen in Software zu finden.
Und das war quasi die gesamte Idee, aus der sich
die Doktorarbeit ergeben hat, dass man so eine Art Plattform baut.
Es gibt den Experten, der Experte stellt eine Anfrage,
hier ist eine ganz schicke Datenbank, Graf-Datenbank,
werden wir gleich noch sehen.
Und dann kommt der Code da rein,
wird ein bisschen vorbereitet und dann kann der Experte in dieser Datenbank einfach Abfragen stellen.
Nach dem Motto, gibt es das, gibt es das?
Und dann guckt er sich das an und dann kann er sagen,
okay, das ist hier eine Sicherheitsschwachstelle,
das ist keine Sicherheitsschwachstelle
So, das war unser Traum. Und dann haben wir festgestellt,
dazu müssen wir ein bisschen leider uns auch mit Compilern und Sprachen beschäftigen.
Eigentlich wollten wir das gar nicht. Und wenn man sich
mit Compilern und Sprachen beschäftigt, muss man dieses Buch lesen.
Wer hat dieses Buch hier gelesen? Wer hat das Buch
schon mal gesehen? Ja, okay. Ich habe es
auch, glaube ich, nicht komplett gelesen.
Es ist ja zweibändig, wenn man die deutsche Version hat.
Ist das Standardbuch, wie man einen Compiler baut?
Und im Prinzip Compiler bauen heißt ja eigentlich nur,
dass man eine Programmiersprache automatisch analysiert und so weit arbeitet,
dass man die Semantik rausholen kann.
Nämlich dann, was der Compiler in seinen Vinärcode dann ausspuckt.
Aus diesem Buch haben wir uns drei Konzepte geklaut. Wir haben uns das,
was man als Parsing normalerweise bezeichnet, die sogenannte syntaktische Analyse,
auch Syntax-Analyse genannt, weil sie uns hilft zu schauen,
wie sieht das Programm eigentlich aus?
Also ganz einfach gesagt, was ist das da?
So optisch. Hat das viele Vorschleifen? Hat das keine Vorschleifen
? Ist das irgendwie mit vielen Vayablen und so weiter?
Dann schauen wir uns natürlich auch den Kontrollfluss an,
weil er uns verrät, wie wird das Programm ausgeführt?
Gibt es da gewisse Verzweigungen? Gibt es Schleifen
Wie sind die Bedingungen an diesen Schleifen und den Verzweigungen und so weiter?
Und das Letzte, was wir angeguckt haben, ist die Datenflussanalyse.
Das ist also die Frage, wenn ich ein Programm habe,
wie fließen die Daten da hin und her?
Also wenn ich zum Beispiel diese Vayable hier in dem Beispiel,
ich gehe mal schnell zurück, weil ich diese Vayable hier habe,
dann möchte ich ja gerne wissen,
dass jetzt vielleicht dieses Data vom Angreifer kommt.
Das ist eine super wichtige Information. Oder ich möchte wissen,
dass zum Beispiel dieses Name Lang, mit dem hier in Verbindung steht.
Und das ist die sogenannte Dataflow-Analyse, bei der man also
die Verbindung zwischen den Einzelnen, Elementen in einem Programm herstellt.
So, wir haben das Buch gelesen. Ich ja nicht.
Ich habe ja den Doktorand, der hat es gelesen.
Aber ich habe es auch mal, als ich studiert habe,
habe ich es auch mal gelesen.
Also von daher, ganz so schlimm war es nicht.
Und dann haben wir geguckt, wie beschreibt man das am besten?
Und tatsächlich, es gibt für diese drei Sachen eine ganz klare
40 Jahre alte oder 50 Jahre alte Beschreibung aus dem Bereich der Softwaretechnik.
Und die will ich kurz vorstellen, weil wir die gleich brauchen werden.
Wenn man sinntags beschreiben will, dann macht man das normalerweise
mit einem sogenannten abstrakten Sinntagsbaum.
Das ist so was ähnliches wie ein Passbaum
Die Details sind jetzt hier vielleicht nicht so wichtig.
Dieser Baum hier beschreibt im Prinzip dieses kleine Programm hier.
Und zwar, wenn wir jetzt mal irgendwie eine Zeile rauspicken,
sagen wir mal hier, Y ist gleich zweimal X,
dann finden wir das hier in diesem Baum wieder.
Und zwar, hier, man kann das mal jetzt nicht erkennen,
aber hier steht quasi, es gibt eine Deklaration in und
diese Deklaration besteht aus Y ist gleich zweimal X.
Und so findet man im Prinzip alles,
was hier sind, taktisch kodiert ist in diesem Baum wieder
Klar, ne? Ist nicht so kompliziert. Also,
zack, nächstes Beispiel. Kontrollfluss. Gibt es auch eine
ganz bekannte, uralte Darstellung, der sogenannte Kontrollflussgraf.
Hier sind die einzelnen Knoten eher so Statements. Also es
ist ein bisschen höher, aber man kann dann sehen,
was von was quasi im Kontrollfluss abhängt.
In dem Beispiel ist das super simpel.
Es gibt ja nur ein If. Also wenn X kleiner
gleich Max ist, dann wird das ausgeführt.
Und das steht hier genauso drin nach dieser Anweisung,
wenn die wahr ist, dann passiert das,
wenn die falsch ist, passiert das.
Auch klar. Jetzt gehen wir noch
einen Schritt weiter
Jetzt sagen wir, okay, wir können jetzt den Kontrollfluss analysieren.
Wir können dann noch den Sintaxbaum oben drüber gießen.
Und daraus erhält man dann, was man im Englischen,
ein Program Dependence Graph nennt oder manchmal auch System Dependence Graph.
Das ist ein Graph, der den Datenfluss darstellt. So,
den muss ich vielleicht mal ein bisschen genauer erklären,
weil man den normalerweise nicht so sieht,
wenn man sich damit nicht beschäftigt.
Hier sehen wir auch die Statements, die in diesem Programm auftauchen.
Also wir sehen das IF. Wir sehen das Sink,
wir sehen das Int und wir sehen den Source,
also im Prinzip die vier Statements,
die hier stehen,
sind hier
vier Knoten
Und jetzt sehen Bekannten und an den Kanten steht immer ein D,
dass es dann heißt Data Dependence oder ein C,
das heißt Control Dependence. So, und das heißt also,
es gibt eine Data Dependence für die Variable X zwischen diesem und
dem Statement und wenn man reinguckt, ist auch klar,
hier wird X quasi definiert.
Hier wird X benutzt oder hier wird Y definiert.
Hier wird Y benutzt. Diese Funktion, hier gibt es
eine Control-Abhängigkeit, wenn das wahr ist, dann passiert das.
Ja, und wenn das war, es passiert auch das.
Habe ich das richtig? Ja, ja, ja,
richtig, genau. Die Reihenfolge der Ausführung ist hier nicht
mehr sichtbar, das ist quasi der Kontrollflussgraf,
aber hier sind die Abhängigkeiten sichtbar
So, jetzt hatten wir diese ganzen Strukturen. Jetzt haben wir
angefangen zu forschen und wir haben die tatsächlich auch benutzt.
Und dann passiert manchmal sowas, also ich war nicht dabei,
aber da hatte Fabian eine wirklich geniale Idee.
Und ich weiß nicht, wie es passieren konnte,
dass das so einfach rausgeploppt ist. Aber er hat gesagt,
ich will das alles in eine Graf-Datenbank schreiben.
Und da habe ich gedacht, ja klar,
das ist ein Graf, das ist ein Graf,
das ist ein Baum, aber wir alle wissen,
ein Baum ist ja auch ein Graf.
So, und dann hatte er so eine typische Informatikerkrankheit,
dass er nämlich alles optimieren will, möglichst keinen Speicher verschwenden.
Und da hat er gesagt,
ich speichere das alles in einer Datenstruktur
Es gibt ja quasi Abhängigkeiten. Und da hat er etwas erfunden,
was wir dann inzwischen Code Property Graph nennen, das ist ein Graph,
in dem diese drei Datenstrukturen ineinander vermischt werden.
Und was wir nicht wussten, ist, dass das eine Neuigkeit war.
Das wusste, also die Softwareleute haben gesagt,
das war schon immer so, ja klar,
dass man das hätte machen können, aber warum sollte man das machen?
Was alle verpasst haben, ist,
dass wenn man das in eine Graph-Datenbank reintut,
dass es dann natürlich ein unheimlich tolles Werkzeug ist und man hat alles immer gleich an der Hand.
Man muss nicht machen, load, Sintaxbaum oder load,
kontrollflos Graph, sondern man hat immer alle Kanten und
alle Knoten zur Hand
So, hier ist das Beispiel von diesem Code Property Graph,
wenn man es genau nimmt, ist das ein Multigraph,
weil nämlich zwischen zwei Knoten mehrere Kanten sein können.
Und wenn wir jetzt da reinschauen,
dann sehen wir in grün, das ist quasi der Sintaxbaum,
in rot, das ist der Kontrollfluss und in blau,
das ist der Daten der Abhängigkeitskraft.
Program Dependence Graph auf Englisch. Und das bedeutet,
ich kann hier die Sintax analysieren,
kann aber dann jederzeit hier hochlaufen und dem Kontrollfluss folgen.
Und wenn ich Lust habe, kann ich dann auch noch den Datenfluss einbeziehen.
Das heißt, ich kann zwischen diesen drei Sichten,
die ursprünglich eigentlich immer getrennt waren,
auf einmal hin und her springen
Und ich habe eine unheimliche Freiheit darin, mir zu überlegen,
will ich jetzt wissen, wie das Programm aussieht?
Will ich wissen, was das Programm macht? Oder will ich
wissen, was in dem Programm geschrieben und gelesen wird?
So, diese Datenstruktur haben wir in Graf-Datenbank gepackt.
Und da zeigte sich natürlich schon schnell,
dass das quasi genau das ist, was man braucht,
wenn man Schwachstellen suchen will.
Hier ist mal so ein Beispiel, abstrakt, was eine Schwachstelle sein könnte.
Also eine Funktion X wird aufgerufen, die ist erreichbar von
einer anderen Funktion Y. Und diese Funktion verarbeitet Z. Ja,
das ist so genau wie dieses Beispiel am Anfang.
Es gibt dieses, Dieses A-Log, also es wird ja Speicher allokiert.
Ich muss aber von außen da irgendwie ran und ich möchte gern,
dass das dieses Datafield verarbeitet, weil das ist ja das, was ich kontrolliere.
Und wenn man das übersetzt in den Compiler, dann sieht man halt,
es gibt die Sintax, das ist dieser Aufruf.
Es gibt den Kontrollfluss und den Datenfluss. Und hier habe ich
einmal SS und immer einmal SZ geschrieben. Das heißt,
eins muss ja falsch sein. Das ist schlecht. So,
und das heißt, wir haben also die Möglichkeit,
jetzt diese Beschreibung, diesen regulären Ausdruck zum Beispiel,
aber auch andere Schwachstellen in all den drei Schichten zu beschreiben und zu suchen.
So, und jetzt war natürlich die nächste Frage,
wie sucht man in einer Graf-Datenbank
Hatte ich keine Ahnung von, wie das geht.
Ich habe gelernt, es geht mit sogenannten Traversals.
Und wir wären gleich noch, ich habe da
sogar noch eine kleine Theorieformel dabei, Folie dabei.
Das ist sogar ein Konzept, was gar nicht so blöd ist.
Also zuerst dachte ich, das ist bestimmt jetzt
nur so SQL aufgebohrt. Sowas wie Select from Graph,
Ware Edge und so. Aber nein, es ist tatsächlich
auch ein theoretisch interessantes Konzept, weil es diese Idee hat,
dass man den Graph abläuft bei der Suche.
Das heißt, man startet irgendwo,
man hat eine Menge von Startknoten und dann ist die Abfrage
eine Menge von Regeln,
die sagt,
wie laufe ich da jetzt durch
Marschiere ich da einfach so lange durch, bis ich
Knoten X finde. Oder sammle ich alle Knoten ein,
bis ich so und so viele Knoten habe.
Und dann laufe ich alle Kanten, die grün sind.
Und dann laufe ich alle Kanten, die rot sind.
Also im Prinzip, man programmiert sich einen Lauf durch den Graf.
Und das kann man in einer Programmiersprache machen. Ich habe
die Beispiele rausgenommen, aber es ist eine echte Programmiersprache.
Gremlin, mit der man diese Läufe programmieren kann.
Was mich nervt an der Sprache, die ist basiert auf Groovy.
Kennt jemand hier Groovy im Raum? Ich bin nicht warm
geworden mit Groovy. Weil das ist so eine Art Java
Weiß ich nicht, Java 2 oder 3. Also,
da fange ich zu alt dafür. Aber Fabian programmiert also
diese ganzen Gremlin-Sachen in Groovy, wenn man sich es anguckt,
sieht es so aus wie Java ein bisschen.
Oder? Naja, keine Ahnung. Also es ist jedenfalls
eine Touring-vollständige Programmiersprache. Man kann darin wesentlich mehr ausdrücken als
zum Beispiel in SQL, was nicht Touring vollständig ist.
Und im Prinzip kann man sehr, sehr viel eigene Logik
in diesen Ablauf stecken. Sowas zu den Traversals.
Die Tragörsals sind so definiert wie hier. Das heißt,
sie bilden nicht von einem Knoten ab auf einen anderen Knoten,
sondern sie bilden immer von einer Menge von Knoten
auf eine andere Menge von Knoten ab
Und deswegen sind sie in ihrer ursprünglichen Definition
hier über die Potenzmengen der zwei der Knoten,
also V ist die Anzahl der Knoten im Graf,
habe ich jetzt nicht gesagt, aber klar.
Das heißt, man bildet immer von einer Menge,
auf eine andere Menge ab. Und das Tolle ist,
dass das halt quasi Anfang und Ende gleich ist. Das heißt,
man kann diese Traversals hintereinander stecken und man kann auch verschiedene Traversals miteinander kombinieren,
weil sie immer alle eine Menge von Knoten reinkriegen und eine Menge von Knoten rausgeben.
So, ich habe jetzt hier mal das,
um mal so ein Beispiel zu zeigen,
wie sowas aussehen könnte,
habe ich hier
so zwei ganz triviale Traversals
Also in Gremlin sieht das noch viel schlimmer aus,
aber so in dieser formalen Notation, finde ich, geht's.
Also hier kommt quasi eine Menge von Knoten X
rein und wir gucken uns die Kanten an.
Wir gehen alle Elemente durch und dann geben wir diese U aus.
Mit anderen Worten, das heißt eigentlich nur,
ich kriege eine Menge von Knoten rein und alle,
die ich mit einem Schritt erreichen kann, kriege ich wieder raus.
In eine Richtung. Und hier in,
das ist genau das Gegenteil, ich kriege eine Menge von Knoten,
gebe ich rein und ich kriege die raus,
die da hinführen würden.
Klar, was ich meine. Ist total simpel eigentlich.
Ist nur so Pseudo-mäßig aufgeschrieben,
weil es in Gremlin natürlich noch
viel schlimmer wäre
Und dann gibt es hier noch so eine,
auch noch etwas verkopfte Notation,
Filter P. Ich tue eine Menge von Knoten rein,
ich kriege nur die zurück, die ein Prädikat P erfüllen.
Prädikat ist halt irgendeine Bedingung. Also ich könnte das P definieren,
als ist grün oder steht Hamburg im Text drin oder was ich will.
Und dann kann ich das natürlich zusammenknoten hier,
out in Filter und kann dann da durchlaufen und sagen,
gut, gib mir alle,
die rausgehen und mach das fünfmal und dann gib mir alle,
die grün sind.
Das haben wir gemacht und haben dann quasi unsere eigene Bibliothek von Traversals gebaut,
die nur das Zweck haben, nach schwachen zu suchen.
Also man kann in diesem Code-Property-Graph auch eine ganze Menge anderer Dinge tun.
Ja, also man könnte da auch bestimmt einige oder andere Fragen der Softwaretechnik beantworten.
Aber wir haben gesagt, nee, uns interessieren nur die Schwachstellen.
Hier ist mal so ein Beispiel, hier,
das ist auch schon so eine Funktionskompositionsnotation, die Fabian toll fand.
Hier passiert also folgendes. Wir sagen, es gibt einen
Match-Traversal und das besteht aus der Komposition von zwei einfacheren Traversals.
Das eine ist das Filter, das hatte ich hier,
das prüft ein Prädikat. Und das andere,
das nennt sich Teenotes, das heißt einfach Treenotes.
Das heißt, der geht den Baum runter und prüft für
alle Knoten in den Baum, ist dieses Prädikat erfüllt.
Super simpel eigentlich
Genau, und so haben wir uns eine Bibliothek gebaut. Und wer jetzt,
äh, mutig, und, äh, auch,
äh, hart gesotten ist, der kann in dem Papier,
was ich am Anfang da referenziert habe, nachschauen,
da stehen diese Dinger, die wir gebaut haben,
tatsächlich formal drin.
Wer eher praktisch orientiert ist, das zeige ich am Ende,
der kann auch auf das Open-Source-Projekt gehen.
Und da stehen die gleichen Dinger in diesem Groovy-Code drin oder Gremlin. Ja,
das heißt, das, was ich jetzt hier erzähle,
das sieht zwar so formal aus, aber es hat alles in realen Kernen.
Es gibt es auch alles in Wirklichkeit. So,
und jetzt kann man quasi das,
was Stefan Esser da am Anfang gebaut hat,
das kann man jetzt auch, und das ist jetzt hier tatsächlich Groovy-Gremlin-Code,
Glaube ich.
Ja, ist es. Das ist also jetzt tatsächlich so,
wie der Experte dieses Grab benutzen würde, was wir ihm geben.
So, was macht es? Das steht hier oben.
Es sucht alle Aufrufe von Mellock und betrachtet das erste Argument.
Mellock hat nur ein Argument. Erster Argument,
auch Nullte Argument hier, weil wir Informatiker sind.
Das heißt, es ist ein bisschen manchmal schwierig zu lesen.
Dann lassen wir uns diese ganzen AST-Notes geben. Das heißt,
wir holen uns aus diesem ersten Argument, das den Passbaum raus oder Sintaxbaum.
Und in diesem Passbaum schauen wir, gibt es da eine
additive Expression? Gibt es einen Ausdruck,
der addiert
Das ist quasi genau das Gleiche, wie das Stefan Esser
gemacht hat. Nur in schön, würde ich sagen,
weil wir eben nicht einfach nur mit einem regulären Ausdruck darüber gehen,
sondern weil wir tatsächlich verstehen, was da auch passiert.
Das heißt, der reguläre Ausdruck wird natürlich auch fehlalarm generieren,
weil er nicht, er weiß nicht, was er macht.
Wir wissen hier zumindest zu einem gewissen Grad, was wir machen.
Wir können nachher in der Fragerunde gern nochmal über die Grenzen der Methode sprechen.
Wir können natürlich auch nicht alles analysieren. Also vielleicht,
wenn ich jetzt den Eindruck erwecke, dass es so wäre,
das ist nicht so. Software, wie wir es hier machen,
statisch, ohne sie laufen zu lassen, zu verstehen,
ist auch nur immer zu einem gewissen Grad möglich.
Da gibt es auch theoretische Grenzen, die man nicht brechen kann.
So, hier ist noch ein bisschen größeres Traversal.
Da sieht man auch mal, dass es dann auch so
eine richtige Code-Struktur kriegt. Das hier, glaube ich,
ist so ein Groovie-Quatsch irgendwie mit diesen,
weiß ich nicht, ich habe es so abgeschrieben,
wie es ist und mir quasi auch erklären lassen,
was es macht.
Also man kann es auch lesen, aber ich verstehe zum Beispiel nicht,
warum das hier mit so Punkten verschachtelt ist.
Was macht es? Am besten liest man es von unten
nach oben
So ist nämlich der Fluss der Daten. Also hier starten wir,
wir suchen nach einer Variable, die zum Beispiel Count heißt,
oder CNT. Genau. Nach so einer Variable suchen wir.
Und dann schauen wir, wie wird diese Variable verarbeitet?
Wird zum Beispiel ein Check gemacht. Das heißt,
gibt es ein IF, was darauf prüft?
Oder gibt es eine andere Bedingung, die diesen,
dieses Count verwendet? Oder liegt auf dem Pfad ein ALOC,
dann ist es vielleicht okay, weil dann wird ja noch Speicher aluziert.
Oder wird da irgendwo eine Funktion Min aufgerufen. Das bedeutet ja,
jemand weiß, wie groß der Buffer ist und wie groß count es.
Und dann macht er Min davon. Und man sieht jetzt hier in dem Beispiel schon,
diese ganzen Funktionen, die haben wir selber geschrieben,
also das Code Contains ist Chack und so weiter.
Und Unsended heißt, das heißt, wir haben unsere eigene Toolbox,
wir müssen gar nicht mehr so richtig in diesen Code-Property-Graph reinschauen.
Und dann wird hier oben geschaut, landet das, dieser Wert von dem Account,
ohne diese Jacks, in einem Mem-Copy an der dritten Position.
Und wer Mem-Copy von C kennt, der weiß,
die dritte Position sagt an, wie viel Bytes kopiert werden.
Also mit anderen Worten, hier suchen wir nach Code,
der irgendwie was zählt und dann etwas kopiert. So,
und jetzt gibt es noch eine Einschränkung, wir suchen nicht irgendwo,
sondern wir suchen im Linux-Kern und wir suchen nach Funktionen, die right heißen.
Weil nämlich in diesem, da gibt es eine gewisse Code-Konvention,
dass diese Variablen auch wirklich so heißen.
Also das, wir betrachten jetzt hier so eine Code-Basis,
die ein bisschen organisierter ist als jetzt so ein,
weiß ich nicht, Studentenprojekt oder so.
Also da gibt es quasi Regeln, wenn ich was zähle,
dann muss das auch Count heißen. Und das nutzen wir uns natürlich hier schamlos aus,
weil dann können wir sagen, okay,
wenn da was gezählt wurde, dann bitte,
und es kommt in den Mem-Copy rein, dann bitte nur,
wenn dann ein If, ein Elocate oder ein Minderzwischen ist.
Ansonsten sagen wir, das ist auf jeden Fall
nicht sicher
Gut, das haben wir so gebaut. Jetzt trinke ich mal
einen Schluck Wasser. Und natürlich muss man, wenn man sowas baut,
sich dann fragen, ist das auch praktisch relevant?
Also natürlich, ich glaube, das kam jetzt rüber,
da kann man jetzt so eine Theorie rumspinnen und man kann das Ganze in so ein Framework hießen,
dann schreibt man so ein Paper,
das heißt A Framework 4 und dann wird das ganze Framework vorgestellt.
Und dann wird das vielleicht veröffentlicht und niemals zitiert,
weil nämlich keiner weiß, bringt es das?
Und da haben wir überlegt, wie wir das evaluieren wollen.
Wir sind zwar selbst so, wie soll man sagen,
Pseudo-Experten. Also wir sind ja Akademiker, das heißt,
wir wissen nicht ganz genau, wie es in der Praxis eigentlich läuft.
Wir haben nur so ein Gefühl. Und deshalb haben wir
uns gedacht, wir brauchen vielleicht jemanden,
der wirklich den ganzen Tag über Bugs sucht.
Und da haben wir die Nico Golde kennengelernt, oder?
Ja. Der inzwischen bei Qualcom arbeitet und sein Brot damit verdient,
im Linux-Kern für die Firma Qualcom Schwachstellen zu suchen.
Quasi 40 Stunden die Woche sucht er Schwachständer.
Dazu muss man wissen, Qualcom ist ein großer Chiphersteller
Die drittgrößter, so nach Intel AMD und im Prinzip die
ganzen Mobiltelefone und so weiter, die benutzen alle Qualcomm-Chip-Sätze.
Das heißt, hier im Raum ist wahrscheinlich mehr Qualcomm-Chips als Intel oder AMD.
Weiß nicht, wenn ihr alle einen Laptop in der Tasche
habt, aber die ganzen Handys, Qualcomm.
Und die haben ein eigenes Linux,
was teilweise auf diesen Geräten läuft und teilweise auch in Bereichen läuft,
wo der Benutzer es gar nicht sieht.
Also dazu muss man wissen,
dass auf einem Mobiltelefon läuft nicht nur das Betriebssystem,
was da oben drauf ist,
also Android oder iOS oder Windows
Oder Fox OS, wie das heißt,
sondern es laufen auch noch Betriebssysteme unter diesem drunter,
die sich zum Beispiel mit der Kommunikation mit der GSM-Stelle beschäftigen.
Oder bei iOS weiß ich es, da läuft
ein kleines Betriebssystem, was sich mit dem Fingerabdrucksensor beschäftigt.
Das sind eigene abgeschlossene Systeme, die nur über gewisse Schnittstellen kommunizieren.
Deshalb hat Qual kaum Interesse daran, Linux sicher zu machen,
weil sie eben nicht nur Android sicher machen wollen,
sondern auch ihre kleinen Linuxe, die auf den ganzen Smartphones und anderen Geräten laufen.
So, dann haben wir uns erstmal alle Schwachstellen von 2012
im Linux-Kern zusammen mit Nico angeguckt
Und ich springe mal eine Folie vor. Haben erst mal geschaut,
welche Schwachstelle können wir damit beschreiben mit dem, was wir haben?
So, und da haben wir ungefähr zwölf Arten von Schwachstellen
festgestellt, die es so üblicherweise gibt.
Wer jetzt mal so eine Vorlesung über IT-Sicherheit besucht hat,
der findet da das eine oder andere Wiese, also Buffer-Overflow,
habt ihr bestimmt schon mal gehört, oder?
Also, Buffer-Overflow muss man natürlich kennen. Dann sowas wie
Race Condition, das ist ja so Bereich Betriebssysteme,
wenn also zwei Prozesse gleichzeitig irgendwas wollen und das führt zu Problemen.
Andere Sachen sind dann schon so ein bisschen spezifischer,
gut, Integer-Overflow kennen wir auch.
Kennt jemand Use-After-Free
Als Schwachstellen-Typ. Ah ja, super. Also Schwachstellen,
die dadurch entstehen, dass ich Speicher habe.
Und dann gebe ich ihn frei und dann benutze ich ihn noch.
Und dann schreibe ich nämlich irgendwo rein, wo ich eigentlich gar nicht reinschreiben soll.
So, und dann haben wir festgestellt, was kann der AST anschauen?
Was kann der ASD plus PDG, AST plus CFG?
Was können wir? Wir können natürlich alles, also,
aber das liegt ja daran, dass wir die anderen Dinge gemerged haben.
Also so eine, das ist jetzt nicht so ein Wahnsinn.
Wir haben halt alles in einer Hand und von daher,
alles, was man mit diesen Funktionen hier mit diesen Konzepten findet,
kann man auch finden.
Wir können Race Conditions und Design-Errors nicht finden.
Also klar, Design-Errors sind sowieso wahnsinnig schwer zu finden.
Weil dazu muss man ja verstehen, was da eigentlich passiert ist.
Race Conditions sind deswegen schwer zu finden,
weil sie sich meistens erst zur Laufzeit sichtbar werden.
Wenn man ein cooles Modell hat von dem,
was man da macht, kann man vielleicht so eine Simulation machen,
also indem man den Ablauf so ein bisschen entfranzt.
Aber wenn man nicht dieses Modell hat und beim Linux-Kern gibt
es so eine Modelle gar nicht, dann kann man nichts anderes machen,
als einfach zu warten, führt das zur Laufzeit zu Problemen.
Das können wir nicht, weil wir führen nichts aus.
Und dann Use After Free, Haben wir in Klammern?
Ich weiß nicht, weiß einer, wie normalerweise Use After Free auftreten?
Also dieser Bug entsteht, also er kann auf verschiedenste Weisen entstehen,
häufig entsteht er aber dadurch, dass es zwei Prozesse gibt oder Threads.
Einer ist fürs Memory-Management zuständig,
einer macht irgendwas und die sind irgendwie so ein bisschen asynchron und dann ist der eine,
der den Speicher quasi verwaltet, schon der Meinung,
okay, alle sind fertig,
gibt dann den Speicher frei und der andere schreibt in der Sekunde gerade noch rauf.
Das können wir auch nicht erkennen,
weil es mich auch mit der Laufzeit zu tun hat.
Wenn es aber in einem Thread passiert, dann können wir es finden.
Also wenn es quasi nur einen Ablauf gibt und es ist
statisch sichtbar,
dann können wir
es finden
So, dann hatten wir das gemacht. Und dann haben wir gesagt,
gut, dann bleibt uns jetzt nichts anderes rüber.
Wir laden jetzt den Linux-Kern in das System rein.
So, und da habe ich dieses coole Bild mitgebracht.
Das ist der Linux-Kern. Wenn man jetzt genau schaut,
stellt man fest, dass man gar nicht so viel sieht,
wie man denkt.
Also das ist theoretisch der Code Property Graph.
Aber leider nur theoretisch. Das hier ist das Hauptverzeichnis
des Kerns und alle diese kleinen Punkte hier,
das sind Quellcode-Dateien
Und eigentlich ist dieser, diese Abbildung eine Mogelpackung,
denn in Wirklichkeit sieht man noch gar nicht den AST,
CFG und PDG, weil unter jedem dieser kleinen Punkte fängt er erst an.
Aber ich wusste nicht, wie ich das visualisieren soll.
Das war ja so schon, das war so schon schwer.
Aber theoretisch muss man sich vorstellen, unter jedem Punkt beginnt
quasi erst das Ganze. Hier habe ich die Zahlen mal,
also der Linux-Kern, 52 Millionen Knoten, 97 Millionen Kanten,
würde man jetzt sagen, ist wahrscheinlich so ein Spasa-Graf,
also die Anzahl der Kanten ist nicht wesentlich höher als die Anzahl der Knoten,
also doppelt so hoch, das ist noch verhältnismäßig Spaß.
Toll ist die Laufzeit, das Einlesen von dem ganzen Ding
, dauert ungefähr zwei Stunden. Also das heißt,
wenn man jetzt einen Fehler suchen will,
macht man das an, geht Mittagessen, kommt wieder,
dann hat man das quasi geladen.
Und dann kann man aber abfragen in diesem Graf innerhalb von 30 Sekunden beantwortet kriegen.
Im Durchschnitt. Da würde jetzt Fabian eine ganze Menge über
diese technischen Details erzählen, die ich auch nicht weiß.
Das hat was mit Cold und Hot-Knotenmengen. Also da gibt
es ganz ausgefuchste Caching-Strategien, weil natürlich dieser Graf kann
Auf den Rechnern, die wir in Braunschweig haben,
nicht komplett im Speicher liegen. Das ist in Hamburg hier
wahrscheinlich anders. Also wenn man ein Terrabyte RAM hat,
dann kann man, glaube ich, da schon viel machen.
Wir haben vielleicht nur so 256 Gigabyte.
Und das bedeutet, man muss diese Caching-Sachen sehr ausgefuchst einsetzen.
Gut, dann haben wir das gemacht. Und da haben
wir viel gefunden. Ich habe jetzt für den Vortrag
nur eine Sache ausgewählt. Wir haben 18 Schwachstellen im Linux-Kern
gefunden, die zu dem Zeitpunkt unbekannt waren
Dieser CVE-Nummer hier, also die CVE-Nummer ist für den Schwachstellensucher
quasi so der heilige Gral oder das ist die Währung,
in der er bezahlt wird. Wenn man eine CVE-Nummer bekommt,
bedeutet das, dass es also all diese Obergeordnete,
das ist ein Institut Amerika, zusammen mit dem ZERT,
die also bestätigen, das ist ein schwerer Sicherheitsfehler,
der bekommt diese Nummer und dann wird das auch entsprechend verbreitet
und das wird auch an die ganzen ZERTs weltweit verteilt.
Ja, das heißt, es gab irgendwann eine Mail,
vielleicht auch an die Uni Hamburg, hoffe ich mal,
wo drin stand, das sind neue Schwachstellen, bitte patcht eure Systeme.
Wenn man keine CVE-Nummer bekommt, weil die sagen,
das ist nicht so schlimm, dann ist das auch nicht so schlimm.
Das heißt, das ist das, also wo wir stolz drauf waren.
Zuerst. Irgendwann guckt, was wir gefunden haben,
sieht man auch von unseren Arten, von Schwachstellen,
die wir gesucht haben, haben wir einiges gefunden.
Wir haben nicht alles gefunden, aber wir haben also Memory-Mapping,
Memory-Disclosure, Overflows und auch Zero White Elocations gefunden.
Und dann kam also der Tag,
an dem ich ins Büro kam und Fabian sagte zu mir,
du wirst es nicht glauben,
ich habe heute eine E-Mail von Linus Torwarts gekriegt,
war leider nur ganz kurz,
stand drin,
vielen Dank,
dass ihr so viele Bugs gefunden habt,
so weitermachen
Die haben uns aufgehängt, weil wir da das Gefühl hatten,
das ist quasi bei einer, bei einer Stelle angekommen,
wo jemand auch sagt, das ist erstaunlich, dass ihr als Leute,
die ja nicht irgendwie in der Sicherheitsindustrie tätig seid,
mal eben so in zwei,
drei Monaten 18 unbekannte Schwachstellen in so einer gewarteten Software findet.
Ja, also man muss ja auch überlegen, der Linux-Kern ist ja,
das ist nicht eine Software, die guckt sich keiner an,
sondern jetzt in diesem Moment sitzen ja wahrscheinlich Dutzende von Leuten
und schauen sich diese Software an auf der Suche nach Bugs.
Und als wir das gemacht haben,
konnten wir noch 18 finden, wir haben die Hoffnung,
dass da noch mehr drin ist,
aber es ist halt Software,
die sehr,
sehr viel gewartet wird
So, das bringt mich schon zum Ende,
man will auch gar nicht so überziehen.
Was sind denn die Kernaussagen von dem Vortrag,
wenn wir jetzt mal neben der ganzen natürlich superinteressanten technischen Komponente neben der interessanten Hacking-Komponente?
Also die erste Sache, die ich vielleicht motivieren wollte,
ist, Schwachstellen sind ein ernsthaftes Problem und auch ein Problem,
für das es zurzeit noch keine richtige Lösung gibt und ein Problem,
wo es vielleicht auch niemals richtige Lösungen gibt.
Ich bin ein bisschen vorsichtig, Es gibt eine ganz gute
Lösung, wenn man Schwachstellen minimieren will.
Und das ist, wenn man Programmiersprachen verwendet,
die von vornherein schon darauf achten, dass viele Sachen nicht passieren.
Aber da gehört leider C und C plus Plus nicht dazu.
Die meiste Systemsoftware wird in C oder C plus Plus geschrieben.
Aber zum Beispiel die Studierenden, ich weiß nicht,
wie das hier in Hamburg ist, lernen ja meistens nicht C,
sondern sowas wie Java oder was lernt man hier?
Swift oder Go, also eine andere Programmiersprache und bei einigen anderen Fragen,
zum Beispiel Java, sind gewisse Arten von Fehlern ausgeschlossen,
weil einfach die Sprache von vornherein so gebaut ist,
dass es nicht passieren kann
Wenn man eine C programmiert, wird man das Problem nicht los.
Und solange wir noch einen C programmieren, ist also
das ein ungelöstes Problem. Und unsere Idee ist,
anstatt immer zu versuchen, es komplett automatisch zu machen,
Werkzeuge zu bauen, die einem Experten helfen.
Und wir konnten zusammen mit dem Nico Golde von Qualcom zeigen,
dass wenn das der Experte macht und man ihm sagt,
wie wir es wollen, dass der auch erfolgreich ist und auch Riesenspaß hat.
Also der benutzt das jetzt noch. Der hat das in
seine tägliche Arbeit aufgenommen
Und wir haben jetzt als unser Beispiel Code-Property-Gras verwendet.
Ich würde nicht sagen, dass dieser Ansatz beschränkt auf diese eine Darstellung ist.
Vielmehr würde ich sagen, es gibt viele andere mögliche Darstellungen,
die man eben entwickeln muss, um dann so was zu machen.
Da müssen halt dann andere Leute ran und inzwischen konnten wir
über 40 Schwächen finden. Alleine mit diesem einen Ansatz,
den ich jetzt hier vorgestellt habe.
So, jetzt kann man sagen, was passiert als nächstes?
Wie geht es weiter? Eine Sache war,
wie konstruiert man denn diese Traversals am besten automatisch?
Ich bin jetzt ganz faul. Ich bin jetzt,
ich möchte eigentlich den Experten nur kurz mal anrufen und
dann möchte ich aber,
dass das alles automatisch läuft
Und das konnte ich jetzt nicht erzählen, aber das ist quasi auch ganz spannend.
Man kann diese Traversals zu einem gewissen Grad auch automatisch generieren,
indem man sich eine Software nämlich anschaut und guckt,
was sind denn da die Datenflüsse?
Also gibst du da immer, also haben wir ja im Prinzip auch gemacht.
Also man schaut sich zum Beispiel die Mem-Coppies an und baut dann automatisch so Bäume auf,
die eben alle Datenflüsse zu dem Mem-Coppy sind.
Und dann kann man daraus nur wieder auch so ein Traversal
generieren und sagen, hier, zack, finde das mal.
Eine Sache, die wir auf dem Schirm haben,
aber uns noch nicht trauen, ist Was ist mit Hardware?
Könnten wir nicht zum Beispiel in den Graf auch Hardware integrieren,
indem wir sagen, der Knoten ist jetzt zum Beispiel das Bremspedal,
um jetzt mal so ein ganz krankes Beispiel zu wählen.
Und der Datenfluss geht also über, dass die Netzwerkschnittstelle hin, bis zum Bremspedal.
Wäre ja auf jeden Fall sehr sexy. Und auch wäre vielleicht auch nötig,
da mal zu schauen, ob es da so Unsinitizes,
Datenflüsse gibt oder andere Schwachstellenarten, die eben direkt auf Hardware,
Auto, muss aber kein Auto sein,
kann auch ein Atomkraftwerk sein.
Also alles, wo quasi Wie heißt das jetzt, Neudeutsch?
Sei über physische Systeme. Da,
wo also aus der Cyberwelt in die physische Welt übergegangen wird.
Dann haben wir, da sind wir gerade dabei,
das läuft. Wir haben so einen Google-Preis gewonnen,
mit dem man also das Geld dann für Forschung einsetzen kann.
Und da bauen wir das System für Binär,
oder Binär ist falsch, für einen nativen Programmcode.
Also quasi für übersetzte Programme. Das liegt daran,
dass an vielen Orten wird die Software ja nicht kompiliert.
Also wenn man jetzt nicht, kennt jemand noch kein Two?
Oder Gen-Two
Also, wenn man nicht ganz verrückt ist, kompiliert man
sich nicht sein ganzes Betriebssystem selber. Das hat man so,
Mitte der 2000er gemacht, als ich noch juckt war,
aber das ist ja total, es dauert ewig.
Und deswegen lädt man sich natürlich die Software runter und
ganz oft bekommt man auch gar nicht den Quellcode.
Also, wer Microsoft oder Apple-Kunde ist, der weiß nicht, was da läuft.
Und das weiß Google auch und es wissen auch Apple und Microsoft,
immer wenn man was von extern sich reinholt,
will man auch prüfen, ist das sicher oder nicht.
Und dazu kann man unseren Ansatz nur verwenden, wenn man
in der Lage ist, auch quasi Assembler zu verstehen.
Doch noch einmal zur Zeit, das ist natürlich nicht so schön,
weil Da hat man ganz andere Hindernisse.
Also alleine das Verstehen von dem Maschinencode,
das automatische Aufbereiten, Kontrollfluss, Datenfluss, ist super aufwendig.
Es gibt ein Open-Source-Projekt, das heißt Jörn. Und zurzeit
wird auch eine Firma gegründet, die das Ganze weitertreiben soll.
Ich bin mir jetzt gar nicht so sicher, also Jörn,
das, was ich heute erklärt habe, heißt Jörn.
Aber die binäre Version zum Beispiel heißt Björn.
Und das Ganze gibt es auch für PHP,
da heißt es Pjörn
Das soll alles unter dem neuen Dach Oktopus, glaube ich,
unterkommen, wo quasi die verschiedenen Arme des Oktopus sind, die verschiedenen Code-Repräsentationen.
Ich weiß aber nicht, wie weit Oktopus ist,
aber wer jetzt Zeit hat für Open-Source-Projekte,
sein Hobby zu opfern und das zu machen,
der sei eingeladen, hier mal hinzugehen.
Das ist quasi so eine Seite, wo wir unsere Software normalerweise veröffentlichen.
Und von da geht es wahrscheinlich irgendwo zu GitHub und da ist quasi die Action.
Genau, und wer sich dafür noch mehr interessiert,
der kann sich an mich wenden,
aber ich werde alle Fragen automatisch an Fabian weiterleiten.
Deshalb kann man sich auch
gleich an Fabian wenden
Fabian ist halt unheimlich daran interessiert an Leute,
die sich das mal angucken und auch benutzen.
Und also bisher war das so erfolgreich,
dass sich das hier auch explizit nochmal sage.
Also wer sich das anguckt und Spaß dabei hat,
der findet da ein offenes Ohr.
Ja, das ist ein gelebtes Open-Source- Projekt.
Das ist noch nicht so abgestorben wie Thunderbird oder so,
wo es keine richtige Entwicklung mehr gibt.
Okay, das war mein Vortrag. Ich bin bereit für Fragen.
Ich greife mehr moderiert ein, wenn das erforderlich ist.
Bitteschön, die Fragen. Vielen Dank für den super Vortrag
Ach, ich hätte da mal eine. Ich habe sogar
dran. Also ich fange mal an mit einer harmlosen Frage.
Ihr habt ja nur diese 18 Fehler gefunden.
Und mich interessiert das Verhältnis von gewissermaßen Kandidaten,
in denen Schachstellen drin sein könnten und den eben 18. tatsächlich gefunden in so einem riesen Ding.
Also das heißt, wie viel Maruelis aussortieren ist.
Genau. Prozentual. Also das ist so eine Problematik,
um die wir uns ein bisschen drücken wollen.
Also weil Alle Gutachter haben immer gesagt, was ist denn mit den Fehlalarmen?
Ihr müsst die quantifizieren. Aber was wir eigentlich wollen,
ist ja, dass der Mensch das analysiert.
Und daher haben wir es jetzt immer so gemacht,
dass für jedes der Traversal, haben wir uns die Top 20 geben lassen.
Das heißt, wenn man 18 Schwachstellen gefunden hat,
dann hat man diese 18 Schwanzstellen in den Top 20 gefunden.
Das heißt, im Worst Case sind 19 Fehlalarme pro Finding
dabei. Und wir finden das fantastisch,
aber zum Beispiel in der wissenschaftlichen Community würde dann ja so
eine Zahl entstehen,
wie 90 Prozent ist nicht
so gut
Wenn man jetzt nur das anschaut, ne?
Und das deswegen haben wir uns da ein bisschen drum gedrückt.
Man kann es auch andersrum formulieren und sagen,
Kandidaten sind alle Anweisungen, die es gibt.
Dann wären wir bei 0,0001. Aber irgendwie dieses Modell mit den Fehlalarmen ist ein Modell,
was man nur, also was richtig Sinn eigentlich nur macht,
wenn es komplett automatisiert ist.
Wenn man wirklich diese Fehlalarme, wenn man da leidet.
Ja, ich glaube, dann habe ich mich nicht richtig ausgedrückt.
Dann frag noch mal. Weil ich ja weiß,
dass die Ergebnisse viel besser sind. Also wenn ich mir
jetzt vorstelle, dass ich alles einfach manuell angucken müsste,
dann habe ich sozusagen alles als Kandidaten
Wenn man so will, der Extremfall, wenn man so will,
die Null war. Ja. Und jetzt stellt sich
die Frage, wie viel besser ist sozusagen die Methode?
Jetzt war es erstmal andersrum. Da muss man ja auch
auf irgendwas kommen, aber es kam nicht 90 Prozent sein.
Was man jetzt gebraucht hätte, wenn man das beantworten wollte,
man müsste sich einen zweiten Sicherheitsexperten holen,
einen zweiten Nico Golde und dem müsste man sagen,
du machst das alles mit Grab.
Und dann hätte man einfach vergleichen müssen,
wie viel findet der mit dem Grab und wie viel findet
der mit unseren Chaversals? Das ist schwierig,
wir haben es nicht gemacht,
aber eben alle anderen Vergleiche sind so ein bisschen unfair für
die eine oder die andere Methode
Weil ja bei uns quasi programmiert wird. Das heißt,
wir schaffen ja quasi neue Dinge. Man kann das jetzt
gegen irgendwelche Tools vergleichen. Aber die Fehler waren ja noch
drin. Das heißt, die Tools werden immer verlieren.
Die haben sie halt nicht gefunden. Aber das heißt ja nicht,
dass die Tools schlecht sind. Vielleicht haben die in der Vergangenheit
schon 500 andere Sachen gefunden. Also mit anderen Worten,
eine richtige, saubere, quantitative Analyse von Schwachstellen ist sehr schwierig.
Es gibt aktuell eine super interessantes Papier,
wo die sagen, weil das so schwierig ist,
fügen wir die Fehler künstlich in die Software ein,
weil dann wissen wir auch, wie viel da drin sind.
Und dann können wir auch endlich messen,
wie viel hast du gesehen, wie viel hast du nicht gesehen,
wie viel sind falsch positiv.
Das ist aber jetzt im Mai rausgekommen
Von daher kann ich jetzt noch nicht dazu sagen,
ob das für uns nützt. Wenn ich das richtig verstanden habe,
wurde ja durch ihren Ansatz nach einer Fest von diesen Beispielen her abgeleiteten Menge von Mustern gesucht.
Welche Überlegungen kann man anstellen, sich die Frage zu stellen,
ja, wie viel Muster gibt es noch,
die eigentlich Schwachstellen sind, aber zum Beispiel in dieser Liste von,
die sie übernommen haben,
wenn sie vorgekommen sind.
Aber eben auch dazugehören
Ich meine, in einer desziplinierten Sprache gibt es wenig,
das hören Sie ja schon an,
wenn Leute da aber trotzdem bleibt auch das unangenehme Gefühl.
Ja, ich habe da so ein paar Beispiele jetzt in
eine Nachfrage übersetzt und das läuft alles sehr gut.
Aber wie viele habe ich nicht erwischt? Ja, die Antwort
kann ich Ihnen nicht geben. Also das ist tatsächlich,
das ist nicht geklärt. Vielleicht könnte man sogar überlegen,
ob man das theoretisch gar nicht klären kann.
Aber ich will mal ein Beispiel nennen, in den 2000er
Jahren ist eine völlig neue Art von Schwachstellen gefunden worden.
Das nannte sich dann Format String
Schwachstellen. Das ist also immer dann,
wenn man Print F benutzt, kann man das also missbrauchen.
Und da ist die Geschichte wie bei dem Bash,
also quasi 40 Jahre lang, hat nie jemand daran gedacht,
dass man vielleicht mit diesem Prozentzeichen in dieser Print F-Anweisung irgendwas machen kann.
Dann hat das jemand gefunden und dann hat sich herausgestellt,
das ist eine ganz eigene Art von Schwachstellen, die auch eigene Charakteristiker hat.
Und so habe ich die Sorge,
wenn wir jetzt hier aus dem Raum rausgehen,
findet irgendwo jemand auf der Welt etwas, was noch keiner bedacht hat.
Es ist überall und dann ist das wieder so eine neue Schwachstelle.
Hartbleed ist ja auch ein super Beispiel. Das ist eine Sicherheitsbibliothek,
die verwendet man, also Open SSL, man verwendet es,
um zu verschlüsseln, um zu authentifizieren.
Das ist eine ganz, ganz tolle Sicherheitssache. Und keiner merkt,
dass da zwei Jahre lang eine Schwäche drin ist,
die eigentlich dann alles wieder rückgängig macht.
Also die Quintessenz ist, das Messen, was wir nicht finden,
ist schwer. Man kann nur messen, das,
was man weiß und hätte finden können. Also wir haben
ein paar Sachen auch nicht gefunden oder können die gar nicht finden.
Ob da in dieser Tabelle noch 30 neue Spalten sind,
mit anderen fiesen Sachen, weiß ich nicht, kann sein.
Wollen wir es nicht hoffen? Ja. Zwei Qualifierungen,
wenn der Fegereizer, der fragt die Fehler,
haben wir das Gebäck, kann man das noch anders hinlassen.
Haben andere Projekte in Königreich und Arbeitsaufwand
Ja. Ich würde sagen nein,
also ich habe noch von keinem gehört, aber,
also ich habe von keinem gehört,
aber es könnte schon sein, das ist ja quasi,
also zu der Zeit, wo wir es gemacht haben,
nicht definitiv, aber es kann natürlich sein,
dass vor zehn Jahren mal jemand irgendwas anderes gemacht hat und da war natürlich die Codebasis auch noch auf einer anderen Qualität,
aber ich würde sagen,
es gibt immer wieder mal so innovative und sehr kräftige Sicherheitsprojekte,
die Schwachstellen finden.
Also als das Fazing,
diese Technik, mit dem randomisierten Beschießen aufgekommen ist,
gab es auch so eine Welle,
wo ganz viel Schwachstellen in Protokollimplementierung
gefunden wurden
Unsere Welle ist nicht halb so groß wie die vom Fassing.
Also da ist eher so mal 100 die Anzahl der Fehler.
Nicht im Linux, aber in Software. Von daher,
ich weiß jetzt erst mal von keinem, aber ich glaube sowas,
es kann jederzeit wieder mal jemand eine gute Idee haben.
Ja. Ich würde interessieren, sie hatten am Anfang ja,
sie hatten in ihrer Präsentation die Linux vorstellen gezeigt,
die hatten anderen mit CKE von 2013.
Also sind jetzt auch schon drei Jahre praktisch her.
Wie ist es in der Industrie angenommen worden, das Konzept?
Beziehungsweise was sind die Probleme, warum es nicht angenommen wurde als beispielsweise Stefan?
Erstmal meine ich, ich nutze immer noch Grap.
Stimmt. Was sind da die Würden,
die da stehen
Also Stefan Esser, also den muss man einfach nur auf Twitter folgen,
der wird wahrscheinlich sein Leben lang Grab benutzen und
er kann das ja auch einfach so unglaublich gut.
Die Industrie, da will ich jetzt,
das ist eigentlich fast wie eine vorbereitete Frage.
Also die Industrie ist mega scharf darauf. Also tatsächlich,
warum wir die Ausgründung machen, ist,
unabhängig hat uns Google, Microsoft und Amazon kontaktiert.
Und alle haben gesagt, sie wollen das haben.
Und ich habe dann zu Fabian gesagt,
dass für mich als Uni oder als Professor an der Uni ist das nicht so,
das ist, das ist ein bisschen eine andere Nummer.
Ich würde gerne forschen, aber ich will nicht
deren Code durchsuchen
Aber das ist ideal, um zu sagen,
hier ist eine Firma, ihr gebt euch uns euren Google-Mail-reudigen Code da.
Und wir gucken den durch und sagen euch,
das ist kaputt und das ist gut.
Also die Industrie ist scharf darauf. Es gibt auch einige Leute,
die das schon benutzen, so wie es jetzt bei Open Source ist.
Also ich weiß, von einem bei Microsoft, der das einsetzt.
Ich weiß auch, dass es zum Beispiel noch eine nicht
so schöne, die Kehrseite dieser Forschung.
Ich weiß, dass das australische Verteidigungsministerium oder Verteidigungsministerium,
Abteilung Cyberdefense, diese Software auch einsetzt und schon verschiedene Bug-Reports
geschrieben hat
Weiß ich nicht, die veröffentlichen noch nicht selbstbewusst.
Die Frage ist, ob das Verteidigungsministerium in Australien
die Fehler findet, um sie zu stopfen.
Aber das weiß ich nicht. Und das ist nicht so schön,
ja. Er begründet sich ein bisschen auf eine Formulierung,
die sie von dem jetzt gab. Und zwar war das,
das seinen Schwachstellen zu finden, und dann wäre es schwierig.
Schwierig ist ja nicht unlöblich. Gibt es da Fotos?
Also ich kenne nichts aus dem Bereich der Schwachstellensuche.
Ich glaube aber, wenn man das unbedingt machen will,
müsste man mal in der Softwaretechnik schauen. Es ist ja so,
Wenn jemand so ein UML-Diagramm baut oder so ein,
was kann man noch bauen, so ein, na,
hier so ein Szenario-Ablauf mit so, wer könnte man natürlich fragen,
implementiert die Software das so, wie es in dem UML-Diagramm ist?
Das ist dann schon etwas dichter an dem Design.
Ja, aber sie haben ja gesagt, es ist schwer.
Also da muss man natürlich auch in Bereiche rein,
die vielleicht nicht mehr so angenehm sind.
Also ein anderes Beispiel wäre, sie haben eine textuelle Beschreibung
davon, was der Algorithmus tut. Also zum Beispiel,
sie haben RFC 2046 und das beschreibt TCP und jetzt ist
die Frage,
implementiert mein Betriebssystem TCP
Und das ist ja bis heute noch nicht geklärt.
Ob die Betriebssysteme TCP richtig implementieren. Aber theoretisch,
da müsste man meinem Gefühl nach, müsste man hin,
man müsste da hin, wo das Design beschrieben ist.
Ein Format weg des ONL, ja,
sagen wir mal, sehr, sehr praxisfrei ist.
Also ich habe das nach dem Studium...
Ich habe das nach dem Studium, keine Ahnung.
Also ich weiß, dass es UML gibt. Ich glaube auch,
dass das in der Softwareentwicklung ein wichtiges Werkzeug ist.
In meiner Forschung ist das nicht relevant.
Ich habe da sogar meine Vorlesung drüber gehalten
Äußerst ungern. Ja. Sehr gut. Ja. Wie
weit ist denn das mit dem automatischen Generieren von Anfragen?
Aber wenn ich weiß, wonach ich suche, kann ich auch keinen benutzen.
Weil dann kann ich es ja so einfach nur so, ist ja mir egal.
Aber untersucht mich zum Beispiel ein Programm, wo ich jetzt weiß,
das ist ein Fehler und das ist ein Fehler, dann die,
die mit Machine Learning zu gucken, wenn ich jetzt da neuen gut eingebe,
wie wahrscheinlich ist es, dass auch ein Fehler ist.
Ich generiere da auch eine Anweisung. Also erst mal zum ersten Teil der Frage,
wenn ich weiß, wonach ich suche,
kann ich es mit Krepp finden, würde ich sagen,
das ist schon mal falsch,
weil ich ja mit Krepp quasi Die Art der Anfragen,
die ich stellen kann, ist total eingeschränkt.
Also zum Beispiel, wenn ich suche, ich suche,
das von Count etwas in Memcopy reinfließt,
kriegen sie mit gerade nicht hin.
Also von daher, gut für uns. Zum zweiten Teil
der Frage, wie haben wir das mit dem Automatischen gemacht?
Wir haben das tatsächlich mit Machine Learning gemacht. Und zwar
haben wir so ein bisschen die, das Konzept der Anomalieerkennung verwendet.
Also wir haben uns immer sogenannte Source-Sink-Systeme,
oder wie sagt man auf Deutsch, Quellen, Quellen, Senkensysteme angeschaut.
Also da, wo Daten entstehen, da gibt es ja
gewisse Anzahl von Funktionen. Und es gibt Daten,
die lesen Funktionen oder wir kriegen Pointer rein und so.
Und dann haben wir die quasi gruppiert und haben uns geschaut,
was liegt denn so dazwischen
Und da haben wir quasi dann ein Modell der Normalität draufgebaut.
Also einfach gesagt, wenn einer Stringcat benutzt und Mellock,
dann liegt oft ein String Lang dazwischen.
Und dann haben wir die Traversals halt so gebaut,
dass diese Mitte verneint wird.
Also mit anderen Worten, da entsteht dann ein Muster,
was nach etwas sucht, was sehr selten auftritt.
Damit haben wir auch Schwachstellen gefunden, aber zum Beispiel nicht
in Linux. Ja, das ist halt die Frage,
gibt es diese Anomalien und sind das dann
auch Schwachstellen oder sind das nicht Schwachstellen
Also um das Beispiel mal zu konkreter zu machen,
wir haben zum Beispiel in VLC,
das ist ja so ein super toller Videoplayer, mehrere Schwachstellen gefunden.
Und die Entwickler ließen sich aber nicht davon überzeugen,
dass das Schwachstellen sind, haben gesagt, nee.
Und dann habe ich den Fabian gebeten, für eine Schwachstelle
mal zu zeigen, dass man es exploiten kann.
Hat auch geklappt. Die anderen haben sie uns trotzdem nicht geglaubt.
Und da muss man dann auch irgendwann sagen, ja,
keine Ahnung. Also vielleicht sind sie auch wirklich keine Schwachstellen.
Also das muss ich vielleicht auch nochmal sagen,
der Vortrag hat es natürlich bestmöglich verkauft, festzustellen,
ob ein Fehler eine Sicherheitsschwachstelle ist,
ist oft gar nicht so einfach
Also, dass es ein Fehler ist, ist relativ leicht festzustellen.
Und dass Sicherheit eine Rolle spielt, ist auch relativ leicht.
Aber ob der Angreifer das wirklich so ausnutzen kann,
dass er am Ende auf der Kiste da seine evil.exit starten kann.
Das ist schwierig zu sagen. Weitere Frau. Ja, weiterfallen.
Ja. In welche Richtung soll das bei dem Maschinencode gehen? So,
dann marschiert es doch erst nach Möglichkeit,
zu vielleicht mal ins System deinem Feldtest gematcht werden und dann denk ich auch bei Text dazu,
oder soll der Maschinencode direkt auf eine halbe Stunde aufbauen?
Das ist eine super Frage
Wir haben uns entschieden, wie wir das machen wollen,
aber ich bin mir nicht so sicher, ob das,
also man könnte dir Maschinencode decompilen, hängt ein bisschen davon ab,
was für ein Maschinencode das ist.
Und dann einfach das anwenden. Jetzt haben wir ausprobiert,
theoretisch geht's, aber was da rauskommt,
ist natürlich der hässlichste Code, den man sich vorstellen kann.
Von daher ist das, was da dann entstanden ist,
war nicht schön. Zur Zeit bauen wir einen Graf direkt
aus dem Maschinencode. Wir haben aber so eine Intermediate-Sprache,
also es gibt so beim Compiler, wenn man heute einen Compiler schreibt,
dann baut man den nicht mehr so direkt durch,
von C nach X86,
sondern man übersetzt C in eine Intermediate-Sprache
Die dann schon so aussieht wie Assembler.
Und dann gibt es einen, noch einen Compiler,
der quasi die Intermediate-Sprache in die jeweiligen Architekturen übersetzt.
Und das gibt es auch andersrum. Also wenn man Binärcode an
einen nativen Code analysiert, gibt es auch so Intermediate-Sprachen.
Und wir schauen uns jetzt easy an, falls das hier jemand kennt.
Ist eine mega hässliche Sprache, finde ich,
die also so ein bisschen wie Postskript ist,
falls hier mein Postskript kennt.
Also eine Stack-basierte Sprache, wo quasi alles mögliche immer auf
den Stack gepusht wird und dann die einzelnen Instruktionen
auch alle wieder poppen
Also man würde nicht schreiben, A plus B,
sondern immer schreiben A plus.
Und man weiß sofort, das andere liegt auf dem Stack.
Das liest sich nicht so leicht. Aber das kann man dann,
genau, jetzt muss ich ein bisschen ins Schwärmen kommen.
Kennt der noch jemand diese Reverse-Polish-Notation? Man kann diese Stack-basierten Sprachen
so transformieren, dass man sie dann ohne Klammern ausdrücken kann.
Oder? Ich glaube, das ist der Grund,
warum wir das bei ESI machen. Man kann dann diese ganzen Berechnungen,
wenn sie eben, wenn keine Schleifen dann sind,
kann man so ganze Blöcke zu so einem Ausdruck zusammenbauen.
Und den kann man dann emulieren. Und deswegen machen
die das
Das ist ja schön. Ich interessiere mich für die Abfragen auch.
Ja. Und wie erwartet das dann im Modalengebiet hinter steckt?
Und die zweite Frage ist, wobei jetzt Maschine...
Ja, eine super Frage. Also die zweite Frage kann ich gleich beantworten.
Machine Learning war da gar nicht drin, ne?
Also, wir nennen das Graph Mining, als Tarnung,
weil wir ja eigentlich immer sagen, dass wir Machine Learning benutzen.
Tatsächlich, dieses Paper hat eigentlich kein Machine Learning-Anteil.
Ja, also wenn man es ganz ehrlich ist.
Die anderen Papers, die da drum entstanden sind,
haben alle mit Machine Learning zu tun.
Aber ich fand jetzt für den Vortrag,
dass hier einfach Am besten, weil es am Kern der Sache ist.
Und es ist ja auch beim Lernen oft so,
wenn man erstmal alles gut vorbereitet hat und Pre-Processing und alles läuft,
dann ist das der entscheidende Schritt.
Also die Frage, kein Machine Learning. Zur Logik,
die Logik, die Modallogik, also die Logik steckt in dieser Sprache,
diese Sprache ist Turing vollständig.
Von daher kann man damit alles machen, was man will.
Hier sieht man so ein bisschen, also das ist jetzt
hier so ein ganz einfaches oder was einfach gewisse Anweisungen zusammenodert.
Das geht noch beliebig komplex, aber tatsächlich weiß ich nicht genau,
welche Funktionen da zur Verfügung stehen. Und eine richtige Abfragesprache,
wie man sie jetzt vielleicht aus den Datenbanken kennt,
die auch so ein theoretisches Grundgerüst hat.
Also was wie so ein relationales Modell oder so, ist hier nicht vorhanden.
Tatsächlich, das Modell ist der Lauf über den Graf. Ich weiß nicht,
ob das ein Modell ist, aber das ist quasi,
dass das Konzept und die Beschreibung dieser Läufe sind,
wenn man es jetzt abstrakt sagt, Touring-Maschinen.
Und also mega komplex. So, und einfacher,
es gibt so eine einfachen Sachen, das haben wir nicht benutzt.
Es gibt eine Sprache, die heißt Jetzt habe ich es vergessen.
Aber wer sich für Graf, also wenn man Graf-Datenbanken sucht,
findet man erst mal so einfache SQL angeleitete Sprachen,
die dann auch oft so eine ganz eigene Abfragelogik mitbringen.
Also wie man fragt, wie man gruppiert und so weiter.
So wie SQL, aber ein bisschen smarter. Haben wir
nicht gemacht. Ich habe auch da eine Frage. Ja,
das geht so ein bisschen auch tatsächlich auf das, was wir hier sehen.
Da steckt ja im Grunde genommen genau dieses Angreiferwissen drin. Also was hier programmiert wird,
ist ja, in dem Fall ist es zwar sozusagen eine Negativaussage,
die programmiert ist, aber grundsätzlich ist ja das How gewissermaßen,
um Angriffe zu finden, kodiert in solchen Kotschnipseln.
Und wenn ich mir jetzt vorstelle, dass das Open-Source-Projekt,
das du genannt hast, die Möglichkeit eröffnet,
solche Coach-Nipsel auch als Angreifer zu analysieren, dann kam ich natürlich,
wie das so oft ist, leider bei Detektoren.
Ich denke da so ein bisschen an die Varianten,
die mal vorher vielen Jahren so im Bereich der Medien,
Watermarking-Erkennung und so weiter da im Umlauf waren.
Man kann so einen Adaptivenangriff ja bauen, sodass man also versucht,
gerade so viel anders zu machen, dass die jeweiligen Detektoren nicht anschlagen.
Also gewissermaßen verändert, den man jetzt bewusst als Chartcoach unterschieben wollte,
genau so, geringfügig, dass er zwar tut,
was er sozusagen tun soll, im bösen Fall,
aber er tut eben nicht das, was erwartet wird von dem,
der diese Schnipsel programmiert hat.
Wäre eventuell so eine Umgehungsmöglichkeit, solche Erkennungstools für zum Beispiel Nachrichtendienste,
die ganz bewusst Fehler in Software verheimlichen wollen,
wäre eine Möglichkeit, durch solche Codeschnipsel Umgehungsaffacken, die Möglichkeit,
das leichter zu machen.
Selbstverhältnis. Ja, aber die... Ganz im Kern ist eine super Frage.
Ich fange mal mit was anderem an. Also eigentlich kann man immer,
wenn man eine Schwachstelle findet, sich fragen,
ist das ein Fehler oder ist das eine Hintertür?
Also kann man sich fragen, wenn man paranoid ist.
Aber manchmal muss man diese Frage stellen. Das heißt,
hat derjenige das mit Absicht programmiert oder nicht? So,
und wir sind in unserer Arbeit natürlich immer davon ausgegangen,
der Programmierer ist gut.
Damit ist deine Frage quasi beantwortet. Wir müssen uns nicht
darum kümmern
Von daher haben wir das nicht ignoriert,
aber jetzt könnte man natürlich theoretisch fragen, was wäre,
wenn der Programmierer böse ist?
Und tatsächlich ist das, was wir in Zukunft machen wollen,
auch die Suche nach Hintertüren.
Allerdings muss man da schon gleich, bevor man anfängt,
muss man eingestehen, dass man gewisse Arten von Hintertüren niemals finden werden kann.
Es gibt aber so einfache, es gibt ein Papier,
die führen sogenannte Authentication-By-Pass-Volumbilities ein.
Also Authentifikations-By-Pass-Schwachstellen. Und da ist ja schon klar,
also und oft sind das Schwachstellen,
wo es ein hardcodiertes Passwort gibt
Und da ist ja auch klar,
das ist eigentlich keine Schwachstelle, das ist eine Hintertür.
Und für so eine Schwachstelle könnte man wieder Dinger bauen,
aber so wie der Angreifer das natürlich weiß, beginnt dann so ein Katz-Maus-Spiel.
Und wenn der Angreifer schlau genug ist,
wird er den Punkt finden, also ich habe ja schon,
die Antwort ist ja klar.
Also wenn es Dinge gibt, die wir gar nicht sehen können,
dann würde ich als Angreifer als erstes erstmal dahin.
Aber es gibt auch noch viele andere ganz gemeine Sachen.
Zum Beispiel erzähle ich noch aus dem Nähkästchen. Ein Papier,
was es, glaube ich, in keine Konferenz geschafft hat.
Aber was ich für super halte,
die haben analysiert,
wenn man Maschinencode hat
Dann kann man ja an eine Stelle reinspringen und den ausführen.
Man kann aber auch an eine andere Stelle springen, extra kaputt,
schief, wo man eigentlich nicht hinspringen soll und gucken,
was man da ausführen kann.
Meistens führt das zu einem Absturz. Aber jetzt könnte
ein Angreifer sich ja quasi eine Software schreiben,
die von außen alles tut, was sie soll,
aber wenn man irgendeine Stelle schräg reinspringt, macht sie was ganz anderes.
Also quasi mehr Funktionscode. Und bei den Hackern gibt es das schon,
nicht so, aber ähnlich, es gibt sogenannte,
also Shellcode ist ein Teil von so einem Angriff,
der quasi eine Shell öffnet.
Und es gibt Shellcode,
der für verschiedene Prozessorarchitekturen funktioniert
Eigentlich nicht sein kann. Also wenn man jetzt Xx86 hat und Arm,
dann kann man ja nicht sagen, das funktioniert auf beiden Plattformen.
Aber es funktioniert auf beiden, weil das so geschickt am
Anfang gefriemelt ist, dass durch ein paar clevere Jumps,
der dann automatisch entweder in den Armen oder Xx86 Zweig springt.
Aber dieser Teil am Anfang, der ist halt,
wie soll man sagen, mehr Plattform, Code,
was nicht sein theoretisch oder, naja,
was jedenfalls sehr kompliziert und erstmal unwahrscheinlich ist.
Von daher, wenn der Angreifer böse mit uns ist,
dann kann er
ganz schlimme Sachen haben
Also, ich habe noch einen. Es gibt unser Gehen nicht,
das ist cool. Es kommt auch das Gehen aufs Umfeld.
Du kochst ihn nicht. Und da kann man Menschen mit
so einer Brillante von CTL auf den Abstrak-Center ziehen.
Und die haben die witzige Funktionalität noch,
dass man damit auch eine Code-Transformation beschreiben kann.
Was witzig ist. Also, was ich attraktiv finde,
das Problem ist, es ist relativ mühsam, diese Patches zu schreiben.
Unter anderem, weil die Logik ein bisschen unheimlich ist.
Und gibt es meinen Tag oder meinen Wunsch,
es gibt so ein Umfeld von Jörn,
ein vergleichbares Tool
Was, das war auch meine Hoffnung mit der Machine Learning-Geschichte,
das ist irgendwie,
dass man die Meinung Co-Transformationen zeigen kann und es waren ähnliche Vorschläge gemacht.
Was ist denn eine Transformation? Ja,
dass man aus Horst Cock, wie das Haus bebaut hat.
Ach so. Ich stelle mir vor,
dass man das in den Graf transformiert, verändert.
Ach so. Das haben wir da aber noch gar nicht drüber nachgedacht.
Nee, also das haben wir noch nicht gemacht.
Keine Ahnung. Also, dass man quasi das da reinschmeißt und
dann lässt man sich aus dem Graf wieder zur Scoot generieren
Also wenn man jetzt den Sintaxbaum betrachten würde,
würde wahrscheinlich, kommt ja der gleiche Code wieder raus.
Aber wenn man den Rest betrachtet, ist das,
glaube ich, eine sehr spannende Frage.
Da habe ich gar keine Idee. Das ist mein Wunsch.
Keine Ahnung, weiß ich nicht. Also muss man machen
. Gut. Wünsche oder Räume sind Wohlgefühle der Dinge,
die wir erreichen können? Da fangen Sie gleich an.
Wir sind jetzt, glaube ich, eine angekommen.
In diesem Sinne nochmal ganz vielen Dank für den Vortrag.
Ich bin das nächste Colocio ist nach meinem Kenntnisstand die Verabschiedung im Herz oder Richtig.
Also es findet dieses Semester Kreinkologium mehr statt.
Das war sozusagen der letzte Burtbank zu dem nächsten Semester dient.
Die Reihe noch vor, Semester beginnt, mit der Verabschiedung
vom Professor Wolfinger. Und da sind sie natürlich auch einiger.
Ich glaube, ganz herzlich eingeladen. Bis dahin. Föhn
nach Hause wegen