Software Engineering Informatik. Grundlagen der Statischen Analyse und ihre Werkzeuge

Transkript

1 Grundlagen der Statischen Analyse und ihre Werkzeuge

2 Übersicht 1. Statische Analyse Allgemein 2. Grundlagen 3. Abstrakte Interpretation 4. Werkzeuge der Statischen Analyse 5. Zusammenfassung 2

3 Sichere Software Erkennung und Beseitigung von Sicherheitslücken Ist es möglich Schwachstellen im Programmcode zu erkennen? Was kann von einem Angreifer ausgenutzt werden? Wie kann es von einem Angreifer ausgenutzt werden? 3

4 Zwei Schritte eines Angriffs Der Angreifer ändert den Programmablauf Durch Buffer-Overflow: Überschreiben der Rücksprungadresse auf dem Stack Der Angreifer nutzt diese Änderung um beliebigen Code auszuführen Durch Buffer-Overflow: Code auf den Stack schleusen Wie können wir das verhindern? Mithilfe der Statischen Analyse 4

5 Statische Analyse Berechnung von Eigenschaften eines Programms ohne es auszuführen Alle möglichen Eingaben Alle möglichen Zustände Aber: Satz von Rice besagt, dass es unmöglich ist eine beliebige nicht triviale Eigenschaft eines Programms bzw. einer Turing Maschine, algorithmisch zu entscheiden Also: Nicht jeder konkret mögliche Zustand wird mit einer Eingabe einzeln getestet, stattdessen Approximationsverfahren 5

6 Statische Analyse in der Praxis Anwendungsgebiete Automatische Optimierung des Programmcodes Verifizierung des Programms (gewollte Eigenschaften, keine Laufzeitfehler, geschützt gegen Angriffe) Ziele Fehler so früh wie möglich auffinden (während der Entwicklung) Verhindern von Abstürzen zur Laufzeit Programm besser verstehen 6

7 Abstrakte Interpretation Interpretiert das Programm unter simpleren Bedingungen Dazu werden Abstract Domains genutzt abstrahiert die konkreten Informationen so, dass nur die für wichtige empfundenen Informationen erhalten bleiben Repräsentiert eine Menge von echten Zuständen(Concrete Domain) Erzeugt eine Über-Approximation der Concrete Domain Bei der Wahl der Abstract Domain ist zu beachten, wichtige Faktoren nicht außer acht zu lassen, sonst entstehen Falschaussagen Ziel: Soviel wie möglich über die Zusammenhänge erfahren, aber dabei so wenig wie möglich berechnen à Konflikt zwischen Präzision und Geschwindigkeit Also: Abstract Domain Vereinfachung der Concrete Domain 7

8 Beispiel Abstrakte Interpretation Um welchen Rückgabewert handelt es sich? 5 lässt sich zu int abstrahieren Der Rückgabewert muss also dem Typ der Summe entsprechen, der durch die Operation int + int entsteht à Der Rückgabewert ist also vom Typ int public int im_concrete() { result = 5 + 5; } public int im_abstract() { result = int + int; } 8

9 Concretezation Elemente der Abstract Domain repräsentieren eine Menge von echten Zuständen Concretization Function(γ) gibt den Zusammenhang zwischen den abstrakten Zuständen γ und den konkreten Zuständen wieder 9

10 Beispiel Concretezation Beispiel Abstract Domain: [36,39] à Concrete Domain: γ([36,39]) = {36,37,38,39} Abstrakter Zustand: = a [36,39], b [40,41] à Konkrete Zustände: γ( ) = { a 36,b 40, a 36,b 41,..., a 39,b 40, a 39,b 41 } Würde ein Programm jetzt die Operation a = 2 b; ausführen ergäbe das: = a [80,82], b [40,41], da 2 [40,41] = [80,82] à = à Echte Obermenge γ( ) kann nur { a 80, b 40, a 82, b 41 } produzieren à Über-Approximation ", ", ", ", ", ", ", ", ", ", ", " 10

11 Joining von abstrakten Zuständen Konvergieren mehrere abstrakte Zustände wird durch Joining ein neuer abstrakter Zustand gewonnen Beispiel : = a [36,39], b [40,41] True: a [80,82], b [40,41] False: a [36,37], b [40,41] if (a >= 38) a = 2 * b; /* join point */ à a [36,82], b [40,41] 11

12 Zwei Approximationsverfahren Run in the aggregate Endlich große Menge von Deskriptoren (Abstract Domain) beschreibt Gruppe von Zuständen Programmanweisungen werden in linearer Abfolge ausgeführt Run in a non-standard fashion Führt isoliert Programmteile der Anwendung aus Durch zusammenfassen aller Programmteile, sollen alle Zustände der Anwendung erfasst werden, also keine lineare abfolge 12

13 (1) Beispiel Fehler wird erkannt Analyse rechnet im Zweierkomplement à Modulare Arithmetik springt bei x = 2^32 wieder auf 0 und damit ist der If-Block ausführbar à Gefahr wird korrekterweise erkannt unsigned int x = 1 << 31; if (trigger) x = 2*x; if (x == 0) { // Do something malicious } 13

14 (1) Beispiel Fehler wird erkannt Fehler- Zustände- Erreichbare- Zustände- Zustandsuniversum- Fehler Zustände überlappen mit erreichbaren Zuständen, also existiert eine Schwachstelle Analyse erkennt Schwachstelle, da Über-Approximation echte Obermenge von erreichbare Zustände bzw. erreichbare Zustände echte Teilmenge von Über-Approximation à Abstract Domain korrekt bestimmt 14

15 (2) Beispiel Fehler wird nicht erkannt Analyse rechnet im Bereich der unendlichen Integer Arithmetik à If-Block ist nicht ausführbar à Gefahr wird fälschlicherweise nicht erkannt unsigned int x = 1 << 31; if (trigger) x = 2*x; if (x == 0) { // Do something malicious } 15

16 (2) Beispiel Fehler wird nicht erkannt Fehler- Zustände- Erreichbare- Zustände- Zustandsuniversum- Fehler Zustände überlappen mit erreichbaren Zuständen, also existiert eine Schwachstelle Analyse erkennt Schwachstelle nicht, da keine Über-Approximation à Abstract Domain falsch bestimmt 16

17 Beispiel Genauigkeit Abstraktion kann an Genauigkeit verlieren Beispiel: Abstract Domain z.b. pos, neg Variable a := positiv Variable b := positiv à Else-Block der Bedingung erreichbar, obwohl die Zuweisung b = a dies unmöglich macht à False-Positiv public void falsepositiv(int a) { a = abs(a); int b = a; if (a <= b) { // Do something good } else { // Do something malicious // irrelevant, da // nicht erreichbar } } 17

18 Beispiel Genauigkeit Fehler- Zustände- Erreichbare- Zustände- Zustandsuniversum- Fehler Zustände überlappen nicht mit erreichbaren Zuständen, also existiert keine Schwachstelle Analyse erkennt aber fälschlicherweise eine Schwachstelle, da Über-Approximation und Fehler Zustände überlappen à Abstract Domain korrekt bestimmt. Aber: Weitere manuelle oder automatische Analysen notwendig 18

19 Vollständige / unvollständige Analyse Vollständige Analyse Eine bestimmte Art von Sicherheitslücken ist nicht vorhanden Keine falsch negativ Ergebnisse Nachteil: Komplex und rechenitensiv Unvollständige Analyse Findet Schwachstellen schnell und einfach Nachteil: falsch positiv und falsch negativ möglich 19

20 Vergleich zur Laufzeitanalyse Laufzeit Eine konkrete Eingabe wird ausgewählt Abfolge der Zustände dieser Eingabe wird untersucht Mehrere Analysen für mehrere konkrete Eingaben Statisch Eine abstrakte Eingabe wird ausgewählt Menge der Zustände durch abstrakte Eingabe wird untersucht Wird nur einmal ausgeführt 20

21 Datenflussanalyse Statische Code Analyse Abhängigkeiten eines Programms werden wiedergegeben Zwei Arten der Analyse 1. Vorwärtsanalyse: Nutzt Kontrollflussgraphen, um den Programmcode zu untersuchen 2. Rückwärtsanalyse: Nutzt umgekehrten Kontrollflussgraphen, um den Programmcode zu untersuchen Änderungen der Daten beim Passieren eines bestimmten Programmteils werden deutlich 21

22 Kontrollflussgraph / Controle Flow Graph (CFG) Enthält einen Knoten(Block) je Programmanweisung Kanten zwischen zwei Knoten v1 und v2 stellen möglichen Kontrollfluss von v1 nach v2 dar Anweisungen mit Bedingungen werden entsprechend beschriftet und stellen eine Verzweigung dar Zwei spezielle Knoten enter und exit markieren Ein- und Austritt einer Prozedur 22

23 CFG Beispiel class EineKlasse { private int x; public static void do(boolean bol) { EineKlasse obj = new EineKlasse(); obj.x = 50; if (bol) { obj.x = 100; } } System.out.println(obj); } 23

24 Abstrakte Interpretation mit CFG Abstrakte Interpretation durch CFG der Funktion Reihenfolge wird beachtet daher Kontrollfluss-sensitiv Verfahren genannt Vorgehensweise: 1. Liste mit zu bearbeitenden Knoten erstellen (Anfang: enter Knoten) 2. Nächstes bzw. erstes Element aus Liste nehmen 3. Knoten durch Berechnung simuliert (durch sog. Abstract Transformers) und abstrakten Zustand weitergegeben zum nächsten Knote und mögliche Zustände als Element der Abstract Domain notieren 4. Unterscheidet sich dieser Zustand von einem vorherigen(z.b. Schleife) dann muss Knoten wieder in Liste, ansonsten entfernen 5. Nachfolger ermitteln (ausgehende Kanten) und in Arbeitsliste packen 6. Wiederholen bis Arbeitsliste leer 24

25 Interprozeduraler Kontrollflussgraph / Interprocedural Controle Flow Graph (ICFG) Erweiterung des CFG, um Abhängigkeiten zwischen den Funktionen in einem Programm darzustellen Jede Aufruf einer Prozedur wird im ICFG mit einem call und einem returnsite Knoten ausgedrückt Call-Kanten sind die Verbindung von call Knoten und enter Knoten. Return-Kanten sind die Verbindung von exit Knoten und return-site Knoten 25

26 ICFG Beispiel 26

27 Kontextsensitive Analyse mit ICFG Ähnlich Kontrollflusssensitive Analyse nur Abstract Transformers zwischen call und return-site Knoten Beziehung zwischen formalen und übergebenen Parametern an die Funktion werden dadurch deutlich 27

28 Boolean Programme Ein ganz normales Programm(z.B. C-Programm), dass allerdings nur den Datentyp Boolean verwendet Endlich viele Funktionen ohne Parameter Endlich viele globale und lokale Variablen Codierung in Kellerautomaten möglich 28

29 Kellerautomat / Pushdown Systeme (PDS) Erweiterung des endlichen Automaten um einen Stack Stack wird zur Auswertung relevanter Informationen genutzt Übergang in einen anderen Zustand abhängig vom obersten Kellersymbol Zwei Optionen 1. Etwas auf den Keller legen (PUSH) 2. Oberstes Kellersymbol aus dem Keller nehmen bzw. abarbeiten (POP) Zustandswechsel auch ohne Eingabesymbol möglich Umwandelbar in kontextfreie Grammatik 29

30 Zusammenfassung Um Sicherheitslücken zu finden, müssen wir das Programm verstehen Grundkonzepte der Statische Analyse Abstrakte Interpretation: Concrete und Abstract Domains Konflikt zwischen Genauigkeit und Zeit Falschaussagen möglich Werkzeuge nötig wie z.b. der Kontrollflussgraph 30