Sichere Software. Sicheres Programmieren und Quellcodeanalyse. Thomas Biege

Transkript

1

2 Sichere Software Sicheres Programmieren und Quellcodeanalyse Thomas Biege

3 Überblick generelle Ursachen technische Ursachen: C/C++ Beispiele aus der Praxis kleine Einführung in die Kryptographie Verwendung von SSL/TLS

4 Ursachen

5 Klassifizierung technische Fehler logische Fehler administrative Fehler

6 Wo ergeben sich Sicherheitsprobleme? An der Grenze zwischen Privilegiendomänen Netzwerk vs. Server Benutzer vs. Applikation Internet vs. Firmennetz

7 Warum werden Fehler zu Problemen der Sicherheit? fehlende Aufgabenteilung: ein Prozess erledigt alle Aufgaben keine Trennung zwischen Kontroll- und Nutzdaten: Code-Segment und Daten- Segment, PPP, IP, TCP, usw.

8 Software-Entwicklung fehlendes Wissen und Sensibilität kurze Entwicklungszyklen vs. Qualität Features vs. Qualität keine Quality-Assurance-Abteilung

9 Resultat Image-Verlust erhöhte Kosten: Support, PR, Fehlerbehebung

10 Technische Ursachen C und C++

11 Stolpersteine Speicherüberläufe Wertebereichsüberläufe Race-Conditions temporäre Dateien Format-Bugs Dynamischer Speicher usw.

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

13 Abstrakter abstrakter Stack-Aufbau Parameter IP BP lokale Variablen

14 Was kann überlaufen? Stack-Speicher Variableninhalte (Zeiger, Integer,...) gesicherte Register Heap-Speicher Variableninhalte (Zeiger, Integer,...) Programmstrukturen (GOT, atexit,...) Integer-Variablen (Wertebereich)

15 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 */

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

17 CPU-Register gesicherter Instruction Pointer (IP) überschreiben mit Maschinencode RET restauriert den IP CPU führt Code des Angreifers aus gesicherter Base Pointer (BP) One-Byte Bufferoverflow

18 Function-Pointer 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);

19 Wertebereichsüberläufe unsigned + 1 unsigned signed Typenwandlung unsigned signed Typenwandlung unsigned

20 Race-Condition Time-of-Check vs. Time-of-Use Grund: nicht-atomare Operationen fehlendes Locking Wo: Dateisystem multithreaded Code Synchronisation verteilter Datenbanken Signale/Interval-Timer usw.

21 Vermeiden von Race- Conditions (Dateisystem) niemals symbolische Dateinamen, stattdessen Dateideskriptoren O_NOFOLLOW setuid(2), setgid(2), initgroups(3) fork(2) + Privilegien anpassen chdir(2) und obere Verzeichnisstruktur prüfen

22 temporäre Dateien Verzeichnis für jederman schreibbar chmod +t /tmp /var/tmp wird nicht vererbt Race-Conditions O_NOFOLLOW O_CREATE O_EXCL (Achtung: NFSv1,2) mkstemp(3) mktemp(1)

23 Format-Bugs zum ersten Mal im Jahr 2000 publiziert printf-ähnliche Funktionen lesen: %x, %p schreiben: %n falsch: snprintf(buf, sizeof(buf), user_data) richtig: snprintf(buf, sizeof(buf), %s, user_data)

24 Dynamischer Speicher free() free(3) mit benutzerdefin- Kontroll- und Nutzdaten iertem Argument doppelverkette Liste Kontrolldaten mit free(3) Nutzdaten oder Überlauf doppeltverkettete Liste implementierungsabhängig Resultat: Verändern von Resultat: Speicherinhalten Verändern von Speicherinhalten implementationsabhängig Block (intern) chunk Block (extern) mem prev_size size fd or data bk or data...

25 Filtern von Benutzereingaben Positivliste vs. Negativliste a-za-z0-9\s reicht oft aus Bsp.: Dateinamen in C, Perl, Shell Bsp.: Cross-Site-Scripting in SQL, HTML, LDAP und Terminal-Escape-Sequenzen...

26 Prozessumgebung Vor dem Ausführen externer Programme immer das Environment säubern. problematisch: PATH, IFS niemals vertrauen: USER, UID gefährlich: LD_PRELOAD, LD_LIBRARY_PATH niemals system(3) oder popen(3) verwenden

27 Zugriffsrechte So offen wie nötig, so restriktiv wie möglich. umask(2) falsches Zahlensystem dezimal vs. oktal 660 anstatt 0600 oft vergessen: IPC

28 sensible Daten kein Swapping: mlock(2) Speicher säubern: memset(3), spez. Bit-Muster Dateisystem säubern: spez. Bit-Muster keine Core-Dumps: setrlimit(3) Kryptographie Debugging vermeiden: ptrace(2), SIGTRAP

29 offene Ressourcen beim Starten von fremden Programmen alle Deskriptoren schließen Dateien Verzeichnisse! Sockets IPC fcntl(2) und Close-on-Exec Flag

30 Ressourcenbegrenzung systemweite Denial-of-Service Attacke vermeiden setrlimit(2) ulimit(1) wichtige Systemressourcen: Core-Dump Größe Anzahl offener Deskriptoren max. Speichergröße max. Anzahl Prozesse

31 Timing-Angriffe ursprünglich zur Analyse von Smart-Cards (Crypto- Prozessor) Zeitmessung von verschiedenen Ausführungspfaden sowie Berechnungen Bsp.: Prüfung von Authentifizierungs-Code vermeiden von Abkürzungen, konstante Berechnungen, zufällige Verzögerungen, keine datenabhängigen Berechnungen

32 API-/Protokolldesign Interface-Funktionen: private Daten schützen Eingaben nicht vertrauen: Typ und Inhalt prüfen Limits setzen: keine globalen Limits Zustandsautomat verteilen von CPU-intensiven Operationen auf Clients: Schutz vor DoS-Attacken

33 Beispiele aus der Praxis

34 ntop - popen(3) if(num == 0) putenv( QUERY_STRING=); sprintf(line, %s/cgi/%s, getenv( PWD ), cginame); if((fd = popen(line, r ) == NULL) {... cginame = ;/bin/rm -rf /

35 ziptool - strncat(3) switch(oper) { case MOUNT_DISK: strncpy(cmd, MOUNT_CMD, strlen(mount_cmd)+1); strncat(cmd, -t ext2, 9); strncat(cmd, dev, strlen(dev)+1); strncat(cmd,, 1);...

36 Benutzereingaben - Format-Bugs /* Check Password */ if(strncmp(su_pwd, user_input, strlen(su_pwd))!= 0) { /* Wrong Password */ sprintf(fmt_str, Wrong Password: %s\n, user_input); printf(fmt_str); exit(0); }

37 Zugriffsrechte - IPC /* creating shm */ if( (shm_id = shmget(0, stat_buf.st_size, S_IRWXU 654 IPC_CREAT IPC_EXCL)) < 0) err(-1, error: unable to create shm\n );... exit(0);

38 Die folgenden Fehler waren alle Teil einer realen Applikation und wurden Die roten Zeilen enthalten den Fehler, die grünen Zeilen sind die entsprec Integer-Overflow - smalltalk Korrektur. Blaue Abschnitte kennzeichnen den Teil, bei dem der Fehler se negative Auswirkung hat. Bsp. smalltak 2.1.8: [...] memset (crgb, 0, 256 * sizeof (unsigned int *)); for (a = 0; a < ncolors; a++) { char1 = colortable[a].string[0]; char1 = (unsigned char)colortable[a].string[0]; if (crgb[char1] == NULL) { crgb[char1] = (unsigned int *)... [...] Hier haben wir ein Vorzeichenproblem. Die Variable char1 ist vorzeichen vom Typ int (32 Bit). Die Variable colortable[a].string[0] besitzt Vorzeichen ist aber vom Typ char und deswegen nur 8 Bit groß. Das Prob offensichtlich. Da wir einen Wert der Größe 8 Bit einer Variablen mit der

39 Arrays und überschreiben evtl. vitale In Integer-Overflow - X11 Bsp. libxpm aus Xorg-X : [...] unsigned int i; int i; for (i = nbytes; --i >=0;) *dst++ = *src++; [...]

40 anders interpretiert wird als wir erwarten. In einigen Fällen wird der Teil sogar optimiert. Integer-Overflow - xpdf Also benutzen wir den Typ size_t, da er nicht vorzeichenbehaftet ist und zudem n auf allen Architekturen problemlos zu benutzen ist. (32 Bit vs. 64 Bit) Bsp. xpdf 2.02pl1: [...] size_t size; [...] if(size*sizeof(xrefentry)/sizeof(xrefentry)!= size) { error(-1, "Invalid 'size' inside xref table."); } ok = gfalse; errcode = errdamaged; #define SIZEOF_MYDATA 100 entries = (XRefEntry *)gmalloc(size * sizeof(xrefentry)); for (i = 0; i < size; ++i) { entries[i].offset = 0xffffffff; entries[i].used = gfalse; } [...]

41 Der Parameter ist nicht vom Typ size_t sondern vom Typ int, das Resultat ist als abermals ein Wertebereichsüberlauf. Zudem ist diese Implementierung nicht 6 tauglich. Integer-Overflow - Samba 1 Im Dezember 2004 wurde mehrere potentielle Integer Overflows im Samba-Cod behoben. Dafür wurden die Funktionen malloc(), realloc(), calloc() aus der glib eigenen Funktionen ersetzt, die das Ergebnis einer arithmetischen Operation v Allozieren des Speichers prüfen. Die folgende Funktion ist ein Ersatz für malloc(): void *malloc_array(size_t el_size, unsigned int count) { if (count >= MAX_ALLOC_SIZE/el_size) { return NULL; } #if defined(paranoid_malloc_checker) return malloc_(el_size*count); #else return malloc(el_size*count); #endif

42 Integer-Overflow - Die if-anweisung bricht ab, wenn der Wertebereich der Ergebnisvariablen über wird. Und natürlich sind wir paranoid und definieren PARANOID_MALLOC_C um den Codeblock return malloc_(el_size*count) zu aktivieren. Samba 2 Guckt man sich aber nun malloc_() genauer an, entdeckt man, dass die vorher Prüfung ausgehebelt wird, da eine weitere arithmetische Operation folgt (+ 1 somit wieder ein Integer Overflow stattfinden kann. void *malloc_(size_t size) { #undef malloc /* If we don't add an amount here the glibc memset seems to write one byte over. */ return malloc(size+16); } #define malloc(s) ERROR_DONT_USE_MALLOC_DIRECTLY Die Addition wurde nur eingefügt, damit Valgrind (ein Programm zum Auffind Speicherlecks und ähnlichem) diese Stelle nicht mehr bemängelt. Welch Ironie zeigt, dass ein Werkzeug alleine bei weitem nicht ausreicht, um Code zu überp

43 Kryptographie

44 Einführung Kryptographie = griech. Geheimschrift Ziele Vertrauen Integrität Authentizität mathematisch: Algorithmen logisch: Protokolle

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

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

47 Es besteht kein Grund in Panik zu verfallen, man sollte sich lediglich Gedanken um neue Standards machen. Hier ist das amerikanische NIST (National Institut of Standards and Technology) gefragt. Das NIST hatte 1997 bereits eine Ausschreibung gestartet, um einen Nachfolger für DES zu suchen. Der Nachfolger, der sog. Advanced Encryption Standard (AES), wurde durch den Algorithmus Rijndael gefunden. ( Hashes und Signaturen ()*&#$+%+%,-")".!"#$%&#$'!"#$%&#$' /"*$0 1.23%&'$4(* /"*$0 1.23%&'$4(* 5+**"2+,6&2+*' 7 5+**"2+,6&2+*'

48 Zufallszahlen - (P)RNG max. Entropie: Hmax = 1, wenn P = 0,5 +/- e, bei e = 0 Grundlage vieler Algorithmen und Protokolle Die meisten Unix-Systeme bieten /dev/random oder /dev/urandom an Qualität unbekannt, /dev/urandom u.u. MD5(0) nie PRNGs aus Software-Bibliotheken benutzen zur Not: EGADS oder EGD benutzen Counter-Mode + zufälliger IV read(2) anstatt fread(3) (kein Buffering)

49 TLS/SSL

50 Does and Donts SSL Version >= 3 bzw. TLS Bestimmte Algorithmen sind veraltet (DES) einige Schlüssellängen sind zu klein symmetrisch: n >= 128 Bit asymmetrisch: n >= 1024 Bit (RSA) Exportbeschränkungen deaktivieren privaten Schlüssel schützen

51 Does and Donts Ephemeral Keying = Perfect Forward Security (PFS) PRNG ausreichend initialisieren (wenigstens so viele Zufallbits wie Schlüsselbits, die generiert werden sollen) SSL-Session erneuern bei großen Datenmengen Verzeichnis mit CA-Certs nur von root schreibbar Zertifikate prüfen!

52 Abschluß

53 Was kann getan werden? Lehrgänge für Entwickler KISS = keep it simple stupid Privilegien-/Aufgabenteilung QA und Sicherheitsprüfung als Teil der Entwicklung Source-Code Audits externe Experten projektfremde Entwickler

54 Weitere Informationen

55 Fragen?