Sichere Software Quellcodeüberprüfung und sicheres Programmieren

Transkript

1 Sichere Software Quellcodeüberprüfung und sicheres Programmieren Thomas Biege

2 Agenda erster Teil: 10:00 Uhr 12:30 Uhr Pause: 12:30 Uhr 13:30 Uhr zweiter Teil: 13:30 Uhr??? Uhr

3 Überblick Ursachen: generelle Ursachen technische Probleme: C/C++, Perl, Java,... Kryptographie: kl. Einführung, Algorithmen, Angriffe praktische Beispiele: Buffer Overflow & Co. Abschluß: Step-by-Step Auditing, Zusammenfassung weitere Quellen: Werkzeuge, Papers, Bücher

4 Ursachen

5 generelle Ursachen technische Fehler logische Fehler administrative Fehler

6 Wo tauchen Fehler auf? an der Grenze von untersch. Privilegdomänen Netzwerk <> Server privilegiert <> unprivilegiert Internet <> Firmen-Netzwerk Dateneingaben sind benutzerkontrolliert fehlende Aufgabenteilung sendmail <> postfix Kombination von Nutz- mit Kontrolldaten

7 Software-Entwicklung fehlendes Wissen und Sensibilität kurze Entwicklungszyklen vs. Qualität Anzahl der Features vs. Qualität Resultat: zusätzliche Kosten durch Support, PR, Image-Verlust, Fehlerbehebung, etc.

8 Probleme: C/C++ und andere Programmiersprachen

9 Stolpersteine in C/C++ Speicherüberläufe Race-Conditions temp. Dateien Format-Strings *alloc() und free() Chroot-Umgebung Prozeßumgebung Benutzereingaben vertrauliche Daten offene Ressourcen 0,1,2 Zugriffsrechte Ressourcenbegrenzungen Signale Interval-Timer Terminal-Escape-Sequenzen Code-Verläufe API-Design dynamisches Linken

10 Die Speicherhöhle Stack und Heap Stack Grows down Heap Grows up

11 abstrakter Stack-Aufbau Parameter IP BP lokale Variablen

12 Was kann überlaufen? Variablen auf dem Stack Variablen auf dem Heap Integer-Variablen

13 Was kann modifiziert werden? Content Stack Heap Format free() Variableninhalte CPU-Register Function-Pointer jmp_buf-variable VPTR (nur C++) GOT _dtors atexit malloc debug hooks return into LibC Integer

14 Beispiel 1 (Speicherinhalte) /* that's our secret phrase */ char origpassword[12] = "Geheim\0"; char userpassword[12]; /* read user input */ gets(userpassword); if(strncmp(origpassword, userpassword, 12)!= 0) { printf("password doesn't match!\n"); exit(-1); } /* give user access to everything */

15 Beispiel 1 (Speicherinhalte) userpassword origpassword 0 11 userpassword origpassword 11

16 CPU-Register gesicherter Instruction Pointer (IP) Überschreiben des gesicherten IPs mit der Adresse des Maschinencodes RET restauriert den gesicherten IP CPU fährt mit der Ausführung bei fort Überschreiben des Base Pointers (BP) bei One-Byte- Speicherüberläufen

17 Beispiel 2 (Function-Pointer) long (* funcptr) () = atol(); /* ** der Angreifer platziert seinen Maschinencode irgendwo ** im Prozeßspeicher */ /* ** durch das Ausnutzen eines Speicherüberlaufes wird ** der Wert von (*funcptr) mit der Adresse des Maschinen- ** codes überschrieben */ /* ** Wenn der Function-Pointer benutzt wird, wird der ** Code des Angreifers ausgeführt. */ (*funcptr)(string);

18 Beispiel 3 (Integer-Überläufe) unsigned int uintamount; unsigned int uintsize; // uintgetvaluefromuser() gibt UINT_MAX zurück uintamount = uintgetvaluefromuser(); // Durch Multiplikation von uintamount mit einem Wert größer // als 1 erhalten wir einen Wert größer als UINT_MAX. // Bei dem Versuch, diesen Wert in eine unsigned int Variable // zu speichern, erfährt die Variable einen Überlauf. // Das Resultat ist somit kleiner als der tatsächlich berechnete // Wert. uintsize = uintamount * sizeof(struct mystructure); // malloc(3) alloziert somit einen zu kleinen Puffer mystructurearray[i] = malloc(uintsize);

19 Beispiel 4 (Vorzeichen) char Buffer[512]; short shortusersize; short shortbuffersize = sizeof(buffer); shortusersize = longgetvaluefromuser(); if(shortusersize > shortbuffersize) { fprintf(stderr, "Buffer too small!\n"); exit(-1); } /* Aufgrund eines sehr hohen Rückgabewertes von longgetvaluefromuser() ** wird shortusersize zu -1. Resultat: if-abfrage wird umgangen ** Funktionen wie malloc(3), memcpy(3) etc., die eine size_t- ** Variable benutzen, interpretieren den Wert -1 als einen positiven ** Wert (1024). Somit wird wieder ein zu kleiner Puffer bereitgestellt ** und ein Speicherüberlauf provoziert. */

20 Race-Conditions Time-of-Check vs. Time-of-Use Grund: nicht-atomare Operationen fehlendes Locking Wo: Dateisystem multithreaded Code Synchronisation von verteilten Databanken...

21 Beispiel 5 (Zugriffsprüfung) /* access(2) mit realer UID */ if(access("/home/evil_ed/rythmstick", W_OK) == 0) { /* Benutzer darf schreiben */ } /* open(2) mit effektiver UID */ if((fd = open("/home/evil_ed/rythmstick", O_WRONLY)) < 0) { fprintf(stderr, "Can not open File!\n"); exit(-1); }

22 Vermeiden von Race-Conditions im Dateisystem faccess(3) O_NOFOLLOW setuid(2) und setgid(2) (initgroups(3)) fork(2) chdir(2) + obere Verzeichnisstruktur prüfen niemals symbolische Dateinamen verwenden, besser Dateideskriptoren!

23 temporäre Dateien Verzeichnis für jedermann beschreibbar chmod +t /tmp /var/tmp (nicht vererbt) Race-Conditions Zugriffsrechte O_CREATE O_EXCL (Achtung: NFSv1/2) mkstemp(3) mkdtemp(3)

24 Format-String-Fehler zum ersten Mal im Jahr 2000 publiziert printf()-ähnliche Funktionen lesen: %p, %x,... schreiben: %n falsch: snprintf(buf, sizeof(buf), UntrustedUserDataBuffer); richtig: snprintf(buf, sizeof(buf), "%s", UntrustedUserDataBuffer);

25 free() free(3) mit benutzerdefiniertem Argument implementationsabhängig Kontrolldaten mit Nutzdaten doppeltverkettete Liste Resultat: Verändern von Speicherinhalten Block (intern) chunk Block (extern) mem prev_size size fd or data bk or data...

26 Chroot-Umgebung wechseln des Wurzelverzeichnisses auf Prozeßebene Schutz sicherheitsrelevanter Daten Device-Files/Gerätetreiber Privilegien (eigene Benutzer-IDs verwenden) offene Dateideskriptoren Netzwerk-API Verzeichnis-Links Zugriffsrechte /proc

27 Prozeß-Umgebung PATH IFS USER UID LD_PRELOAD (ignoriert bei setuid) LD_LIBRARY_PATH (ignoriert bei setuid)... und eine Menge mehr. niemals system(3) oder popen(3) benutzen (Shell!!!)

28 Filtern von Benutzereingaben Es sollten Positivlisten nicht Negativlisten benutzt werden: a-z, A-Z, 0-9 verringern der Angriffsfläche gewappnet sein für die Zukunft bspw. Dateinamen in C/C++, Perl, Shell,... bspw. includes in PHP bspw. Cross-Site-Scripting bei SQL, HTML,...

29 vertrauenswürdige Daten kein Swapping mlock(2) Speicher säubern memset(3) spez. Bitmuster Dateisystem säubern spez. Bitmuster keine Core-Dumps setrlimit(2) verschl. Daten nur bekannte und stark verbreitete Crypto. Lib.s Debugging vermeiden ptrace(2) SIGTRAP...

30 " offene Ressourcen privilegierter Prozeß startet unprivilegierten Prozeß alle Deskriptoren schließen Dateien Verzeichnisse (!!!) Sockets IPC fcntl(2)!!

31 0,1,2 Standard-Dateideskriptoren (stdin, stdout, stderr) nicht in neueren glibc-versionen, OpenBSD-Kernel, etc. while(fd < 2) { if( (fd = open("/dev/null", 0600)) < 0) return(-1); }

32 Zugriffsrechte So offen wie nötig, aber so geschlossen wie möglich. falsches Zahlensystem dezimal vs. oktal 660 anstatt 0660 umask(2) oft vergessen: IPC

33 Ressourcenbegrenzung Ressourcen begrenzen Denial-of-Service (DoS) vermeiden setrlimit(2) ulimit(1) wichtige Ressourcen Core-Dateigröße offene Dateideskriptoren max. Speichergröße max. Anzahl Benutzerprozesse

34 Signale asynchrone I/O Blockieren von Signalen vor kritischen Code- Abschnitten eigene Signal-Handler können gefährlich sein, wenn sie zur falschen Zeit ausgeführt werden Empfangen und Senden nur bei gleicher: User ID Session ID

35 Interval-Timer Interval Timer erzeugen Signale drei Arten von Timern: ITIMER_REAL ITIMER_VIRTUAL ITIMER_PROF werden vererbt sollten ignoriert werden getitimer(2) setitimer(2)

36 Terminal-Escape-Sequenzen /etc/termcap ANSI.SYS (altbekannte DOS ANSI-Bombe) interaktive Clients Mail-Clients Chat-Clients Web-Browser (textbasiert) etc. Übernahme der Terminal-Kontrolle Denial-of-Service Modifizieren von Informationen Kommandos ausführen vtxxx 0x00 0x1F 0x7F 0x9F

37 Code-Verläufe Timing Attack ursprünglich zum Analysieren von Krypto-Servern und embedded Systemen Zeitmessung zwischen verschiedenen Ausführungspfaden Bsp. Analyse von Authentifikationsmechanismen unterscheiden von gültigen und ungültigen Benutzerkonten keine Abkürzungen im Auth.-Code benutzen oder: zufällige Verzögerungen vor jeder Antwort

38 API-/Protokoll-Design Interface-Funktion Zugriffskontrolle für private Daten keine privaten Daten exportieren (Bibliothek) Eingaben nicht vertrauen Typ und Inhalt prüfen soviele operative Daten wie möglich intern halten Limits setzen je Verbindung/Aufrufer keine globalen Limits ( DoS) Zustand beibehalten Verteilen CPU-intensiver Operationen auf Clients Vermeiden von Denial-of-Service Attacken Vorsicht bei vertrauenswürdigen Daten

39 dynamisches Linken immer absolute Pfadnamen verwenden

40 Was ist mit Perl? keine low-level Angriffe temp. Dateien Perl-Kommandos mit Seiteneffekten Taint-Mode...

41 temp. Dateien eigenes Verzeichnis sysopen(): use Fcntl qw(o_rdwr O_CREAT O_EXCL); [...] sysopen(tmpfile, "/tmp/myfile.888", O_RDWR O_CREAT O_EXCL, 0600);

42 Seiteneffekte system() glob() exec() <> Backticks open() und spezielle Dateinamen eval() und \e 0x00 (Poison NUL Byte)

43 Taint-Mode Flag: -T Verzeichnisse werden geprüft externe Daten haben keinen Effekt ausserhalb des Codes Shell-Befehle Änderungen an: Dateien Verzeichnisse Prozesse perlsec(1)

44 Was ist mit Java? keine low-level Angriffe aus der Sandbox ausbrechen logische Fehler Race-Conditions Weitergabe von Informationen Modifikation von Informationen fehlende Eingabeprüfung schwache Zugriffsrechte schlechtes API-/Protokoll-Design Exceptions (ähnlich Signalen) Timing-Attacken...

45 praktische Beispiele

46 # ' " % 3 1. ( ntop popen(3) )( % & %! "$#! -,, * + )( % #! 2 # + 0/ 4

47 & " " / & ) ) ziptool fehlerhaftes strncat(3) (' %$ #! '. ) -, )+* (' & %$ # / '

48 Benutzereingaben - Format-String Fehler '&! % $ #"! & & ( )

49 &* ' % 0 3 '0 / '0 / ; Interprozeßkommunikation - Zugriffsrechte! $#!"! )( &' & % + ++-, & (*. )( , + : (*. )( +54

50 Dateizugriff - Race-Condition

51 $$ " "! " $ " ( ( Chroot-Umgebung offene Ressourcen $ '' &%!! # # # $43! ,/.,- *'! +* ) (! $ 6 5! $43! ,/.,- *'! +* ) (!, ' + % - + " $43 "!

52 Kryptographie

53 (Mini-)Einführung Kryptographie = griech. Geheimschrift Die Kunst/Wissenschaft der Informationstransformation zur sicheren Speicherung oder Übertragung. Ziele Vertrauen Integrität Authentizität... Algorithmen = mathematisch Protokolle = logisch

54 symmetrische Algorithmen Klartext Algorithmus unsicherer Kanal Algorithmus Klartext Chiffretext Chiffretext geheimer Schlüssel sicherer Kanal geheimer Schlüssel

55 asymmetrische Algorithmen Klartext Algorithmus unsicherer Kanal Algorithmus Klartext Chiffretext Chiffretext öffentlicher Schlüssel (für jederman zugänglich) geheimer/ privater Schlüssel

56 Verschlüsselungsmodi Electronic Code Block (ECB) jeder Klartextblock wird unabhängig verschl. Cipher Block Chaining (CBC) XOR des Klartextblocks mit dem vorangegangenen Chiffretextblock erster Block XOR zufälliger Initialisierungsvektor (IV) Output Feedback (OFB)... wiederholtes Verschl. eines Initialisierungswertes zum Erzeugen eines Schlüsselstroms (Stromchiffre) XOR des Klartextes mit dem Schlüsselstrom (s. One-Time- Pad)

57 Verschlüsselungsmodi: Probleme Electronic Code Block (ECB) Muster im Klartext bleiben erhalten (stat. Analyse) Blöcke können entfernt und ausgetauscht werden Cipher Block Chaining (CBC) Integrität kann nicht garantiert werden Wenn Klartext bekannt ist, können Blöcke ersetzt werden (auch von untersch. Nachrichten bei Verwendung des selben Schlüssels) Blöcke am Ende können entfernt werden Output Feedback (OFB) Integrität kann nicht garantiert werden Wenn Klartext bekannt ist, können Blöcke ersetzt werden Blöcke am Ende können entfernt werden

58 Angriffsmethoden Ciphertext-Only nur der Chiffretext ist vorhanden schwer, möglicherweise statistische Analyse Known Plaintext bekannt: Klartext und Chiffretext, gesucht: der Schlüssel additiver Wert bei Additive Stream Chiphers (OFB) kann eruiert werden Fehler im Algorithmus Chosen Plaintext Klartext unter Kontrolle ähnlich Known Plaintext, aber kraftvoller

59 Angriffsmethoden Chosen Chiphertext Es kann beliebiger Klartext in Chiffretext gewandelt werden und vice versa Fehler im Algorithmus Birthday Paradox doppelte Werte (Kollision) finden Wenn 23 Personen sich in einem Raum befinden, dann ist die Wahrscheinlichkeit 2 Personen mit dem selben Geburtstag zu finden höher als 50%. 64Bit-Zufallszahl: 2^64 =~ 2^(64/2) => weniger als die Hälfte bis zur Kollision! Meet-in-the-Middle ähnlich Birthday Paradox generieren der 2^(n/2) Werte vorab...

60 Bsp. Alarmanlage Sensor im Museum Monitor in Polizeistation Replay-Attacken Sensor schickt regelmäßig verschl. Alles OK - Nachricht an die Polizeiwache Einbrecher zapft die Telefonleitung an Alles OK -Nachricht wird aufgezeichnet die aufgezeichnete Nachricht wird während des Einbruchs wieder in die Telefonleitung eingespeist in der Polizeiwache wird die Nachricht entschl. Alles OK

61 Replay-Attacken vermeiden Integritätsprüfung (Hash) Zeitstempel Uhren können manipuliert werden Uhren können desynchronisieren Integer-Überläufe Y2K Bug Übertragungslatenz Zeitfenster (schlecht) Zähler (monoton steigend) Zustandshaltung (Paket doppelt?, n Pakete gelöscht?) wenigstens 64Bit groß Zufallszahlen interaktiv Birthday Paradox und Meet-in-the-Middle deswegen deutlich mehr als 64Bit groß

62 Abschluß

63 Was kann getan werden? einfache Regeln beachten KISS (keep it simple, stupid) Aufgaben-/Privilegienteilung... sichere API/Library benutzen Werkzeuge: Flaw-Scanner, Memory-Checker Source-Code-Audits Projektplanung: QA parallel zur Entwicklung versuchen am Ball zu bleiben oder: Experten engagieren Niemals eigene Krypto.-Verfahren benutzen!

64 Step-by-Step Auditing mit der Software vertraut machen installieren konfigurieren Dokumentation lesen Datenverarbeitung Wo werden Daten gelesen? Wo werden Daten geschrieben? Wie sind die Rechte verteilt? Wie arbeiten die Komponenten zusammen?

65 Step-by-Step Auditing Wie funktionieren die Kommunikationsprotokolle? Befehle Datenfluß Zustände Kryptographie Algorithmen Protokolle Schlüssellängen Betriebsmodus Quellcode untersuchen (logisch, technisch) o.g. Fragen klären Zeile für Zeile

66 Zusammenfassung Wir haben gesehen, dass Sicherheitslöcher sehr subtil und obskur sein können. Selbst Bug-Typen, die schon viele Jahre bekannt sind, verschwinden nicht. Weitere Fragen?

67 weitere Quellen: Werkzeuge, Papers, Bücher

68 Werkzeuge grep(1) Secure Programming Library Valgrind PScan FlawFinder RATS

69 weiterführende Literatur Thomas Biege; Security-specific Programming Errors (Part 1) D. Wheeler; Secure Programming for Linux and Unix HOWTO Peter Gutmann; Secure Deletion of Data from Magnetic and... Matt Bishop; Unix Security: Writing Secure Programs; SANS '96 perlsec(1) Man-Page Scut; Exploiting format string vulnerabilities Sebastian Krahmer; Execution Path Timing Analysis Viega, MCGraw; Building Secure Software; Addison-Wesley Cryptographic Compendium