1 / 41

Sichere Implementierung

Sichere Implementierung. Systemsicherheit: Bufferoverflow , FormatString. Motivation Übungsaufgabe. Lab3: Stack-basierte Buffer Overflows. “ Buffer Overflow“-Angriffe.

sidney
Download Presentation

Sichere Implementierung

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Sichere Implementierung Systemsicherheit: Bufferoverflow, FormatString

  2. Motivation Übungsaufgabe • Lab3: Stack-basierte Buffer Overflows Dr. Wolf Müller

  3. “Buffer Overflow“-Angriffe • „Buffer Overflow“-Angriffe nutzen Schachstellen, die sich aus Implementierungsfehlern infolge nachlässiger Programmierung resultieren. • Ansatzpunkt: Programme, wo Daten in Variablen fester Länge (String, Array), eingelesen oder kopiert werden, ohne,dass die reale Länge durch das Programm geprüft wird. • Variablen, in die Daten kopiert werden sind abstrakt betrachtet Pufferbereiche (buffer). • Schreiben einer zu großen Datenmenge führt zum Überlauf (overflow). Dr. Wolf Müller

  4. Ziel, Ablauf • Absicht: • Ausführung beliebigen Codes • Ausführung einer Remote-Shell, Installation eines Virus, Keyloggers, … • Denial of service • Schritte: • Einbringen von Code in den Puffer • Umleitung des Kontrollflusses zum Angriffs-Code • Ausführung des Angriffs-Codes Dr. Wolf Müller

  5. Buffer Overflow: Entwicklung • Anfangs nur Ausnutzung von Operationen zum Kopieren von Zeichenketten • Später auch Integer-Overflow • Schleifen die nicht korrekt terminieren • Unicode-Probleme - Länge einzelner Zeichen ist variabel Dr. Wolf Müller

  6. Angriffsmöglichkeiten • Ziele • stack, heap, staticarea • Parameter Veränderung (non-pointer data) • D. h. Ändern von Parametern für existierende Aufrufe zu exec() • Injizierter Code und existierender Code • Absolute und relative Adressenabhängigkeiten • Ähnliche Attacken • Integer overflows • Format-string Angriffe Dr. Wolf Müller

  7. Adressraumverwaltung • Alle gängigen OS unterstützen virtuellen Speicher • Jedem Prozess virtueller Adressraum zugeordnet • Drei logische Bereiche • Text bzw. Codesegmet • Enthält Befehle des Prozesses • In der Regel durch OS gegen Überschreiben geschützt • Heap • Enthält dynamisch angelegte Datenobjekte, globale Variablen, globale Konstanten • Wächst von niedrigen zu höheren Adressen • Grenze zum Stack fließend • Stack • LIFO • Dient Verwaltung von Prozeduraufrufen • Enthält lokale Variablen von Prozeduraufrufen, deren Eingabeparameter, Rücksprungadresse, Umgebungsvariablen • Wächst von höheren zu niedrigen Adressen • Compiler erzeugt Maschinencode, um Daten auf Stack und Heap zu speichern oder wieder zu entfernen • Stack und Heap können nicht gegen Überschreiben geschützt werden, sind in der Regel ausführbar. Dr. Wolf Müller

  8. argument 2 argument 1 Address of Attack code RA frame pointer locals Attack code buffer 0xFFFFFFFF 0xC0000000 0x42000000 0x08048000 0x00000000 Segmentierung des virtuellen Adressraums kernel space stack shared library heap bss static data code Dr. Wolf Müller

  9. Stack Stack Layout • Jede aufgerufene Prozedur bekommt neuen Stack Frame auf Stack • Stack wächst (in der Regel) zu niedrigen Adressen • Stack Pointer zeigt auf aktuell oberstes Stackelement (erstes verfügbares Element) • Frame Pointer zeigt auf Anfang des aktuellen Stackframes • Größe und Offset des Frames werden zur Compile-Zeit festgelegt. • Inhalt des Stackframes wird als Offset relativ zum Stackpointer oder Framepointeraddressiert.

  10. Stack Frame: Was liegt drin? • Parameter • Lokale Variablen • Temporäre Werte • Rückgabewert • Stack Pointer • Frame Pointer • Returnadresse • (gespeicherter PC) • Dynamisch gelinkt • Referenz auf Frame des Aufrufenden, um nach Aufruf ursprünglichen Stack wieder zu rekonstruieren. • Statisch gelinkt • Referenz auf auf nächsten Frame der lexikalisch einschließenden Prozedur.

  11. Stack Layout Angenommen, Funktion f ruft g und g bereitet Aufruf von h vor ... Erste 4 Parameter in der Regel in Registern. Rest in umgekehrter Reihenfolge gespeichert, damit mit fp+increment zugegriffen werden kann. parameter 6 f-Frame parameter 5 return value return address Aktueller FP f’s Frame Pointer. Wird wieder hergestellt bei Return von g. Wichtig bei dynamischem Linken. saved fp local variables Temporäre Variablen, erzeugt durch Compiler bei Code-Generierung. temporary values g verantwortich für Sicherung und Wiederherstellung potentiell von f benutzter Register. g-Frame other savedregisters h's Parameter. parameters Oft in Registern gespeichert. return value return address Aktueller SP Program Counter, damit g nächste Instruktion nach Return von h weiß. saved fp

  12. Raten der Einsprungaddresse new return address new return address new return address new return address new return address new return address Real program nop instructions Dr. Wolf Müller

  13. NOPs (90) mal anders IA32 27 daa ' IA32 2f das / IA32 33 c0 xor %eax,%eax IA32 37 aaa 7 IA32 3f aas ? IA32 40 inc %eax @ IA32 41 inc %ecx A IA32 42 inc %edx B IA32 43 inc %ebx C IA32 44 inc %esp D IA32 45 inc %ebp E IA32 46 inc %esi F IA32 47 inc %edi G IA32 48 dec %eax, H IA32 4a dec %edx J IA32 4b dec %ebx K … http://shellcode.org Dr. Wolf Müller

  14. Beispiele • (In)famous: Morris worm (1988) • gets() in fingerd • Code Red (2001) • MS IIS .ida vulnerability • Blaster (2003) • MS DCOM RPC vulnerability • Mplayer URL heap allocation (2004) % mplayer http://`perl –e ‘print “\””x1024;’` • ... Dr. Wolf Müller

  15. Privilegierte Programme (suid | sgid)openSuSE-10.3 find / -type f \( -perm -04000 -o -perm -02000 \) -rwsr-xr-x 1 rootaudio /bin/eject -rwsr-xr-x 1 rootroot /bin/mount -rwsr-xr-x 1 rootroot /bin/ping -rwsr-xr-x 1 rootroot /bin/ping6 -rwsr-xr-x 1 rootroot /bin/su -rwsr-xr-x 1 rootroot /bin/umount -rwsr-xr-x 1 rootroot /opt/kde3/bin/artswrapper -rwsr-xr-x 1 rootshadow /opt/kde3/bin/kcheckpass -rwxr-sr-x 1 rootnogroup /opt/kde3/bin/kdesud -rwsr-xr-x 1 rootroot /opt/kde3/bin/kpac_dhcp_helper -rwsr-xr-x 1 rootroot /opt/kde3/bin/start_kdeinit -rwsr-x--- 1 rootdialout /sbin/isdnctrl -rwsr-xr-x 1 rootshadow /sbin/unix2_chkpwd -rwsr-xr-x 1 rootshadow /sbin/unix_chkpwd -rwsr-xr-x 1 roottrusted /usr/bin/at -rwsr-xr-x 1 rootshadow /usr/bin/chage -rwsr-xr-x 1 rootshadow /usr/bin/chfn -rwsr-xr-x 1 rootshadow /usr/bin/chsh -rwsr-xr-x 1 roottrusted /usr/bin/crontab -rwsr-xr-x 1 rootshadow /usr/bin/expiry -rwsr-xr-x 1 rootroot /usr/bin/fileshareset -rwsr-xr-x 1 roottrusted /usr/bin/fusermount -rwxr-sr-x 1 gamesgames /usr/bin/glines -rwxr-sr-x 1 gamesgames /usr/bin/gnibbles -rwxr-sr-x 1 gamesgames /usr/bin/gnobots2 -rwxr-sr-x 1 gamesgames /usr/bin/gnometris -rwxr-sr-x 1 gamesgames /usr/bin/gnomine -rwxr-sr-x 1 gamesgames /usr/bin/gnotravex -rwxr-sr-x 1 gamesgames /usr/bin/gnotski -rwsr-xr-x 1 rootshadow /usr/bin/gpasswd -rwxr-sr-x 1 gamesgames /usr/bin/gtali -rwsr-xr-x 1 rootshadow /usr/bin/kcheckpass -rwxr-sr-x 1 rootnogroup /usr/bin/kdesud -rwsr-xr-x 1 lpsys /usr/bin/lppasswd -rwxr-sr-x 1 gamesgames /usr/bin/mahjongg -rwsr-xr-x 2 rootroot /usr/bin/man -rwsr-xr-x 2 rootroot /usr/bin/mandb -rwsr-xr-x 1 rootroot /usr/bin/newgrp -rwsr-xr-x 1 rootshadow /usr/bin/passwd -rwsr-xr-x 1 rootroot /usr/bin/rcp -rwsr-xr-x 1 rootroot /usr/bin/rlogin -rwsr-xr-x 1 rootroot /usr/bin/rsh -rwxr-sr-x 1 gamesgames /usr/bin/same-gnome -rwsr-xr-x 1 rootroot /usr/bin/sudo -rwsr-xr-x 1 rootvideo /usr/bin/v4l-conf -rwxr-sr-x 1 roottty /usr/bin/wall -rwxr-sr-x 1 roottty /usr/bin/write -rws--x--x 1 rootroot /usr/bin/Xorg -rwxr-sr-x 1 gamesgames /usr/games/lbreakout2 -rwxr-sr-x 1 rootmail /usr/lib/cyrus/bin/deliver -rwsr-xr-x 1 rootroot /usr/lib/libgnomesu/gnomesu-pam-backend -rwsr-xr-x 1 rootroot /usr/lib/mc/cons.saver -rwxr-sr-x 1 rootpolkituser /usr/lib/PolicyKit/polkit-grant-helper -rwsr-xr-x 1 rootroot /usr/lib/PolicyKit/polkit-grant-helper-pam -rwsr-xr-x 1 rootroot /usr/lib/pt_chown -r-xr-sr-x 1 rootuucp /usr/lib/vmware-tools/bin32/vmware-tpvmlp -r-sr-xr-x 1 rootroot /usr/lib/vmware-tools/sbin32/vmware-hgfsmounter -rwxr-sr-x 1 roottty /usr/lib/vte/gnome-pty-helper -rwsr-xr-x 1 rootroot /usr/local/lib/xcdroast-0.98/bin/xcdrwrap -rwsr-xr-x 1 rootroot /usr/sbin/change-passwd -rwsr-xr-x 1 rootuucp /usr/sbin/mgnokiidev -rwxr-sr-x 1 rootmaildrop /usr/sbin/postdrop -rwxr-sr-x 1 rootmaildrop /usr/sbin/postqueue -rwsr-xr-x 1 rootroot /usr/sbin/suexec2 -rwxr-sr-x 1 roottty /usr/sbin/utempter -rwsr-xr-x 1 rootroot /usr/sbin/zypp-checkpatches-wrapper Dr. Wolf Müller

  16. Demo • Buffer Overflow Vulnerabilities (http://nsfsecurity.pr.erau.edu/bom/index.html) • http://nsfsecurity.pr.erau.edu/bom/Jumps.html • http://nsfsecurity.pr.erau.edu/bom/Spock.html • http://nsfsecurity.pr.erau.edu/bom/Smasher.html • http://nsfsecurity.pr.erau.edu/bom/StackGuard.html • Linux SuSE 12.1 • https://www2.informatik.hu-berlin.de/sar/Itsec/slides_ssl/demo_bufferoverflow.tgz Dr. Wolf Müller

  17. ASCII-Tabelle Dr. Wolf Müller

  18. BufferOverflow/README.txt # It is a demo for bufferoverflow, please usewithcare and only on yourownsystem! # (c) Wolf.Mueller@informatik.hu-berlin.de # runasasroot echo "0" > /proc/sys/kernel/randomize_va_space # not present in OpenSuSE 11.4 #echo "0" > /proc/sys/kernel/exec-shield gcc-fno-stack-protector -z execstack -o unsafeunsafe.c chmod u+s unsafe # runcmdsasconvetionaluser: suuser ./exploit.pl #LocalRoot-Shell ./root_sk.pl #LocalRoot-Shell ./open_port*.pl #OpensRoot-Shell over network # Access to networkedRoot-Shell via commandgiven in rsh*. Dr. Wolf Müller

  19. Vorbeugung • Strategien • Erkennen und entfernen der Schwachstellen (am besten) • Verhindern von Code-Einschleusung • Erkennung von Code-Einschleusung • Verhindern der Code-Ausführung • Wo kann eingegriffen werden? • Analyse und Kompilierung des Codes • Linken der Objekte zum Programm • Laden des Programm in den Speicher • Ausführung des Programms Dr. Wolf Müller

  20. Gefährliche C-Funktionen Dr. Wolf Müller

  21. Werkzeuge / Strategien • Secure Programming (strcpy strncpy, …) • Typesafe Programming Languages (Java) • Splint - Check array bounds and pointers • Non-executable stack • Stackguard – put canary before RA • Libsafe – replace vulnerable library functions • RAD – check RA against copy • Analyze call trace for abnormality • PointGuard – encrypt pointers • Binary diversity – change code to slow worm propagation • PAX – binary layout randomization by kernel • Randomize system call numbers Dr. Wolf Müller

  22. Libsafe / StackGuard • Wenn Quellcode vorhanden! • Libsafe (Linux) • Wrapper für Standard-C Bibliotheksaufrufe, insbesondere für „riskante“ Funktionen • StackGuard Tool (UNIX) • Patch für C-Compiler / aktuell default im gcc • Compiler: • Fügt spezielles Kontrollzeichen (Canary) direkt hinter der Rücksprungadresse auf dem Stack ein. • Erzeugt Code, der vor dem Rücksprung prüft, ob das Kontrollzeichen verändert wurde. • Bei Änderung Warnung in SysLog • analog Stack Cookies (Microsoft für Windows Server 2003) Dr. Wolf Müller

  23. Futher Reading • Randomize code • Barrantes, Ackley, Forrest, Palmer, Stefanovic, Zovi, “Randomized Instruction Set Emulation to Disrupt Binary Code Injection Attacks,” ACM CCS 2003. • Randomize location of code/data • Bhatkar, DuVarney, Sekar, “Address Obfuscation: an Efficient Approach to Combat a Broad Range of Memory Error Exploits,” USENIX Security 2003. Dr. Wolf Müller

  24. Randomized Instruction Sets (RISE) • Bedrohung: • Einschleusung von Binärcode über das Netzwerk • Ziel: • Diversifizierung jedes Systems in von außen nicht vorhersagbarer Weise • Lösung: • Jedes Programm hat verschiedenes und geheimes Instruction-Set • Übersetzer der Instructions zur Ladezeitpunkt in zufälliger Weise modifiziert. • In HW oder Software implementierbar • Grenzen: • Keine Abwehr von Manipulationen nur im Datenbereich Dr. Wolf Müller

  25. Scrambled Code Data RISE: loading binary RISE Memory Key ELF binary file Code + Data Dr. Wolf Müller

  26. Code RISE: executing code RISE Memory Scrambled Code Key + Data Hardware Dr. Wolf Müller

  27. Injected from network Code Code Scrambled Code RISE: foreign code RISE Memory Scrambled Code Key + Data Hardware SIGILL Dr. Wolf Müller

  28. Adressen Randomisierung • Bedrohung: • Speicherfehler-Exploits • Ziel: • Verhinderung der Vorhersagbarkeit von Speicheradressen • Lösung: • Neuzuordnung von Speicherbereichen • Vertauchen der Reihenfolge von Variablen und Code • Einführung zufälliger Lücken zwischen • Grenzen: • schwierig zu implementieren mit üblichen Application Binary Interface zur Ladezeit Dr. Wolf Müller

  29. Randomisierung • Randomisierung der Startadressen von Speicherbereichen • Stack: großen Wert • Heap: großen Block allocieren • DLLs: linken mit Dummy-lib • Code/static data: Konvertierung in shared lib, oder an verschiedenen Adressen neu linken • Macht Angriffe mit absoluten Adressen schwieriger! kernel space stack shared library heap bss static data code Dr. Wolf Müller

  30. Stackrandomisierung SuSE 9.3 • Kernel: 2.6.11.4-21.17-default,ohneStackrandomisierung • Output: konstant0xbffff570 0xbffff570 0xbffff570 0xbffff570 0xbffff570 0xbffff570 openSuSE 11.4 • Kernel: 2.6.37.1-1.2-desktopmitStackrandomisierung • Output 0xbf7fd300…0xbfffbf90 0xbfa725700xbf92bc200xbff312300xbf9b4a700xbfb016000xbfb16e100xbfda88a0 #include <stdio.h> intmain() {intfoo; printf("%p\n", &foo); return 0;} ≤ 8MB Dr. Wolf Müller

  31. Randomisierung • Vertauschen der Reihenfolge von Variablen und Routinen routines • Lokale Variables in den Stackbereich • ReihenfolgestatischerVariablen • Reihenfolge der Routines in DLLs or ausfürbarenProgrammen • MachtAngriffemitrelativenAdressenschwieriger Dr. Wolf Müller

  32. Verhinderung der Ausführung • Solaris 10 • Stack-Segment als nicht ausführbar konfigurierbar • ähnliche Patches auch für • Linux (www.openwall.org) • Windows NT/2000 (securewave.com) • Trusted OS (speziell abgesicherte Varianten von Standard OS) • Trusted Solaris • Trusted HP-UX • Einbau von speziellen Compartments, die Systembereiche gegeneinander abschotten, Wirkung des BO bleibt begrenzt. Dr. Wolf Müller

  33. NX-Bit / XD-Bit • NX-Bit (no execute) Athlon 64 • XD-Bit (executiondisable) Itanium, P4, Core, Pentium-M • Hardwareunterstützung : • Bit wird Betriebssystem für Stack im Arbeitsspeicher gesetzt • Unterscheidung zwischen Daten und Code • als Daten markiertem Speicherbereich, (z.B. Bild), kann nicht ausgeführt werden. • Betriebssystem muss dieses Bit unterstützen. • Nicht für alle Programme möglich: • Just in time Compiler • Dynamischer Linker Dr. Wolf Müller

  34. Buffer Overflow: Timeline Quelle: https://zynamics.files.wordpress.com/2010/02/code_reuse_timeline1.png Dr. Wolf Müller

  35. Tools: Statische Code-Analyse • http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis • „Lint“ Dr. Wolf Müller

  36. Tools: http://valgrind.org/ • Framework für dynamische Analysewerkzeuge • Ziel: automatische Erkennung von: • Fehler in Speicherverwaltung eines Programms • Fehler im Verwalten von Thrreads • Profiling der Speichernutzung Dr. Wolf Müller

  37. Fazit & Info • Sicheres Programmieren = Königsoption • Secure Programming HOWTO : • http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html • Weiterführende Informationen: • Simple Buffer Overflow Exploitation Tutorial - Ubuntu 10.10http://www.youtube.com/watch?v=_Zvj1r3y1k0 • Erster Buffer Overflow auf dem Heap (Solar Designer):http://www.openwall.com/articles/JPEG-COM-Marker-Vulnerability. • "ExploitWritingTutorial" auf corelan.be Teil 10 Umgehung von DEP mit ROP (return oriented programming): http://www.corelan.be/index.php/2010/06/16/exploit-writing-tutorial-part-10-chaining-dep-with-rop-the-rubikstm-cube/ Dr. Wolf Müller

  38. Formatsrings: printf() • Funktion: intprintf(constchar* format, ...); • formatRegelt, wie nachfolgende Parameter interpretiert werden. • Beispiele: • printf("n=%d", 42);  n=42 //dezimal • printf("n=%u", 42);  n=42 //unsigned dezimal • printf("n=%x", 42);  n=2A //hex • printf("n=%.10d", 42);  n=0000000042 //10 Stellen • printf("%s %n", string, &num_of_chars); gibt string aus und schreibt Anzahl der ausgegebenen Zeichen nach num_of_chars in den Speicher Dr. Wolf Müller

  39. Formatsrings: Probleme printf() Was wenn keine Parameter? • printf nimmt implizit an, dass Parameter auf dem Stack liegen! • Beispiele: • printf("%x"); oberstes Wort (32bit) vom Stack //b760bc05 • printf(„%.10x"); oberstes Wort (32bit) vom Stack mit 10facher Genauigkeit // • printf("%x…%x"); n * oberste Worte vom Stack • printf("A…A%n");schreibt in Speicherbereich, auf den das oberste Stackelement (Wort) zeigt Zahl der ausgegebenen Zeichen! Dr. Wolf Müller

  40. Formatstrings: hw.c //hw.c #include <stdio.h> int main(intargc, char* argv[]) { if (argc > 1) printf(argv[1]); return 0; } #> hw "Hello World!" Hello World! #> hw "%x%x%x%x" b75efc058048439b7727ff48048430 Dr. Wolf Müller

  41. Formatsrings: Angriffsmöglichkeiten • %x Analyse des Stacks • %n (mit passend vielen ausgegebenen Zeichen) schreiben von Speicherbereichen • Z.B. Rücksprungadresse auf Stack legen, anschließend mit Hilfe von %n überschreiben. Dr. Wolf Müller

More Related