Tuesday, November 08, 2011

A Bug Hunter's Diary

I'm happy to announce that my new book »A Bug Hunter's Diary - A Guided Tour Through the Wilds of Software Security« is now available in paperback and ebook editions.


► View the detailed Table of Contents here (PDF).

► Chapter 2 is available for download here (PDF).

► Visit the book's companion website for further information, news, and resources.

     
    I hope you enjoy the book as much as I enjoyed writing it!

    Monday, May 16, 2011

    How to get gdb working on Apple iOS 4.3.x

    ► Step 1: Download and install gdb

    1) Download gdb at http://apt.saurik.com/debs/gdb_1518-11_iphoneos-arm.deb
    2) Transfer the file to the iDevice (e.g. via SSH)
    3) Install the package with the following command
      iPhone:~ root# dpkg -i gdb_1518-11_iphoneos-arm.deb

      This version of gdb will work on iOS 4.3.x with ASLR but it has a problem displaying the register values. To solve this issue I wrote a little gdb script.

      ► Step 2: Download and use my gdb script

      1) Download the gdb script at http://www.trapkit.de/pub/registers.gdb
      2) Transfer the file to the iDevice (e.g. via SSH)
      3) Start gdb and load the script with the following command:
        (gdb) source registers.gdb

        The script implements a new gdb command called 'ir' ([i]nfo[r]egisters) that lists the registers and their contents. Example output:
          (gdb) ir
          r0      0x10004005      268451845
          r1      0x07000006      117440518
          r2      0x00000000      0
          r3      0x00000c00      3072
          r4      0x00001a03      6659
          r5      0xffffffff      -1
          r6      0x00000000      0
          r7      0x2feb5dbc      803954108
          r8      0x00000000      0
          r9      0x3f45afb4      1061531572
          r10     0x00000000      0
          r11     0xffffffff      -1
          sp      0x2feb5d84      803954052
          lr      0x35cd575f      902649695
          pc      0x35cd5c00      902650880

          Alternatively, rename the file to '.gdbinit' and put it in the home directory of the user that will run gdb.

          Friday, January 14, 2011

          checksec.sh now with FORTIFY_SOURCE support

          New checksec.sh release.

          What's new with version 1.4:

            * Support for FORTIFY_SOURCE (--fortify-file, --fortify-proc)
            * Lots of other bugfixes and improvements
              - Check if the readelf command is available
              - readelf support for 64-bit ELF files
              - Check if the requested files and directories do exist
              - '--dir' is now case-sensitive and correctly deals with trailing slashes
              - Check user permissions
              - Etc.

          ► Example of the new '--fortify-file' option

          The following testcase is vulnerable to a classical stack buffer overflow (see line 10):
          tk@ubuntu$ cat testcase.c
          01 #include <string.h>
          02 #include <stdio.h>
          03
          04 int
          05 main (int argc, char* argv[])
          06 {
          07        int     a = 1;
          08        char    buf[12];
          09
          10        strcpy (buf, argv[1]);
          11        printf ("%08x\n", a);
          12
          13        return 0;
          14 }
          Compile the testcase without stack canary support (-fno-stack-protector) and without FORTIFY_SOURCE:
          tk@ubuntu$ cat /etc/lsb-release
          DISTRIB_ID=Ubuntu
          DISTRIB_RELEASE=10.10
          DISTRIB_CODENAME=maverick
          DISTRIB_DESCRIPTION="Ubuntu 10.10"
          
          tk@ubuntu$ gcc -fno-stack-protector -o testcase testcase.c
          Check the executable file with checksec.sh:


          The output shows, that FORTIFY_SOURCE is indeed not supported by the executable file. Now we try to overflow the stack buffer:
          tk@ubuntu$ ./testcase AAAA
          00000001
          
          tk@ubuntu$ ./testcase AAAABBBBCCCCDDDD
          44444444
          As can be seen from the output, the stack variable 'a' was successfully overwritten with our overly long command line argument ('a' was overwritten by the supplied D's or 0x44 in hexadecimal). Now we compile the testcase with FORTIFY_SOURCE support but without stack canaries and check the executable file with checksec.sh again:
          Under Ubuntu FORTIFY_SOURCE is activated when compiled with -O2 or higher. On other Linux distributions (e.g. Fedora or openSUSE) you need to add the compiler flag '-D_FORTIFY_SOURCE=2'.

          The output of checksec.sh shows, that the executable file was successfully compiled with FORTIFY_SOURCE. Now we try to overflow the buffer again:
          tk@ubuntu$ ./testcase AAAABBBBCCCCDDDD
          *** buffer overflow detected ***: ./testcase terminated
          ======= Backtrace: =========
          /lib/libc.so.6(__fortify_fail+0x50)[0x936970]
          /lib/libc.so.6(+0xe486a)[0x93586a]
          /lib/libc.so.6(__strcpy_chk+0x44)[0x934be4]
          ./testcase[0x8048447]
          /lib/libc.so.6(__libc_start_main+0xe7)[0x867ce7]
          ./testcase[0x8048381]
          ======= Memory map: ========
          007d4000-007f0000 r-xp 00000000 08:01 135323     /lib/ld-2.12.1.so
          007f0000-007f1000 r--p 0001b000 08:01 135323     /lib/ld-2.12.1.so
          007f1000-007f2000 rw-p 0001c000 08:01 135323     /lib/ld-2.12.1.so
          0080f000-00829000 r-xp 00000000 08:01 131159     /lib/libgcc_s.so.1
          00829000-0082a000 r--p 00019000 08:01 131159     /lib/libgcc_s.so.1
          0082a000-0082b000 rw-p 0001a000 08:01 131159     /lib/libgcc_s.so.1
          00851000-009a8000 r-xp 00000000 08:01 138119     /lib/libc-2.12.1.so
          009a8000-009aa000 r--p 00157000 08:01 138119     /lib/libc-2.12.1.so
          009aa000-009ab000 rw-p 00159000 08:01 138119     /lib/libc-2.12.1.so
          009ab000-009ae000 rw-p 00000000 00:00 0
          00ff9000-00ffa000 r-xp 00000000 00:00 0          [vdso]
          08048000-08049000 r-xp 00000000 08:01 658356     /home/tk/testcase
          08049000-0804a000 r--p 00000000 08:01 658356     /home/tk/testcase
          0804a000-0804b000 rw-p 00001000 08:01 658356     /home/tk/testcase
          09e50000-09e71000 rw-p 00000000 00:00 0          [heap]
          b779f000-b77a0000 rw-p 00000000 00:00 0
          b77ae000-b77b0000 rw-p 00000000 00:00 0
          bfb00000-bfb21000 rw-p 00000000 00:00 0          [stack]
          Aborted

          This time the attempt to trigger the buffer overflow was successfully mitigated by FORTIFY_SOURCE.

          ► Example of the new '--fortify-proc' option

          With the new option '--fortify-proc' it is also possible to check running processes for FORTIFY_SOURCE support:


          You can download the new version 1.4 of checksec.sh here.

          Thursday, July 15, 2010

          Zone Crasher

          I released a new security advisory for Oracle Solaris and OpenSolaris. See TKADV2010-005 for a detailed description of the vulnerability and the OpenSolaris source browser for the source code fixes.

          Tuesday, May 04, 2010

          checksec.sh now with kernel support

          New checksec.sh release.

          What's new with version 1.3:

          * Additional checks for a number of kernel hardening features.
            Thanks to Jon Oberheide (jon.oberheide.org).
          Example of the new "--kernel" option:


          You can download the new version 1.3 of checksec.sh here.

          Sunday, April 18, 2010

          Split-process model FTW

          As I already mentioned in my last posting Google Chrome supports a split-process model that allows each browser tab to exist in its own process. The benefits to such a configuration include security and stability, as a bug in the renderer will only cause problems with a single tab that can be closed while others remain active.

          ► Want an example?


          If you open this testcase in Apple's Safari the browser will crash. If you open the testcase in Google Chrome only the current tab will be affected. It's a simple stack overflow (stack exhaustion) bug. This is a stability issue that by itself cannot lead to remote code execution. See this blog entry for more information about stack overflows.

          If you want some more information about the particular bug see the Chromium bugtracker or Webkit's Bugzilla.

          Apple also finally recognized the benefits of such a split-process model: see WebKit2.

          Friday, April 02, 2010

          "Kernel Bug" in Google Chrome

          I have to admit that I'm deeply impressed by the security architecture of Chromium, the open-source browser upon which Google Chrome is built. Google provides a lot of interesting background information on the security architecture of Chromium here and here. The most important security feature of Chromium is that the browser has two modules in separate protection domains: a »browser kernel«, which interacts with the operating system, and a »rendering engine«, which runs with restricted privileges in a sandbox.

          If there's a bug in the rendering engine (JavaScript V8, Webkit, FFmpeg etc.) it will only affect a sandboxed renderer process. As long as you can't escape the sandbox you're quite limited in what you can do. But if you find a bug in the browser kernel the game changes.

          Lately (see TKADV2010-004) I found an out-of-bounds array indexing bug in the FTP handling code of Google Chrome. As all the networking code, including the handling of FTP, is implemented in the browser kernel, the bug not only affects a sandboxed browser tab but the whole browser.

          If you want to crash your Google Chrome browser (Windows version <= 4.1.249.1036) see my advisory for a proof of concept.

          Tuesday, March 30, 2010

          My new book just got released!

          It's available in German only at the moment, but I'm currently working on an English version of the book.

          ► German Version

          »Aus dem Tagebuch eines Bughunters.
           Wie man Softwareschwachstellen aufspürt und behebt«

          Das Buch beschreibt den Lebenszyklus ausgewählter Softwareschwachstellen, die ich im Laufe der letzten Jahre gefunden habe. Jedes Kapitel erläutert dabei im Detail, wie ich die jeweilige Schwachstelle gefunden und anschließend ausgenutzt habe, sowie die durchgeführten Schritte zur Behebung der Schwachstelle seitens des Herstellers.

          Mehr Informationen zum Buch gibt es auf meiner Webseite oder beim dpunkt.verlag.

          ► English Version

          Working Title: »From A Bug Hunter's Diary«

          The book describes the lifetime of some interesting real-life software vulnerabilities I found over the last years. Each chapter goes into great detail on how I found a bug, the steps I took to exploit it and how it was rectified by the vendor.

          The English version will be released when it is finished ;)