12.5 Sicherer Programmcode

Transkript

1 12.5 Sicherer Programmcode Typische Beispiele für unsicheren Code: Pufferüberlauf ungeschützte kritische Abschnitte (im Englischen: software vulnerabilities) SS-12 1

2 Pufferüberlauf ausschließen! Das Problem (2.5 ): Unsichere Programmiersprachen (wie C, C++,...) lassen zu, dass beim Beschreiben eines Feldes jenseits der Feldgrenzen geschrieben wird. Die Effekte solcher Programmfehler sind zunächst nicht definiert - üblicherweise werden benachbarte Daten in Mitleidenschaft gezogen. SS-12 2

3 Angreifer können solche Programmfehler ausnutzen, wenn Eingabedaten direkt oder indirekt in gefährdete Felder fließen: mit gezielt gewählten Eingabedaten können Sicherheitsverletzungen bewirkt werden. Mehr als die Hälfte aller Sicherheitswarnungen des CERT* betreffen Angriffe, die mit Pufferüberlauf arbeiten! Der Schaden: Gezieltes Einschleusen von Daten in andere Variable - oder gar Einschleusen von eigenem Code. Voraussetzung: Kenntnis des Codes (und des Übersetzers) (but remember: no security by obscurity!) SS-12 3 * Computer Emergency Response Team

4 Die Lösung: am besten: am zweitbesten: sonst: nur sichere Programmiersprachen benutzen (Notbehelf: Keller-Manipulation entdecken: 2.5, so auch mit MS Visual C++ /GS *) Felder, insbesondere Zeichenketten, nur mit sicheren Bibliotheksfunktionen bearbeiten extreme Vorsicht, extensive Code Reviews, werkzeuggestützte Code-Analyse Literatur: M. Howard, D. LeBlanc: Writing Secure Code. Microsoft Press 2003 * Compiler option /GS: SS-12 4

5 Angriffs-Varianten gezielte Änderung einer benachbarten Variablen (zur Erinnerung: Aufgabe 2.2) Zerstörung der Keller-Organisation (Rücksprungadresse!) und damit Abschießen eines Servers ( denial of service) (2.5 ) gezielte Einschleusung von eigenem Code, der durch gezielte Manipulation der Rücksprungadresse im Keller aktiviert wird Mutation eines Servers oder SUID-Programms zum Schadprogramm (d.i. raffiniertere Variante von 2.5 ) ähnliches auf der Halde (erheblich schwieriger) SS-12 5

6 Vorsicht beim Kopieren von Zeichenketten! gets, fgets (2.5 ) string, strcasecmp, strncasecmp, strcat, strncat, strlcat, strchr, strrchr, strcmp, strncmp, strcpy, strncpy, strlcpy, strcspn, strspn, strdup, strlen, strpbrk, strstr, strtok, strtok_r printf, fprintf, sprintf, snprintf (Windows:) StringCchCopy, StringCchCat,... count characters (!) SS-12 6

7 Vorsicht mit Unicode-Zeichen: 1 Zeichen = 2 Bytes! (vgl. Aufgabe 5.2) // WCHAR = wide character = Unicode character WCHAR src[] = "To be or not to be"; WCHAR dest[16]; // 32 bytes... StringCchCopyW(dest,sizeof(dest),src); 32! kopiert maximal 32 Unicode-Zeichen, nicht nur 16! Merkregel: Makro verwenden #define Length(x) = sizeof(x)/sizeof(x[0])... StringCchCopyW(dest,Length(dest),src); SS-12 7

8 Verwandtes Problem: printf... bedingt durch drei Schwächen des Formatierers von C/C++ : printf("... %s... %i... %n...", string, number, &count); speichere Anzahl bisher verarbeiteter Zeichen übernimm Zeichenkette bzw. Ganzzahl Variable Parameterliste ohne Längenüberprüfung! printf greift ins Leere - d.h. irgendwo in den Keller -, wenn weniger Argumente als vom Formatierer gewünscht printf(string); ist erlaubt (Konsequenz von ) SS-12 8

9 printf("%s", argv[1]); ist in Ordnung printf(argv[1]); ist Schwachstelle! (entsprechend auch, wenn das Argument über Umwegen aus der Eingabe kommt) Strategie des Angreifers: langen Formatierer eingeben, der wie folgt konstruiert ist: an geeigneter Stelle ist ein %n enthalten an geeigneter Stelle ist die Adresse einer Zelle enthalten, auf die sich das %n beziehen soll vor dem %n wird mit hinreichend vielen % gesteuert, welcher Wert in diese Zelle gelangen soll Damit prinzipiell jede Umwandlung zum Schadprogramm möglich SS-12 9

10 Der Trick dabei: Der Formatierer wird von printf abgearbeitet; dabei wird für die vielen % auf den Keller zugegriffen und damit auch auf den Formatierer selbst und damit werden Teile von ihm als Argumente interpretiert und damit wird die Adresse für das %n untergeschoben:... %x %x %x %n \xc0\x2a\xf5\x01 angewandt auf (ohne Leerzeichen)... %x%x %x%n \xc0\x2a\xf5\x01 Ausgabe: e25?*? Knifflig: richtig beginnen mit... SS-12 10

11 Verwendung sicherer Bibliotheksfunktionen Typ string in der Standard Template Library von C++: #include <string> using namespace std; int main() { string s;... ähnlich dem String in Java (aber Werttyp, nicht Verweistyp) StringCchCopy, StringCchCat,... sind etwas sicherer als gets, strcpy,... SS-12 11

12 Eingaben vollständig überprüfen! Spezifikation (!): Präzise spezifizieren, welche Eingaben erlaubt sind! Korrekte Implementierung: Alle nicht erlaubten Eingaben sofort zurückweisen! SS-12 12

13 Werkzeuggestützte Code-Analyse Mustererkennung (etwas besser als mit grep strcpy) J. Viega et al.: ITS4: A Static Vulnerability Scanner for... [2000] integer range constraints D. Wagner et al.: A First Step towards Automated Detection... [2000] Erweiterung von LCLint: semantisch annotierte Bibliotheksfunktionen D. Larochelle et al.: Statically Detecting Likely Buffer Overflow... [2001] Erweiterung des Übersetzers: Regelmenge zur Code-Prüfung K. Ashcraft et al.: Using Programmer-Written Compiler Extensions... zur [2002] Beachte: Weder schließen diese Ansätze Fehlalarme aus noch entdecken sie alle Fehler! SS-12 13

14 Vorsicht mit kritischen Abschnitten! Gefahr: Programmierer geht irrigerweise davon aus, dass während der Ausführung seines Programms keine Änderungen in der Umgebung stattfinden - z.b. im Dateisystem. Angreifer nutzt dies aus. Szenario: Programm Angreifer prüfe Datei x bearbeite x ändere x SS-12 14

15 if(!access(file,w_ok) ) { // write access ok // gap for attack is here int fd = open(file,o_wronly,0); write(fd,text,sizeof(text)); printf("written alright\n"); } else printf("no write access\n"); Wo könnte dieser Code stehen? "TOCTOU" : time of check - time of use In einem setuid-programm von root, das in eine vom Aufrufer übergebene Datei schreibt. Um nicht aus Versehen in eine für den Aufrufer nicht schreibbare Datei zu schreiben - denn root kann überallhin schreiben! - wird zuvor geprüft, ob der Aufrufer das Schreibrecht hat (access legt die real UID zugrunde!). [! Professionell wäre, die EUID umzusetzen anstatt access zu verwenden!] SS-12 15

16 Was macht der Angreifer? Er bringt es fertig, in der gefährdeten Lücke die Datei, die sich hinter file verbirgt, durch eine andere zu ersetzen, z.b. durch die Passwort-Datei - die dann überschrieben wird! $ ln -s mywritablefile link $ setuidprog link &... if(!access(file,w_ok) ) { $ rm link; ln -s /etc/passwd link // gap for attack int fd = open(file,o_wronly,0); Timing überlegen! Automatisiert wiederholt versuchen! (Mehr zum Thema z.b. Viega/McGraw: Building Secure Software) SS-12 16

17 12.6 Testen kann eingesetzt werden, um Pufferüberläufe nachzuweisen Fuzzing: Programm wird mit Zufallseingaben bombardiert, je verrückter, desto besser. Reaktionen des Programms: kein Absturz Absturz, also Programmfehler sicherheitskritisch?! SS-12 17

18 Gezieltere Vorgehensweise: E. Haugh, M. Bishop: Testing C Programs for Buffer Overflow Vulnerabilities Dynamische Variante der statischen Analyse von D. Wagner et al. Werkzeug STOBO (Systematic Testing of Buffer Overflows): char dst[256]; wird durch STOBO instrumentiert: char dst[256]; STOBO_stack_buf(dst, sizeof(dst)); Damit wird die vereinbarte Puffergröße dynamisch in einer Tabelle festgehalten. SS-12 18

19 Bei den Testläufen werden die Längen der jeweils beteiligten Puffer und Zeichenketten überprüft. Auch wenn die Testdaten keinen Pufferüberlauf verursachen, können eventuell mögliche Pufferüberläufe erkannt werden und es werden entsprechende Warnungen ausgegeben. Die entsprechenden Programmstellen sind dann zu prüfen. SS-12 19

20 Ende Systemsicherheit SS-12 20