Universität Hamburg CISAT Integration von sicherheitszentrierter statischer Analyse in den Enwicklungsprozess 14. DFN Cert Workshop 07.02.2007 D. Schreckling,, M. Johns, C. Beyerlein Fachbereich Informatik SVS Sicherheit in Verteilten Systemen
Agenda Hintergrund: Statische Analyse Motivation CISAT Einbindung in automatisierte Prozesse Live Demo Zusammenfassung D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 2
Motivation (I) Zwei Klassen von Ursachen für f r Sicherheitslücken: cken: Semantisch Problem wird von einem Fehler in der Programmlogik verursacht Beispiele: Mangelhafte Zugriffskontrolle Fehlerhafte Kryptoroutinen I.A. nicht automatisiert zu finden Syntaktisch Problem wird von einem Fehler im Programmcode verursacht Bespiele: Buffer Overflows, Formatstring Fehler Cross Site Scripting, SQL Injection Zum Teil automatisiert per Static Analysis zu finden D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 3
Beispiel Buffer Overflow #include <string.h> int main(int argc, char **argv){ char *buf[50]; // do some stuff... strcpy(buf, argv[1]); // do some more stuff... } return 0 D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 4
Motivation (II) Statische Analyse von Source Code Arbeitet auf Programm Code (Semi-)Automatisches finden von syntaktischen Fehlern, die zu Sicherheitslücken führen können Ansätze: API detection Kontroll-Fluss Analyse Daten-Fluss Analyse Neben kommerziellen Lösungen L existieren eine Reihe von freien Alternativen D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 5
Freie Tools Flawfinder: : API Detection RATS: API Detection ITS4: API Detection BOON: Buffer Overflow Fînder Mops: Race Conditions Splint: Verification light CQual: : Datenfluss Analyse / Formatstring Probleme D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 6
Motivation (III) Beobachtung: Es gibt eigentlich eine gute Auswahl an Werkzeugen und Ansätzen Diese freien Tools werden aber wenig eingesetzt... D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 7
Zögerliche Anwendung (I) Uneinheitliche Schnittstellen Aufruf Konventionen Flawfinder version 1.26, (C) 2001-2004 David A. Wheeler. Number Übergabewert: of dangerous Verzeichnis functions in oder C/C++ Files? ruleset: 158 Examining Konfiguration: example7.c Switches, Dateien oder Environment? example7.c:36: [4] (format) printf: $ cqual boon If format test.c -config strings /usr/local/share/cqual/lattice can be influenced by an attacker, taint1.c they $ mops -m chrtchdr.mfsa -t tmp/ -o out/ -- "gcc -o foo foo.c" taint1.c:1 can be exploited. Use a constant for the format POSSIBLE specification. VULNERABILITIES: ``getenv'' used but not defined taint1.c:2 Possibly example7.c:17: $ cqual a -config ``printf'' buffer [2] /usr/local/share/cqual/lattice overflow used (buffer) in but `x@main()': not defined char: taint1.c taint1.c:7 Statically-sized 10..10 incompatible bytes allocated, types arrays can 0..19 in assignment be overflowed. bytes used. *s: $tainted Perform bounds $ checking, splint <- siz(x@main()) $untainted taint1.c:1 +bounds use buf.c functions that limit length, or ensure that <- len(x@main()) $tainted <= *getenv_ret taint1.c:7 <= *s taint1.c:8 the size is larger than the maximum possible length. Ausgabe Format <= *t taint1.c:9 example7.c:24: [1] (buffer) <= *printf_arg1 strncpy: taint1.c:2 Easily Position used incorrectly; des Fehlers <= in $untainted doesn't Source Code always \0-terminate or check for invalid pointers. Risk is low because the source Zusatz Information (trace) is a constant string. example7.c:26: Bewertung[1] (buffer) strncpy: Easily used incorrectly; doesn't always \0-terminate or Schulungsaufwand, check for invalid pointers. erschwerter Umstieg und Evaluation D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 8
Zögerliche Anwendung (II) Enger Focus Die meisten freien Tools sind auf eine spezifische Fehlerart spezialisiert BOON: Buffer Overflows CQual: Formatstring Schwächen... Für einen vollständigen Schutz muss mehr als ein Tool eingesetzt werden Erhöhter Schulungsaufwand Erhöhter Aufwand im praktischen Einsatz D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 9
Zögerliche Anwendung (III) Ausgabeformat nicht maschinenlesbar Erschwert die Einbindung in automatisierbare Prozesse Versionen-Kontroll-Systeme IDEs Bugtracking-, troubleticket- und Reporting-Prozesse Wenn so eine Integration erstellt wurde, ist sie spezifisch für ein einziges Tool Nachträglicher Wechsel mit signifikanten Aufwand verbunden D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 10
Motivation (III) Beobachtung: Es gibt eigentlich eine gute Auswahl an Werkzeugen und Ansätzen Diese freien Tools werden aber wenig eingesetzt... Uneinheitlich Speziell Schwer zu integrieren Open Source Teufelskreis Nur aktiv genutzte Programme werden weiterentwickelt Nur Programme die aktiv weiterentwickelt werden, werden auch genutzt D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 11
CISAT Universität Hamburg Combination & Integration of Static Analysis Tools Fachbereich Informatik SVS Sicherheit in Verteilten Systemen
CISAT CISAT: Combination & Integration of Static Analysis Tools Sammlung von Werkzeugen, Methoden und Konventionen Ziele: Unterstützung des Einsatzes von statischer Analyse im Entwicklungsprozess Besondere Berücksichtigung automatischer Prozesse Belebung der Entwickler- und Nutzer-Community D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 13
CISAT: Einheitliche Schnittstellen (I) Ansatz Uniforme Aufrufsyntax Einheitliches Ausgabeformat Umsetzung Anpassung bestehender Werkzeuge über Wrapper (oder direkte source patches) Ergebnis Automatisches Setzen von default Optionen, die für möglichst ähnliches Verhalten sorgen Übersetzung des Tool-spezifischen Ausgabeformats in das einheitliche CISAT-XML Format Alle Werkzeuge verhalten sich gleich Investitionen in Schulung und Integration bleiben beim Wechsel des Werkzeuges erhalten D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 14
CISAT: Einheitliche Schnittstellen (II) XML-Format Maschinenlesbar, erweiterbar, verifizierbar, einfach in menschenlesbare Form zu bringen (z.b. XSLT) <?xml version="1.0"?> <scan-result xmlns="http://www.xyz.de/sectoolers/scan-result/0.9/"> <files>... </files> <problems> <problem> <toolname>cqual</toolname> <severity>1.0</severity> <probability>0.5</probability> <category>type</category> <location> <file>formatstring.c</file> <line>23</line> <field>*env</field> <text>incompatible types in assignment</text> </location> <trace>... </trace> </problem> <problem>... </problem>... </problems> </scan-result> D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 15
CISAT: Kombination von Werkzeugen SATEC: High Level API Kombination und Evaluation von Werkzeugen, die die definierte einheitliche Schnittstelle implementieren Z.B. Sammlung, Auswahl und Bewertung von Ergebnissen Implementiert ebenfalls: Die einheitliche Aufrufsyntax Das einheitliche Ausgabeformat In SATEC realisierte Kombinationen verhalten sich nach außen wie ein reguläres Werkzeug D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 16
Einsatz von CISAT Universität Hamburg Integration in Versionskontroll-Prozesse Fachbereich Informatik SVS Sicherheit in Verteilten Systemen
CISAT: Integration in Versionen-Kontroll-Systeme Warum integrieren wir CISAT in VCS? Verbreitetes Werkzeug in der Software-Entwicklung Zentraler Punkt in der verteilten Software-Entwicklung Funktionalitäten zur Verfolgung von Änderungen sind vorhanden Welcher Code wurde durch wen hinzugefügt? Wann wurde der Code geändert? Welcher Nutzer ist für welchen Code verantwortlich? Verbreitung von Software direkt aus VCS heraus Welches Problem sollten wir nun lösen? l Änderung können Verwundbarkeiten erzeugen Fehler in Projekten bleiben unentdeckt Coding Richtlinien meist unwirksam D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 18
Zielsetzung Ein Beispielszenario www.insecure.org www.student.de www.some-company.com www.just-for-fun.de C II S A T VCS Projekt Problem Report D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 19
Anforderungen an VCS Integration Transparenz Nutzer gewöhnen sich ungern an neue Software Umstrukturierung der Entwicklungsprozesse unerwünscht Einfache Integration Geringer bzw. kein Aufwand für Integration neuer Systeme Keine Veränderungen an Kernkomponenten Skalierbarkeit Nutzung verfügbarer Ressourcen zur Statischen Analyse Prüfung großer Projekte während fortlaufender Entwicklung D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 20
Struktur der Integration SARA Job Disposer UI UI VCS Worker D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 21
UI User Interface UI UI Erlaubt SARA Übliche Kommunikation mit VCS Extraktion von Prüfergebnissen Generische Integration Plugin für IDE VCS Job Disposer Einfache Erweiterungen von Kommandozeilen-Tools Worker D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 22
VCS Version Control System Speichert Prüfergebnisse UI UI Zugriff erfolgt über einfache API SARA Job Disposer Transparente Integration durch Hooks Nahezu in allen verbreiteten VCS enthalten Erfordern keine Modifikation von Kernkomponenten Interaktion mit Client bleibt unverändert ndert VCS Worker D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 23
SARA Static Analysis Result Administrator SARA Job Disposer UI UI SARA übernimmt Benachrichtigung von Nutzern Zugriff auf Prüfergebnisse VCS Entscheidung welche Projektteile Worker geprüft werden sollen D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 24
Job Diposer und Worker Job Disposer Vielseitig einsetzbarer Batch Processor UI UI SARA Übernimmt Prüfaufträge von SARA Verfügt über Ressourcen angemeldeter Worker Verteilt Aufträge auf Worker Worker Haben CISAT kompatible Statische Analyse Werkzeuge installiert VCS Führen eigentliche Statische Analyse durch Kommunizieren mit VCS Job Disposer Worker D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 25
Funktionsweise www.insecure.org www.student.de www.some-company.com www.just-for-fun.de C II S A T VCS Projekt Problem Report D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 26
Funktionsweise www.insecure.org www.some-company.com C II S A T VCS D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 27
Funktionsweise <?xml version="1.0"?> <job> <requires name="cisat"/> SARA SARA Job Job Disposer Disposer Job Job <task name="vcs:git:checkout" Report version="0.1"> <?xml <![CDATA[<checkout version="1.0"?> <worker repos="/git/projekt" id="446bb49f6e6b38fd40d27c45ec25baa0"> <property branch="master" name="cisat"/> <value commit="9a7f84f42038dabe0ebbc9336828a name="hd:space">9396224</value> />]]> <plugin name="vcs:git:checkout" version="0.1"></plugin> </task> <plugin name="vcs:git:commit" version="0.1"></plugin> <task <plugin name="boon" UI name="boon" version="0.1"> version="0.1"></plugin> </worker> <![CDATA[boon]]> UI </task> <task name="vcs:git:commit" version="0.1"> <![CDATA[<commit repos="/git/projekt" branch="results"> VCS VCS Worker Worker <file from="boon" Worker 1 to="master/9a7f84f42038dabe0ebbc9336828a/toller-job/boon"/> </commit>]]> </task> </job> Hook Hook Register Query D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 28
Probleme der Integration und weitere Forschung Verbesserung der Notifikations-Mechanismen Aktuell werden alle Entwickler über Vorhandensein von Verwundbarkeiten informiert Notifikation der Entwickler zu welchem Zeitpunkt über welches Problem? Nutzung der Historie eines Projektes Berücksichtigung inter-prozeduraler Analyse Annahme intra-prozeduraler Analyse-Werzeuge Inter-prozedurale Werkzeuge erfordern Sonderbehandlung Optimierung der Falsch Positiven Liste Markieren und Ausblenden bekannter Falsch Positiver Ändern des Status Falsch Positiver bei Code Änderungen? Und vieles mehr D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 29
Fazit der Integration in VCS Hohe Transparenz und einfache Integration Nutzung bestehender Infrastruktur Nutzung bestehender APIs Hohe Flexibilität Prüfmethoden können auf Projekte abgestimmt werden Anbindung beliebiger Statische Analyse Werkzeuge (sofern CISAT kompatibel) Neues Paradigma Prüfen von Software wird nicht explizit erzwungen Checks laufen implizit! Einbindung Statischer Analyse in Verteilte Open Source Entwicklung Zentral verwaltete Repositories D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 30
Live-Demo Demonstration der Integration in VCS IDE D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 31
Zusammenfassung der Ergebnisse CISAT bietet Einheitliche Schnittstellen Einheitliches XML-Ausgabe Format CISAT erlaubt Einsatz beliebiger Analyse Werkzeuge Kombination und Interpretation der Prüfergebnisse mehrerer Werkzeuge Direkte Integration in den Entwicklungsprozess CISAT erreicht Integration Statischer Analyse in den Entwicklungsprozess Wiederbelebung spezialisierter akademischer Tools CISAT ist CISAT ist Forschungsobjekt In der Entwicklung D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 32
Fragen Wir bedanken uns für f r Ihre Aufmerksamkeit! Fragen? D. Schreckling, M. Johns, C. Beyerlein, UH, FB Inf, SVS, 2007 33