Jeder Abschnitt muss ausgefüllt werden. Qualität des Reviews geht mit in die Note des Reviewers ein! Review per Mail an schmitt@net.in.tum.de Titel Buffer Overflows Autor Christian Ferch Worum ging es in dem Paper? Hauptpunkte des Themas? Im Paper ging es um den Angriff auf Programme über eine Technik namens Buffer Overflow, bei der Schwächen der von-Neumann-Architektur und der C Calling Conventions ausgenutzt werden. Es wird die Problemstellung dargestellt, wieso Programme überhaupt auf diese Weise angreifbar sind sowie Beispiele wie auf diese Weise angreifbare Programme aussehen. Dabei werden auch mehrere Variationen der Buffer Overflows vorgestellt. Schließlich werden auch Techniken dargestellt mit denen man eigene sowie fremde Programme gegen Buffer Overflows absichern kann. Stärken der Ausarbeitung: Das Thema ist allein schon ziemlich interessant, die Einführung weckt das Interesse des Lesers die Zeit zu investieren das Paper zu lesen. Wie sich rausstellt, war es wert die Zeit zu investieren, da auch Leser mit grobem Verständnis von Buffer Overflows noch etwas neues aus dem Paper herausziehen können. Die Einführung in die Low-Level Speicherverwaltung in C ist verständlich und nachvollziehbar, so dass der Leser im groben schon mal weiß wie die Daten im Speicher angeordnet sind. Abbildung 1 klärt den Leser auf die so ein Overflow tatsächlich stattfindet, was ebenfalls nützlich ist um zu merken dass in C Speicher einfach ohne zu achten von anderen Daten überschrieben werden kann. Ein besonders gelungener Teil ist der Aufbau eines Shellcodes in Abschnitt 3.3, wo der Autor beschreibt wie ein Shellcode aufgebaut ist und auch eine Reihe von interessanten Tricks erklärt. Unter anderem wird erwähnt dass Speicher gespart werden muss, da die Shellcodes nicht beliebig lang sein dürfen und ebenso dass die Shellcodes keine NULL-Bytes enthalten dürfen - und wie man trotz dieser Einschränkungen funktionierenden Shellcode herausbekommt. Schwächen der Ausarbeitung: Um das Speicherlayout noch besser zu verstehen wäre es schön, wenn auch ein Bild mit den Daten-Segmenten sowie Stack, Heap etc. in der Ausarbeitung platz finden würde. Auch ist es manchmal kompliziert zu verstehen was jetzt im Stack "unten" und "oben" sowie "vorne" ist, so dass der Leser oftmal länger überlegen muss wo denn jetzt was liegt. Zudem wird leider Abbildung 2 nicht ausreichend erklärt, so ist nicht bekannt was *bar eigentlich ist, wozu der "Saved Frame Pointer" ist, sowieo woher die Rücksprungadresse jetzt genau kommt. Etwas mehr Details zu Stackframeswären wünschenswert. Fragen an den Autor (Offene Punkte, Fragen die sich beim Lesen gestellt haben): Gibt es Möglichkeiten Buffer Overflows in bereits bestehendem Code zu erkennen, so dass man schon vorher vorsorgen kann? Wie kann man die Adressen an denen der Shellcode liegt nun eigentlich vorhersehen? Wer realisiert Stack-Cookies? Der Compiler oder der Programmierer? Führt es zu einem Performancenachteil? Wie spielt Executable Space Protection mit JIT zusammen? Sachliche Korrektheit (zb. im Bezug auf die genannten Quellen) (mind. 1 Fehler finden!): Ringschluss: "[...] wie es möglich ist, mithilfe von Buffer Overflows beliebigen Code auf jedem Computer auszuführen, den man dazu bringen kann einen ausnutzbaren Buffer Overflow zu erzeugen" - wenn Buffer Overflow möglich, dann Buffer Overflow möglich. Logisch richtig, aber offensichtlich. Ringschluss: "Die Grundlegende Idee einer Buffer Overflow Attacke ist einen sogenannten Buffer Overflow auszunutzen", ebenfalls kein Informationsgehalt. Ungenau: "Der x86 stellt jedem Programm einen Stack zur Verfügung". Der x86 hat Befehle die auf Stack-Strukturen arbeiten, aber diese basieren auf dem Stackpointer und gelten für den gesamten Computer. Das OS kümmert sich darum, die Pointer umzustellen, so dass jeder Prozess (und Thread) seinen eigenen Stack bekommt. Falsch: "Jeder moderne Compiler stellt jedoch Versionen dieser Funktionen zur Verfügung, die Bounds Checking implementieren". Der Compiler geht nicht in den resultierenden Code ein, Funktionen wie strncpy() sind nicht Teil des Compilers sondern der libc. Sie sind nicht einmal besonders nahe verwandt, bsp. glibc und GCC die beide von verschiedenen Teams maintained werden. Form (Quellen, Bilder, Fußnoten, Rechtschreibung, Zeichensetzung, Grammatik etc.) Referenz ist die Vorlage von der Webseite: Es ist schade dass in den Beschreibungen der Stack Overflow-Arten nicht mehr Quellen im Text direkt verlinkt sind. So fällt es dem Leser schwer sich zu bestimmten Arten weiter zu informieren. Auch wirken viele Aussagen ohne Quelle ziemlich arbiträr, die Behauptung das x86 die verbreitetste Architektur scheint unwarscheinlich wenn man bedenkt in wie vielen Kleingeräten wie insbesondere Handys ARM-Prozessoren verbaut sind, da wäre eine Quellenangabe durchaus hinfreich um herauszufinden wie der Autor das gemeint hat. Abgesehen von vielen fehlenden Bindestrichen und den in einem ersten Entwurf zu erwartenden Tippfehlern ist die Form ansonsten in Ordnung. (Rechtschreibung und Zeichensetzung in der Ausarbeitung korrigieren und direkt an den Autor zurückgeben)