Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Sicherheitsprobleme in der Programmierung ● Wie man unsichere Programme schreibt und terroristische Akte nach §202c STGB (DE) begeht indem man deren Sicherheitsprobleme.

Ähnliche Präsentationen


Präsentation zum Thema: "Sicherheitsprobleme in der Programmierung ● Wie man unsichere Programme schreibt und terroristische Akte nach §202c STGB (DE) begeht indem man deren Sicherheitsprobleme."—  Präsentation transkript:

1 Sicherheitsprobleme in der Programmierung ● Wie man unsichere Programme schreibt und terroristische Akte nach §202c STGB (DE) begeht indem man deren Sicherheitsprobleme analysiert

2 Was erwartet euch ● Übersicht über die verschiedenen Fehlerarten ● Beispiele ● Auflösung berühmter Mythen der Programmierung ● Notizen und Erwägung zur Codeverteilung ● Hinweise auf weitere Literatur zum selber bauen

3 Fehlerarten ● Buffer Overflow ● 32-Bit-Code auf 64-Bit-Systemen ● Synchronisierungsprobleme ● Formatstringangriffe ● Injektionsangriffe ● Authentisierungs- und Verifikationsmängel

4 Buffer Overflows ● Ein Puffer, um z.B. Zeichenketten zwischenzuspeichern, wird überschrieben ● Daten werden manipuliert ● Unterscheidung nach Ort des Überschreibens in – Stack Overflow – Heap Overflow

5 Stack Overflow int main(int argc, char **argv) { char buf[128]; puts(“Bitte geben Sie irgendwelchen Quatsch ein”); scanf(“%s”, buf); puts(buf); } /** * Preisfrage: was passiert, wenn mehr als 128 * Zeichen eingegeben werden? */

6 Organisation des Speichers

7 Stack Overflow Basics ● Puffer wird überschrieben mit Assembly-Befehlen – Sprung an das Ende des Codes, um Addresse der Zeichenkette /bin/sh zu erhalten – Addresse vom Stack holen – Nummer des Exec-Systemaufrufes in %eax oder auf den Stack, je nach Betriebssystem – Addresse der Zeichenkette in 2. Register/auf Stack – Dasselbe in das 3. Register/auf den Stack – 0 in viertes Register/auf Stack als Umgebung – Systemaufruf auslösen

8 Stack Overflow Basics 2 ● Returnaddresse wird mit Startaddresse des Puffers ersetzt ● Code im Puffer wird beim Return der Funktion ausgeführt ● Macht besonders viel Spass, wenn das Programm SUID root ist: % echo shellcode | program #

9 Stack Overflow Basics 3 Oh weh! Ein String darf keine NULL-Bytes enthalten! Wie kann ich dann 0 in ein Register schreiben? ● Keine Panik ● xor %eax,%eax → ergibt auch 0 ● Es geht immer ganz ohne Nullen

10 Heap Overflow ● Statt des Stacks wird der Heap überflutet ● Dort befinden sich oft allerlei interessante Funktionspointer (z.B. für fread/fwrite/etc.) ● Benötigt also genauerere Kenntnis des Programms ● Windows: Structured Exception Handler! ● Keine Möglichkeit der Eindämmung, anders als beim Stack ● ProPolice oder NX blockiert den Weg über den Stack? Geh durch den Heap!

11 32-Bit-Code auf 64-Bit-Systemen ● System versucht, Code kompatibel zu halten ● System weiss nicht, ob Vorzeichen vorhanden sind ● Bei nicht vorzeichenbehaftetem Code treten daher allerlei lustige Dinge auf unsigned long fl = (_flags & 0xFFFF0000) > 16; ● Die Bits 48 bis 16 können immer noch gesetzt sein! 0xFFFF0000 wird zu 0xFFFFFFFFFFFF0000 ● Richtig: Konstante als längstmöglichen Wert laden unsigned long fl = (_flags & 0xFFFF0000L) > 16;

12 32-Bit-Code auf 64-Bit-Systemen Warum ist das ein Problem? ● Bounds checks! (Buffer Overflows!) ● Flagmaskierung (Und täglich grüsst das Murmelflag) ● Immer wahre Vergleiche

13 Synchronisierungsprobleme ● Interprozess-Synchronisierung – Dateizugriff – System V IPC – Netzwerksockets ● Threadsynchronisierung – Double Free → Heap Overflow! – Auch wieder IPC, heisst einfach anders und geht einfacher ● Signalbehandlungsfehler – Auch asynchron!

14 Unsynchronisierter Dateizugriff ● Atomische Operationen zum Erzeugen – File in /tmp mit Permissions 0777 anlegen – Angreifer schreibt in das File – Permissions des Files auf 0755 ändern – Lösung: int fd = open(path, O_WRONLY | O_CREAT | O_EXCL, 700); ● Beim Arbeiten mit Dateien stets brav die Locking-API benutzen – LOCK_SH zum Lesen stellt sicher, dass niemand schreibt – LOCK_EX zum Schreiben, damit niemand liest

15 Unsynchronisierter Dateizugriff 2 ● Sind mehrere Dateien zu öffnen, nicht vergessen, sie bei Fehlschlag wieder zu schliessen – Dining Philosophers' Problem ● Fachbegriff: «Race Condition» ● Interessante Auswirkungen bei – Generatoren für kryptographische Schlüssel – Compilern

16 System V IPC ● Grundsätzlich auch wieder race conditions ● Injektion von Objekten in den Speicher der betroffenen Applikationen! ● Berechtigungen beim Erstellen angeben hilft Threadsynchronisierungsprobleme ● Weisen im Grunde dieselben Probleme auf wie IPC-Interaktion ● Vollständiger direkter Speicherzugriff möglich! – Normalerweise aber nicht von aussen

17 Signalbehandlungsangriffe ● Auch innerhalb einer Single-Thread-Applikation ist der Codefluss nicht immer linear ● Signalmaske schützt nicht gegen mehrere Signale verschiedener Typen ● Greifen Signalbehandlungsroutinen auf dieselben Objekte zu, drohen heap corruptions und -overflows ● Keine nichtreentranten Funktionen in Signalhandlern aufrufen! ● Am besten gar nichts aufrufen

18 Formatstringangriffe int main(int argc, char **argv) { if (argc < 2) exit(EXIT_FAILURE) printf(argv[1]); exit(EXIT_SUCCESS); } /* program %s ? */

19 Formatstringangriffe ● Erlaubt, beliebigen Speicher zu lesen ● Sorgt für Verzückung, wenn das Programm z.B. die /etc/shadow im Speicher hat ● Codeausführung meines Wissens nach nicht möglich, solange keine anderen Sicherheitslücken damit verbunden sind

20 Injectionangriffe ● Einbettung einer Sprache in eine andere ● Ausbruch aus der eingebetteten Sprache um Code in der äusseren Sprache auszulösen ● Ältestes Beispiel: /etc/passwd – chfn -f “Tonnerre Lombard:/home/tonnerre:/bin/ksh\nmyroot:ousmfylx02JBI:0:0: My Root” tonnerre:uTl7.9hpkGfI2:1000:500:Tonnerre Lombard:/home/tonnerre:/bin/ksh myroot:ousmfylx02JBI:0:0:My Root:/home/tonnerre:/bin/ksh

21 Cross Site Scripting ● ealert%28document%2ecookie%29%3b%3c%2fscript%3e ● The search string was: hello world alert(document.cookie); ● Popup: “SID=ewewwerw...” ● Stellen wir uns vor, wir sind nicht so gut gelaunt und machen einen AJAX-Aufruf auf unsere Seite

22 Cross Site Scripting 2 ● Lösung: eingebettete Sprachen immer brav encoden #!/usr/bin/perl -w use CGI qw(param); print(encode_entities_numeric(param(“searchstr”))); → hello world<script>alert(document.cookie);</script> → Kein JavaScript-Code wird ausgeführt

23 SQL injections ● Ausbrechen aus SQL-Strings und Einbetten von SQL-Code $stmt = “SELECT uid FROM users WHERE uid = '”. $_POST[“uid”]. “' AND pwhash = '”. sha1($_POST[“pw”]). “';”; ● Benutzername: ' or 1 = 1 -- SELECT uid FROM users WHERE uid = '' OR 1 = 1 -- ' AND pwhash = '...'; ●

24 SQL injections 2 ● Lösung: Encoden der Strings $sth = $dbh->prepare(“SELECT uid FROM users WHERE username = ? AND password = ?;”); $sth->execute(param(“username”), sha1_hex(param(“password”)));

25 Fehlen von Authorisierungsprüfungen ● Benutzer loggt sich ein, sieht im Menü keinen Link auf das Administrationsinterface ● Admin loggt sich ein, sieht im Menü den Link auf /admin ● Benutzer öffnet /admin, bekommt Administrationsinterface und darf Benutzer löschen und sich selbst zum Administratoren machen

26 Fehlen von Authorisierungsprüfungen 2 ● Kunde A geht auf und meldet sich als Kunde A an ● Kundeninterface redirigiert ihn auf ● Kunde ändert URL in ● Kunde sieht Daten von Kunde B und kann diese eventuell sogar bearbeiten

27 Fehlen von Authentisierungsprüfungen ● Seite redirigiert auf Login ● Login prüft Berechtigung des Benutzers ● Login setzt z.B. Benutzernamen in ein Cookie ● Rest der Seite liest das Cookie → Jeder, der sich selbst ein Cookie setzt, ist eingeloggt ● Seite /unter/seite prüft die Authentisierungsdaten nicht sondern nimmt an, dass man den Link nur gefunden hat weil man authentisiert war

28 Session Hijacking bei schwachen Cookies ● Cookie UID=username → Benutzer kann Cookie ändern und ist anderer Benutzer (UID=admin?) ● Cookie SID=auto_increment → Benutzer kann vorhergehende und nachfolgende Sitzungsnummer erraten und Aktionen als andere Benutzer ausführen ● Wir brauchen kryptographisch sichere Session IDs ● Alternativ: Authentisierung mit SSL-Zertifikaten, da ist die Sicherheit bereits «eingebaut»

29 Cross Site Request Forgery ● Relativ neues Thema (im Vergleich) ● Seite A (e.g. Forum) enthält Link auf ● Benutzer, die bei Seite B angemeldet sind und verleitet werden, auf den Link zu klicken, votieren automatisch für das, was Seite A will ● Lösung: kryptographisch sichere Transaktionsnummer ● Problem: paralleles tabbed browsing ungesund ● Andere Lösungen?

30 Mythos: Skriptsprachen lösen diese Sicherheitsprobleme ● Mit Skriptsprachen kann man immer noch schlechten Code schreiben ● Die meisten Beispiele waren oder funktionieren auch in Skriptsprachen ● Codefilter existieren, funktionieren aber nicht (man kann keinen beliebigen Schadcode erkennen) ● Was des einen buffer overflow ist des anderen eval() ● Der Interpreter ist auch nicht beliebig sicher

31 Mythos: Nicht-Maschinen- Bytecode löst das Problem ● Bytecode ist mehr oder weniger mit Skriptsprachen gleichzusetzen (einfach nicht menschenlesbar) ● Der Interpreter/JIT compiler kann auch kaputt sein ● Sandboxes existieren, sind aber entweder unwiksam oder machen die Sprache unbrauchbar

32 Mythen über Mythen Es gibt keine Programmiersprache, welche es erlaubt, das Gehirn abzuschalten. -- ich “There is no brains-out programming language.”

33 Erwägungen zur Codedistribution ● Der beste Code ist nur so viel wert wie sicher gestellt ist dass er korrekt am anderen Ende ankommt ● Bundestrojaner im Binary? ● Sicherheitsvorkehrungen sind in der heutigen Zeit notwendig

34 Systemsicherheit ● Das System sollte gut gewartet werden und auf Einbrüche überprüft ● Das System, auf dem Binaries gebaut werden, sollte gewissen Anforderungen entsprechen – Nur von unabhängigen Experten als sicher eingestufte Komponenten einsetzen – Software sollte auf einem Weg bezogen werden, welcher den hier dargelegten Anforderungen entspricht – Code der verwendeten Tools sollte offen zugänglich sein

35 Systemsicherheit 2 Wenn der Hersteller nicht glaubt, dass den Interessen seiner Kunden damit gedient ist, wenn der Code öffentlich überprüfbar vorliegt, sollte man ihm an diesem Punkt Glauben schenken und sein Produkt meiden.

36 Automatisierte Testsuites ● Neben den Tests auf Funktionalität sollte eine automatische Testsuite für typische Sicherheitsprobleme existieren ● Diese könnte z.B. automatisch furchtbar lange Benutzernamen angeben ● Dies ist nicht immer einfach zu erkennen: z.B. zu lange öffentliche Schlüssel bei Krypto-Tools

37 Der Mensch als Testsuite ● Regelmässige penetration tests der Build- und Entwicklungssysteme sowie der Software selbst – Der Versuch, in die eigene Software einzubrechen, erweitert das eigene Wissen um die Software ● Über aktuelle Sicherheitslücken und Expoit-Techniken auf dem Laufen halten und sie anwenden – Bringt auch mehr Erfahrung auf dem Gebiet der Softwareentwicklung ● Neben Pentests auch code audits ;-)

38 Die richtigen Tools für's Release ● Z.B. zuverlässiger Compiler – gcc 4.x zerstört einige Sicherheitschecks: ASSERT(a + b > a); /* Check for integer overflows */ – gcc 4.x optimiert einiges an Code kaputt – Compiler vor dem Release genauestens unter die Lupe nehmen: ist der produzierte Code sicher/funktionsfähig? ● Ähnliches gilt auch für Skriptsprachen und den Interpreter, etc. ● Tools eventuell patchen wenn notwendig

39 Codesignaturen ● Quellcode und dessen Änderungen sollten signiert sein, um sicherzustellen, dass sie nicht verändert wurden seit sie eingesendet wurden ● Binärdistributionen sollten signiert werden, um sicherzustellen, dass sie seit der Erstellung nicht verändert wurden (Bundestrojaner!) ● Signaturen von Sicherheitsexperten könnten Code zertifizieren ● Sourceverwaltungstools wie tla liefern Signaturfunktion mit → braucht aber mehr Verbreitung

40 (null) #


Herunterladen ppt "Sicherheitsprobleme in der Programmierung ● Wie man unsichere Programme schreibt und terroristische Akte nach §202c STGB (DE) begeht indem man deren Sicherheitsprobleme."

Ähnliche Präsentationen


Google-Anzeigen