Quellcode Analyse

Hacker Contest Praktikum

Quellcodeanalyse

Betreuer: Dr. Martin Mink
Bearbeiter: Amir Neziri & Zoran Zaric
Wintersemester 2010/11

Einleitung - Motivation

 Unterstützung für Programmierer

 Codeduplikate vermeiden

 Analyse von sicherheits- und zeitkritischer Elemente

 Frühzeitige Fehlererkennung (Kostengründe)

 Analyse von Quellcode (White-Box-Testing)

14.12.2010 | Hacker Contest Praktikum - Quellcodeanalyse | Amir Neziri & Zoran Zaric 2

Inhalt

 Fehlerarten

 Methoden

 Code Obfuscation & Deobfuscation

 Analysetools:Auswhalkriterien

 Statische vs. Dynamische Analyse


Fehlerarten

 Buffer overflows

 Integer-overflows

 Formatstring-Angriffe

 Speicherlecks

 Input Validation
 SQL-Injectinos
 Exceptions
 Race Conditions


Fehlerarten – Integer Overflow

 Integer overflow (Ganzzahlüberlauf) tritt auf bei einer
arithmetischen Operation.
 Bei einer Bestimmung von Offset

 Bei einer Speicher-Allokation (Größe)

 Kopierung, Konkatenation, Gleichheit...

 Folgen
 Verfügbarkeit: durch Endlosschleifen

 Integrität: durch Datenmanipulation

 Zugriffskontrolle: Code kann ausgeführt werden

Fehlerarten – Integer Overflow

 Plattformen

 Sprachen: C, C++, Fortran, Assembler

 Betriebssysteme: alle

 Vermeiden von Integer Overflows

 Aufpassen beim Programmieren
 Jede Art von Indexkalkulation
 Jede Art von Berechnung einer Puffergröße

 C/C++ Programmierer sollten besonders aufpassen


Integer Overflow - Beispiel

 Codestück aus OpenSSH 3.3

 nresp=1073741824 und sizeof(char*) hat den Wert 4
 Ergebnis vom nresp*sizeof(char*) läuft über und Arg für
xmalloc() ist 0


Fehlerarten – Formatstring

 Angreifer kann das System zum Absturz bringen oder auch
Code ausführen
 Daten werden als String-Argumente übergeben in einer Funktion wie
sprintf(), FormatMessageW(), syslog() oder printf().

 Folgen
 Vertraulichkeit: ermöglicht die Offenlegung von Informationen
 Zugriffskontrolle: Code kann ausgeführt werden

 Plattformen
 Sprachen: C, C++, Assembler
 Betriebssysteme: alle


Formatstring - Beispiel

 Daten werden ohne Längenprüfung eingelesen


Formatstring – Beispiel(1)

 Korrektur: Bei *scanf() kann im FormatString bei den
FormatTags eine Größenbegrenzung eingestellt werden. Für
Strings geht das mit %<Größe>s.


Fehlerarten – Speicherlecks

 Speicherlecks (Memory leaks) enstehen , wenn ein Programm
dynamisch Speicher alloziert (malloc(), realloc(), ...)

 Alloziert Speicherressourcen werden nicht mehr an das System
zurückgegeben (z.B.: mittels free())
 Es steht nicht unendlich viel Speicher vom Heap dafür zur Verfügung

 Frage:Was ist aber mit Programmen, die
dauerhaft im Einsatz sein müssen?


Speicherlecks - Beispiel

..eine Weile wird es ohne Probleme laufen…


Methoden

 Dynamische Analyse

 Formale Analyse

 Statische Analyse


Methoden – Dynamische Analyse

 Dynamische Verfahren setzen die Ausführbarkeit der Software
voraus

 Sturkuturorientiert
 White-Box-Test
 Darstellungsformen: Kontrollgraph, Strukturdiagram

 Funktionsorientiert
 Tests gegen die Spezifikation
 Definition von Testdaten/ Testergebnissen

 Diverses
 Regressionstests, Leistungs- und Stresstestwerkzeuge


Dynamische Analysetools

 Open Source

 Valgrind

 Daikon

 Avalanche (basiert auf Valgrind)

 Kommerzielle Tools

 Coverity

 Insure++


Dynamische Analysetool -
Valgrind
 Framework zur Erstellung von dynamischen Analysetools

 Verfügbare Tools
 Speichermanagement
 Profiling
 Debugging

 Opensource-Projekt, GPL

 http://www.valgrind.org/

 Verfügbarkeit: X86/Linux, AMD64/Linux, ARM/Linux, PPC32/Linux,
PPC64/Linux, X86/Darwin and AMD64/Darwin (Mac OS X 10.5 and
10.6)


Dynamische Analysetool -
Valgrind
 Erkennt viele Speicherschwachstellen, die in C/C++ Code
gemacht werden

 Programm läuft im Prinzip in einer virtuellen Maschine

 Aufruf
 Normaler Aufruf: myprog arg1 arg2

 valgrind --leak-check=yes myprog arg1 arg2

 valgrind --tool=memcheck program_name


Valgrind - Demo Memcheck

 valgrind --tool=memcheck --leak-check=yes example5


Valgrind - Demo Invalid Points

 valgrind --tool=memcheck --leak-check=yes --track-
origins=yes ./example6


Valgrind – Demo Uninitialized
Variables

 valgrind --tool=memcheck --leak-check=yes --track-
origins=yes ./example7


Methoden – Formale Analyse

 Formale Analyse ist hilfsreich für den Nachweis der Richtigkeit
von Systemen wie z.B. kryptographische Protokolle

 Allgemein: Überprüfung der Konsistenz zwischen
Speziﬁkation und Realisierung mittels mathematischer
Mittel

 Anwendungsbereiche: Sicherheitsanalyse,
Zuverlässigkeitsanalyse, Verfügbarkeitsanalyse, Risikoanalyse

 Oft Programmiersprachen-unabhängig

 Modell checking


Methoden – Statische Analyse

 Statische Code Analyse ist ein statisches Software-
Testverfahren

 Zu testende Software muss nicht ausgeführt werden
 White-Box-Tests

 Dem Quellcode wird einer Reihe formaler Prüfungen unterzogen
 Ziel: Fehler finden und keine Veränderung/Verbesserung im
Quellcode

 Quellecodeanalyse durch Tools oder manuell (Zeitaufwändig)


Methoden – Statische Analyse

 Lint

 Heutige Programmierung oft Trial & Error

 Vor einigen Jahren noch unmöglich, da Rechenzeit zu teuer

 Lint: Check auf syntaktische Korrektheit


Statische Analysetools

 Java
 Jlint
 JavaScript: Jslint (Online oder mit Node.js)

 PHP
 php –l

 Ruby
 ruby -c

 Splint: Erkennen von C-Sicherheitslücken

 Python
 Pyflakes


Demo Pyfleks


Statische Analyse – Code Smells

 Code Smells sind Anzeichen für unsauberen Code. z.B.:

 Duplicate Code

 Dead Code

 Conditional Complexity

 Long Lines


Statische Analyse – Code Smells

 Tools
 Java
 Findbugs
 Konkatenierung von Strigs in Schleifen
 => Schlägt StringBuilder vor

 PHP
 PHP_CodeSniffer

 Python
 pyflakes


Demo - Findbugs


(Deo|O)bfuscation

 Um die Funktion von Code schwer verständlich zu machen wird
er künstlich unleserlich gemacht

 In der Regel zum verstecken / erschweren von reversen von
Malware
 krude Variablen- und Funktionsnamen
 Ausnutzung von wenig bekannte Sprachfeatures

 Methoden der Obfuscation
 Äquivalente Formeln und konstante Transformationen
 Umordnung von Anweisungen
 Varbiablensubstitution


(Deo|O)bfuscation

 Methoden der Obfuscation

 Bedingte Anweisungen und Sprünge

 Aufruf von Subroutinen

 Einfügen von Leercode

 Verschlüsselung

 Mischen von Funktionen

 Spalten von Variablen


(Deo|O)bfuscation

 Beispiel JavaScript Obfuscation

 document.body.write("Hello World!");

 document['body']['write']("Hello World");

 var b = 'body', w = 'write', olleh = "Hello", dlorw = "World";
document[b][w](olleh + ' ' + dlorw);


(Deo|O)bfuscation

 Deobfuscation durch Tools schwer
 Computer können Semantik von Funktionen und Variableninhalten
nicht erkennen

 Neuer Ansatz: Code deobfuscation by optimization
 27C3 in Berlin im Dezember 2010
 Branko Spasojevic


Demo Code Deobfuscation


Auswahlkriterien für Analysetools

 Anforderung: Die verwendete Programmiersprache muss
untertützt werden

 Arten von Schwachstellen, die erkannt werden sollen
 Für Webapplikationen (siehe OWASP Top-10)

 Läuft es mit Binären anstatt Quellcode Dateien?

 Kann es in IDEs integriert werden???

 Lizenz und Kosten für das Tool

 Genauigkeit: Wie hoch ist die „False-Positive-Rate“?

Statische vs. Dynamische Analyse

 Statische Analyse Vorteile

 Schwachstellen im Code können an der exakten Position gefunden
werden

 Es ist relativ schnell falls automatisierte Software benutzt werden

 Automatisierte Tools bieten Vorschläge an => reduziert Recherchen

 Ermöglicht es Schwachstellen sehr früh zu finden, schon während der
Entwicklungszeit => reduziert Kosten



 Statische Analyse Einschränkungen
 Zeitberaubend, falls es manuell durchgeführt wird

 Automatisierte Tools unterstützen nicht alle Programmiersprachen

 Automatisierte Tools berichten über falsche positive und falsche
negative Schwachstellen

 Automatisierte Tools sind genauso gut, wie die benutzten Regel zum
scannen

 Erkennung von Schwachstellen in der Laufzeitumgebung ist nicht
möglich



 Dynamische Analyse Vorteile

 Erkennt Schwachstellen in der Lauftzeitumgebung

 Erlaubt die Analyse von Programmen, für die keinen Codezugriff gibt

 Erkennt die Schwachstellen, die evtl. von der statischen Analyse als
falsche negative Schwachstellen gemeldet wurden

 Ermöglicht die Ergebnisse der statischen Code Analyse zu validieren

 Kann gegen jedes Programm angewendet werden



 Dynamische Analyse Einschränkungen

 Automatisierte Tools bieten ein falsches Gefühle der Sicherheit, dass
alles adressiert wurde

 Automatisierte Tools berichten über falsche positive und falsche
negative Schwachstellen

 Automatisierte Tools sind genauso gut, wie die benutzten Regel zum
scannen

 Sehr schwierig die Schwachstelle im Code bis zum Wurzel zu
lokalisieren => es dauert länger


Fragen??


Literatur

 http://www.owasp.org/index.php/Source_Code_Analysis_Tools
 http://www.owasp.org/index.php/Integer_overflow
 http://pi1.informatik.uni-
mannheim.de/filepool/teaching/sicherheit-
2006/ITS_20061121.pdf
 http://www.pst.informatik.uni-
muenchen.de/lehre/WS0405/mse/folien/D2-BlackWhite6p.pdf
 http://www.scribd.com/doc/28258786/Werkzeuge-Zur-Code-
Analyse-Presentation
 Hacking: Die Kunst des Exploits, Jon Erickson, ISBN-978-1-
59327-144-2
 http://www.cigital.com/papers/download/bsi5-static.pdf


Literatur

 http://www2.swc.toshiba.co.jp/en/tech/design.htm
 http://pi1.informatik.uni-
mannheim.de/filepool/teaching/sicherheit-
2006/ITS_20061121.pdf
 http://securitytube.net/Format-String-Vulnerabilities-Primer-
%28Part-1-The-Basics%29-video.aspx
 http://openbook.galileocomputing.de/c_von_a_bis_z/027_c_sic
heres_programmieren_002.htm
 http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwar
eengineering/testinstallation/articles/66899/
 http://www.owasp.org/index.php/Source_Code_Analysis_Tools
 http://gcn.com/Articles/2009/02/09/Static-vs-dynamic-code-
analysis.aspx


Literatur

 http://valgrind.org/
 http://cs.ecs.baylor.edu/~donahoo/tools/valgrind/
 http://www.securitytube.net/Profiling-Programs-for-Security-
Holes-with-Valgrind-video.aspx
 http://www.cprogramming.com/debugging/valgrind.html
 http://www.mit.edu/~6.170/tools/daikon.html#output
 http://groups.csail.mit.edu/pag/daikon/
 http://pypi.python.org/pypi/pyflakes
 http://findbugs.sourceforge.net/
 http://www.suse.de/~thomas/papers/SecProg/Sicherheitsreleva
nte%20Programmierfehler.pdf


Quellcode Analyse

Weitere ähnliche Inhalte

Andere mochten auch

Mehr von Amir Neziri

Quellcode Analyse