trapkit blog

BENIGNCERTAIN — Remote Extraction of RSA Private Keys

2016-09-01T14:47:00.000+02:00

TL;DR: The so-called BENIGNCERTAIN exploit dropped by the Shadow Brokers extracts RSA private keys from a captured memory dump using a technique similar to the one I described in a paper in 2006.

BENIGNCERTAIN is a "[..] remote exploit for Cisco PIX devices that sends an Internet Key Exchange (IKE) packet to the victim machine, causing it to dump some of its memory. The memory dump can then be parsed to extract an RSA private key and other sensitive configuration information" (from Mustafa Al-Bassam's writeup).

To extract RSA private keys from a captured memory dump, the exploit uses a technique similar to the one I described in a paper entitled "All Your Private Keys are Belong to Us — Extracting RSA Private Keys and Certificates from Process Memory" (2006).

A brief summary of the technique: The standard storage formats for RSA private keys and SSL certificates, as described in PKCS #8 and x509 respectively, are used to create a signature for locating them in memory. Using this signature, a simple pattern match could be done to extract the candidate asymmetric keys in their plaintext form, which could then be verified using an external tool such as OpenSSL.

(!!!) BENIGNCERTAIN looks like it is based on a *2006* technique from @tobiklein to extract keys from proc memory https://t.co/bBByaj05jr
— Matt Suiche (@msuiche) 20. August 2016

The following tweet contains different screenshots of the disassembly of the BENIGNCERTAIN exploit, showing the relevant code snippets:

Extractor of pub&priv DER keys (bc-parser)
sign1 0x3000010
sign2 "\x0D\0x06\x09\x2a\x86\x48\x86\xf7\x0d\x01\x01\x01" pic.twitter.com/qd7mBCcFZT
— Matt Suiche (@msuiche) 18. August 2016

For a more detailed description of the BENIGNCERTAIN exploit refer to:

Here's a quick writeup. BENIGNCERTAIN: remote exploit to extract Cisco VPN private keys. Will update as info comes. https://t.co/cObvedgf1l
— Mustafa Al-Bassam (@musalbas) 18. August 2016

Key takeaways:

The Shadow Brokers leak illustrates that the proposed technique to extract RSA private keys from memory dumps is easy to use, very effective in the wild and extensively field-tested by the Equation Group (widely believed to be operated by the NSA).
Specialized hardware, like a hardware security module (HSM) or a smartcard, can safeguard your cryptographic keys from such an attack.

A Bug Hunter's Diary

2011-11-08T15:28:00.000+01:00

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!

How to get gdb working on Apple iOS 4.3.x

2011-05-16T16:02:00.001+02:00

► 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.

checksec.sh now with FORTIFY_SOURCE support

2011-01-14T11:42:00.001+01:00

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.

Zone Crasher

2010-07-15T22:05:00.000+02:00

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.

checksec.sh now with kernel support

2010-05-04T20:14:00.001+02:00

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.

Split-process model FTW

2010-04-18T16:42:00.001+02:00

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.

"Kernel Bug" in Google Chrome

2010-04-02T10:53:00.001+02:00

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.

My new book just got released!

2010-03-30T20:37:00.001+02:00

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 ;)

The Fix That Never Was

2010-02-22T14:35:00.001+01:00

Approximately two years ago I found a memory corruption bug in one of the kernel drivers shipped with avast! 4.7. After I reported the bug to ALWIL Software they only took about two weeks to provide a fixed version. That's quite fast for a commercial software vendor. To be honest, I never checked if and how the bug was fixed with that new version. Anyway, a few weeks ago I decided to have a look at the avast! drivers again. While reversing the drivers I quickly realized that the measures taken by ALWIL Software to fix my 2 year old bug weren't sufficient.

► A Short Recap of the "old" Bug

Disassembly of the vulnerable aavmker4.sys driver (avast! 4.7, file version 4.7.1098.0):

[..] .text:00010E06    loc_10E06:  .text:00010E06      xor     edx, edx .text:00010E08      mov     eax, [ebp+v38_uc] .text:00010E0B      mov     [eax], edx .text:00010E0D      mov     [eax+4], edx .text:00010E10      add     esi, 4         ; src .text:00010E13      mov     ecx, 21Ah      ; len .text:00010E18      mov     edi, [eax+18h] ; dst .text:00010E1B      rep movsd              ; memcpy [..]

The memcpy() function at .text:00010E1B gets called with the following parameters:

memcpy (EDI, ESI, ECX);    EDI (dst): the value is extracted from user controlled IOCTL input data ESI (src): points to user controlled IOCTL input data ECX (len): 0x21A

As both the destination address as well as the source data of that memcpy() call could be controlled by the requesting user it was possible to overwrite arbitrary memory addresses with arbitrary values. This could be exploited to control the kernel execution flow and to execute arbitrary code at the kernel level. For more details see TKADV2008-002.

► The Fix

The "new" version of the kernel driver (avast! 4.8 <= 4.8.1368.0) implements the following check to remediate the described bug.

Disassembly of the vulnerable aavmker4.sys driver (avast! 4.8, file version 4.8.1356.0):

[..]  .text:00010F21    loc_10F21:   .text:00010F21      and    [ebp+var_4], 0  .text:00010F25      cmp    dword ptr [edi], 0  .text:00010F28      jz     loc_10FC5  .text:00010F2E [1]  mov    esi, [edi+870h]  .text:00010F34      mov    [ebp+v34_uc], esi  .text:00010F37      mov    eax, ds:MmUserProbeAddress  .text:00010F3C [2]  cmp    esi, [eax]      ; user space or kernel space? .text:00010F3E      jnb    short loc_10F46  [..]

Before the described memcpy() function is called a pointer value gets extracted from the user supplied IOCTL input data. That value is then stored in ESI (see [1]). Then it is checked if ESI points into user space or kernel space (see [2]). This is done by comparing the pointer with MmUserProbeAddress. If ESI points into kernel space, the memcpy() function gets called as before. If it points into user space memcpy() won't be called.

If ESI points into kernel space the following code gets executed:

[..]  .text:00010F99    loc_10F99:  .text:00010F99      xor    edx, edx  .text:00010F9B      mov    eax, [ebp+v34_uc]  .text:00010F9E      mov    [eax], edx  .text:00010FA0      mov    [eax+4], edx  .text:00010FA3      lea    esi, [edi+4]    ; src  .text:00010FA6      mov    ecx, 21Ah       ; len  .text:00010FAB      mov    edi, [eax+18h]  ; dst  .text:00010FAE      rep movsd              ; memcpy  [..]

The memcpy() function at .text:00010FAE gets called with the following parameters:

memcpy (EDI, ESI, ECX);    EDI (dst): the value is extracted from a user defined kernel space address ESI (src): points to user controlled IOCTL input data ECX (len): 0x21A

Assumption of the "new" check: As the destination address of memcpy() is now extracted from kernel space memory it isn't possible to directly control that value from user space anymore.

This only holds true if we weren't able to (temporarily) store user controlled data at a user defined address in kernel space. Unfortunately, the aavmker4.sys driver supports at least one IOCTL that allows an unprivileged user to temporarily store arbitrary data at a known kernel space address.

Well, the fix that never was ;)

► Exploitation

Exploiting this bug is quite easy:

STEP 1: Use one of the IOCTLs supported by aavmker4.sys to temporarily store arbitrary data at a known kernel space address (e.g. the IOCTL 0xb2d6001c).

STEP 2: Send a request to the vulnerable IOCTL. Store a pointer at offset 0x870 of the IOCTL data that points to the kernel space address of STEP 1.

STEP 3: Manipulate a function pointer.

STEP 4: Fun and profit.

Working out the rest of the attack is left as an exercise for the reader ;)

Affected are avast! 4.8 <= 4.8.1368.0 and avast! 5.0 < 5.0.418.0. See also my security advisory (TKADV2010-003) for further information.

► EIP Control

I wrote a proof of concept (poc) that gains control of the kernel execution flow (EIP control). Output of the kernel debugger when executing the poc (avast! 5.0 under Windows XP SP3):

#################### AAVMKER: WRONG RQ ######################! Access violation - code c0000005 (!!! second chance !!!) 41414141 ??              ???  kd> kb *** ERROR: Symbol file could not be found.  Defaulted to export symbols for Aavmker4.SYS -  ChildEBP RetAddr  Args to Child               WARNING: Frame IP not in any known module. Following frames may be wrong. edc99bdc f7955cae 8621ada8 e21f0030 00000001 0x41414141 edc99c34 804ee129 861f8030 866c0d98 806d22d0 Aavmker4+0xcae edc99c44 80574dde 866c0e08 865833c0 866c0d98 nt!IopfCallDriver+0x31 edc99c58 80575c7f 861f8030 866c0d98 865833c0 nt!IopSynchronousServiceTail+0x70 edc99d00 8056e4ec 000002f8 00000000 00000000 nt!IopXxxControlFile+0x5e7 edc99d34 8053d648 000002f8 00000000 00000000 nt!NtDeviceIoControlFile+0x2a edc99d34 7c91e514 000002f8 00000000 00000000 nt!KiFastCallEntry+0xf8 039cb1b0 65006e90 000002f8 b2d60034 039cb1fc 0x7c91e514 039cb24c 00000000 00000000 00000000 00000000 0x65006e90  kd> r eax=8621ada8 ebx=866c0d98 ecx=00000000 edx=00000000 esi=867d2bc0 edi=80527660 eip=41414141 esp=edc99be0 ebp=edc99c34 iopl=0         nv up ei pl nz na po nc cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202 41414141 ??              ???

If no kernel debugger is attached the poc gives the following BSoD:

iPhone OS and Mac OS X Stack Buffer Overflow

2010-02-02T22:01:00.001+01:00

My second security advisory in 2010 (TKADV2010-002) describes the details of a stack buffer overflow I found in CoreAudio of Apple's iPhone OS and Mac OS X. The bug can be triggered by playing a maliciously crafted mp4 audio file. Example attack vectors on the iPhone are MobileSafari and malicious ringtones.

Crashdump details:

[..] Process:         mediaserverd [17] Path:            /usr/sbin/mediaserverd  ..  Exception Type:  EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x41414140  ..  Unknown thread crashed with ARM Thread State:     r0: 0x6474613f    r1: 0x01380c40      r2: 0x380c561c      r3: 0x0000010d     r4: 0x41414141    r5: 0x41414141      r6: 0x41414141      r7: 0x41414141     r8: 0x41414141    r9: 0x00181494     r10: 0x41414141     r11: 0x41414141     ip: 0x00818000    sp: 0x01380c00      lr: 0x3072d454      pc: 0x41414140   cpsr: 0x60000030 [..]

Kernel NULL Pointer Dereference in (Open)Solaris

2010-01-31T12:17:00.001+01:00

Today I released a security advisory (TKADV2010-001) describing a NULL pointer dereference in the kernel of Oracle Solaris 10 and OpenSolaris (x86). The bug happens in processor microcode code when retrieving the microcode revision.

Debugging information (SunOS 5.10 Generic_139556-08 i86pc i386 i86pc):

> ::msgbuf [..] panic[cpu0]/thread=ffffffff87df87c0: BAD TRAP: type=e (#pf Page fault) rp=fffffe80012dcbf0 addr=0 occurred in module "unix" due to a NULL pointer dereference   poc: #pf Page fault Bad kernel fault at addr=0x0 pid=1471, pc=0xfffffffffb81e8f3, sp=0xfffffe80012dcce0, eflags=0x10286 cr0: 8005003b cr4: 6b0cr2: 0 cr3: 9f84000 cr8: c         rdi:                0 rsi:                1 rdx:               b6         rcx:                0  r8: ffffffff88050b20  r9: ffffffff87df87c0         rax:                0 rbx:                0 rbp: fffffe80012dccf0         r10:               f5 r11:                0 r12:                0         r13:                1 r14:                3 r15:           100001         fsb: ffffffff80000000 gsb: fffffffffbc278a0  ds:               43          es:               43  fs:                0  gs:              1c3         trp:                e err:                2 rip: fffffffffb81e8f3          cs:               28 rfl:            10286 rsp: fffffe80012dcce0          ss:               30  fffffe80012dcb00 unix:die+da () fffffe80012dcbe0 unix:trap+5e6 () fffffe80012dcbf0 unix:_cmntrap+140 () fffffe80012dccf0 unix:ucode_get_rev+53 () fffffe80012dcd80 ucode:ucode_ioctl+22e () fffffe80012dcd90 genunix:cdev_ioctl+1d () fffffe80012dcdb0 specfs:spec_ioctl+50 () fffffe80012dcde0 genunix:fop_ioctl+25 () fffffe80012dcec0 genunix:ioctl+ac () fffffe80012dcf10 unix:brand_sys_sysenter+1f2 ()  syncing file systems...  done dumping to /dev/dsk/c0d0s1, offset 110231552, content: kernel

Now that Oracle has completed its acquisition of Sun the Sun Alert for this vulnerability will be published in April as part of Oracle's next Critical Patch Update (CPU). The exact date would be 13 April 2010 as documented here.

Since the patch for Solaris 10 is already available and the diffs will be visible in the Mercurial repository and in the OpenSolaris source browser I chose not to wait until 13 April but published my advisory today.

checksec.sh with PaX support

2010-01-02T15:18:00.001+01:00

New checksec.sh release.

What's new with version 1.2:

* Additional PaX (http://pax.grsecurity.net/) checks   Thanks to Brad Spengler (grsecurity.net) for the PaX support.  * Some minor fixes (coloring adjusted, 'pidof' replacement)

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

New version of checksec.sh

2009-12-27T12:54:00.003+01:00

Modern Linux distributions offer some mitigation techniques to make it harder to exploit software vulnerabilities reliably. Mitigations such as RELRO, NoExecute (NX), Stack Canaries, Address Space Layout Randomization (ASLR) and Position Independent Executables (PIE) have made reliably exploiting any vulnerabilities that do exist far more challenging. The checksec.sh script is designed to test what standard Linux OS security features are being used.

While other mitigations do exist (e.g. grsecurity.net) these are not tested.

What's new with version 1.1:

* New '--proc-libs' option. This option instructs checksec.sh to test the loaded libraries of a process.   * Additional information on ASLR results (--proc, --proc-all, --proc-libs)   Thanks to Anthony G. Basile of the Tin Hat project for the hint.    * Additional CPU NX check (--proc, --proc-all, --proc-libs)

I tested the new version on Ubuntu 9.10, openSUSE 11.2 and Fedora 12.

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

Example of additional information on ASLR and NX results:

Example of the new '--proc-libs' option:

I joined the Twitterverse

2009-11-05T12:37:00.003+01:00

Of course, you should follow me on twitter here ;)

The Ringtone Massacre

2009-09-09T23:37:00.003+02:00

If you are an iPhone or iPod user then get the latest update of iPhone OS released today. This new version fixes a heap buffer overflow I found in CoreAudio of iPhone OS (see TKADV2009-007). The bug may be exploited by maliciously crafted AAC or MP3 files. This includes ringtones on the iPhone.

I'm sure you are only listening to AAC/MP3's you got from trusted sources, right? :>

!exploitable vs. TKADV2009-006 vs. Static Analysis Tools

2009-05-16T08:17:00.010+02:00

The following is the result of Microsoft's !exploitable Windbg extension while analyzing the libsndfile bug I released today (TKADV2009-006).

(3a8.62c): Access violation - code c0000005 (!!! second chance !!!) eax=00000000 ebx=0000ffff ecx=000029f1 edx=00000003 esi=02158008 edi=02166000 eip=7c34126b esp=04dbfa8c ebp=04dbfac0 iopl=0         nv up ei pl nz na pe cy cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000207 *** ERROR: Symbol file could not be found.  Defaulted to export symbols for  C:\Programme\Winamp\NSCRT.dll -  NSCRT!memset+0x49: 7c34126b f3ab            rep stos dword ptr es:[edi]  0:015> !load winext\msec.dll 0:015> !exploitable -v HostMachine\HostUser Executing Processor Architecture is x86 Debuggee is in User Mode Debuggee is a live user mode debugging session on the local machine Event Type: Exception Exception Faulting Address: 0x2166000 Second Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005) Exception Sub-Type: Write Access Violation  Exception Hash (Major/Minor): 0x21214e2e.0x67415f20  Stack Trace: NSCRT!memset+0x49 libsndfile!Ordinal9+0x290c2 libsndfile!Ordinal9+0x1994f libsndfile!Ordinal9+0x19eb9 libsndfile!sf_readf_double+0xd5f libsndfile!sf_open+0x89 in_wave+0x1276 kernel32!GetModuleFileNameA+0x1ba Instruction Address: 0x7c34126b  Description: User Mode Write AV Short Description: WriteAV Exploitability Classification: EXPLOITABLE Recommended Bug Title: Exploitable - User Mode Write AV starting at  NSCRT!memset+0x49 (Hash=0x21214e2e.0x67415f20)  User mode write access violations that are not near NULL are exploitable.

Erik, the libsndfile maintainer, also published an interesting blog entry regarding the security measures he took to secure libsndfile. Amongst others he checked his code base with static analysis tools. Unfortunately the bug described in TKADV2009-006 (as well as others) were missed. What a surprise :)

TKADV2009-005

2009-04-04T11:17:00.039+02:00

Today I released an advisory (TKADV2009-005) describing an integer overflow vulnerability in the Quicktime demuxer of xine-lib.

Debug session of the bug

tk@tk-desktop:~$ gdb -q xine

Adjusting the debugger environment:

(gdb) set disassembly-flavor intel  (gdb) directory /home/tk/Desktop/xine-lib-1.1.16.2/src/demuxers/ Source directories searched: /home/tk/Desktop/xine-lib-1.1.16.2/src/demuxers:$cdir:$cwd  (gdb) symbol-file /usr/lib/debug/usr/lib/xine/plugins/1.24/xineplug_decode_qt.so Load new symbol table from "/usr/lib/debug/usr/lib/xine/plugins/1.24/xineplug_decode_qt.so"? (y or n) y Reading symbols from /usr/lib/debug/usr/lib/xine/plugins/1.24/xineplug_decode_qt.so...done.

Set a breakpoint after calloc():

(gdb) break demux_qt.c:1550 No source file named demux_qt.c. Make breakpoint pending on future shared library load? (y or [n]) y  Breakpoint 1 (demux_qt.c:1550) pending.

Now let xine play our poc movie file:

(gdb) r Desktop/xine-lib_QuickTime_Bug/poc2.mov  Starting program: /usr/bin/xine Desktop/xine-lib_QuickTime_Bug/poc2.mov [Thread debugging using libthread_db enabled] [New Thread 0xb78646d0 (LWP 11878)] Dies ist xine (X11 gui) - Ein freier Video-Player v0.99.6cvs. (c) 2000-2007 Das xine Team. [New Thread 0xb76edb90 (LWP 11881)] [New Thread 0xb6eecb90 (LWP 11882)] [New Thread 0xb5d60b90 (LWP 11883)] [New Thread 0xb513bb90 (LWP 11884)] [New Thread 0xb48b8b90 (LWP 11885)] [New Thread 0xb3eb6b90 (LWP 11886)] [New Thread 0xb32ccb90 (LWP 11887)] [New Thread 0xb28feb90 (LWP 11888)] [New Thread 0xb1cf2b90 (LWP 11889)] [New Thread 0xb14f1b90 (LWP 11890)] [New Thread 0xb0cf0b90 (LWP 11891)] [New Thread 0xb0106b90 (LWP 11892)] [New Thread 0xaf905b90 (LWP 11893)] [New Thread 0xaed1bb90 (LWP 11894)] [New Thread 0xadcf3b90 (LWP 11895)] [New Thread 0xad4f2b90 (LWP 11896)] [Switching to Thread 0xb78646d0 (LWP 11878)]  Breakpoint 1, parse_moov_atom (info=0x8ec1978, moov_atom=0x8ec19e8 "", bandwidth=1544000) at demux_qt.c:1550 warning: Source file is more recent than executable. 1550       if (!trak->time_to_sample_table) {  (gdb) x/1i $eip 0xaccdefc8 <parse_moov_atom+1528>: test   eax,eax

EAX points to the overflow heap buffer allocated by calloc():

(gdb) i r eax eax            0x8e48d18 149196056

Content of the heap (before the overflow):

(gdb) x/8x 0x8e48d18 0x8e48d18: 0x00000000 0x00000000 0x00000000 0x00000000 0x8e48d28: 0x00000000 0x00000029 0x00000000 0xade1bcae

Breakpoint after the first written bytes:

(gdb) break 1563 Breakpoint 2 at 0xaccdf052: file demux_qt.c, line 1563.  (gdb) c Continuing.  Breakpoint 2, parse_moov_atom (info=0x8ec1928, moov_atom=0x8ec1998 "???]}??O?j??q?\212_?\022\177;J?w??h~/?o?]\204\032?_??`??\a????L?\234G?", bandwidth=0x178f40) at demux_qt.c:1565 1565       trak->time_to_sample_table[j].count = 0; /* terminate with zero */

The heap buffer is indeed overflowed with user controlled data from the Quicktime movie file:

(gdb) x/8x 0x8e48d18 0x8e48d18: 0x41414141 0x42424242 0x43434343 0x44444444 0x8e48d28: 0x45454545 0x46464646 0x47474747 0x48484848  (gdb) c Continuing.  Program received signal SIGSEGV, Segmentation fault.

checksec

2009-02-28T12:09:00.010+01:00

In my last blog post I described a script called "checkrelro.sh" that can be used to check if ELF executables or processes support the RELRO mitigation technique. I extended that script to also support other memory corruption mitigation techniques. The extended version is now called "checksec.sh" and is able to check Linux ELF executables and running processes if they support the following mitigation techniques: RELRO, Stack Canaries, NX, PIE and ASLR (for more information see Ubuntu, SUSE/Novell, Red Hat).

Example 1 - Check a single executable (Ubuntu 8.10):

Example 2 - Check all executables in a directory (Ubuntu 8.10):

Example 3 - Check a single process by name (Ubuntu 8.10):

Example 4 - Check all running processes (Ubuntu 8.10):

I successfully tested checksec under Ubuntu 8.10 and openSUSE 11.1.

~~Get checksec.sh here.~~ UPDATE (27.12.2009): A newer version of checksec.sh is available here. See also this link.

RELRO - A (not so well known) Memory Corruption Mitigation Technique

2009-02-21T09:11:00.021+01:00

After a discussion with Sebastian Krahmer about RELRO I did a little writeup on this memory corruption mitigation technique for my own purpose. I also decided to post it here just in case someone else might find this information valuable.

RELRO is a generic mitigation technique to harden the data sections of an ELF binary/process. There are two different "operation modes" of RELRO:

Partial RELRO

compiler command line: gcc -Wl,-z,relro
the ELF sections are reordered so that the ELF internal data sections (.got, .dtors, etc.) precede the program's data sections (.data and .bss)
non-PLT GOT is read-only
GOT is still writeable

Full RELRO

compiler command line: gcc -Wl,-z,relro,-z,now
supports all the features of partial RELRO
bonus: the entire GOT is also (re)mapped as read-only

Interim conclusion: In case of a bss or data overflow bug partial and full RELRO protect the ELF internal data sections from being overwritten (as the ELF sections are reordered). Only full RELRO mitigates the well known technique of modifying a GOT entry to get control over the program execution flow.

Testcases

The checkrelro.sh script can be used to test if an ELF binary or a process supports RELRO.

Recent Linux distris have partial RELRO enabled by default (e.g. Ubuntu 8.10 and openSUSE 11.1). There is therefore no difference between "gcc testcase.c" and "gcc -Wl,-z,relro testcase.c" on these platforms.

Testcase 1 (Ubuntu 8.10): Partial RELRO

File: testcase.c

#include <stdio.h>  int main (int argc, char *argv[]) {   size_t *p = (size_t *)strtol (argv[1], NULL, 16);    p[0] = 0x41414141;   printf ("RELRO: %p\n", p);    return 0; }

This test program tries to write the value 0x41414141 at a given memory address.

Compiling "testcase" with partial RELRO:

$ gcc -g -o testcase testcase.c

Test binary:

$ ./checkrelro.sh --file testcase testcase - partial RELRO

Get GOT entry of printf(3):

$ readelf -r ./testcase | grep printf 0804a00c  00000407 R_386_JUMP_SLOT   00000000   printf

Try to modify the GOT address:

$ gdb -q ./testcase (gdb) r 0x0804a00c Starting program: /home/tk/Desktop/testcase 0x0804a00c  Program received signal SIGSEGV, Segmentation fault. 0x41414141 in ?? ()

If only partial RELRO is used, it is still possible to modify arbitrary GOT entries to gain control of the execution flow of a process.

Testcase 2 (Ubuntu 8.10): Full RELRO

Compiling "testcase" with full RELRO:

$ gcc -g -Wl,-z,relro,-z,now -o testcase testcase.c

Test binary:

$ ./checkrelro.sh --file testcase  testcase - full RELRO

Get GOT entry of printf(3):

$ readelf -r ./testcase | grep printf 08049ff8  00000407 R_386_JUMP_SLOT   00000000   printf

Try to modify the GOT address:

$ gdb -q ./testcase (gdb) r 0x08049ff8 Starting program: /home/tk/Desktop/testcase 0x08049ff8  Program received signal SIGSEGV, Segmentation fault. 0x0804842b in main (argc=Cannot access memory at address 0x0 ) at testcase.c:8 8               p[0] = 0x41414141;

If full RELRO is enabled, the attempt to overwrite a GOT address leads to an error as the GOT section is mapped read-only.

How is RELRO used in recent Linux distris?

The checkrelro.sh script is also able to enumerate all processes running on a system and test each one of them if they have RELRO enabled.

Testcase 3 (Ubuntu 8.10): Inspect all running processes

$ sudo ./checkrelro.sh --proc-all init (1) - full RELRO vmware-guestd (15296) - no RELRO gedit (15771) - partial RELRO sshd (16181) - partial RELRO sshd (16193) - partial RELRO bash (16196) - no RELRO notification-da (16626) - partial RELRO udevd (2542) - partial RELRO getty (4382) - partial RELRO getty (4383) - partial RELRO getty (4390) - partial RELRO getty (4393) - partial RELRO getty (4395) - partial RELRO acpid (4563) - partial RELRO syslogd (4677) - partial RELRO dd (4729) - partial RELRO klogd (4731) - partial RELRO dbus-daemon (4754) - partial RELRO avahi-daemon (4776) - partial RELRO avahi-daemon (4777) - partial RELRO sshd (4806) - partial RELRO cupsd (4849) - partial RELRO hald (4913) - partial RELRO console-kit-dae (4916) - partial RELRO hald-runner (4979) - partial RELRO hald-addon-inpu (4999) - partial RELRO hald-addon-stor (5004) - partial RELRO hald-addon-acpi (5009) - partial RELRO bluetoothd (5055) - partial RELRO NetworkManager (5110) - partial RELRO wpa_supplicant (5115) - partial RELRO nm-system-setti (5118) - partial RELRO gdm (5148) - partial RELRO gdm (5151) - partial RELRO Xorg (5155) - partial RELRO system-tools-ba (5171) - partial RELRO atd (5206) - partial RELRO cron (5234) - partial RELRO dhclient (5236) - partial RELRO getty (5333) - partial RELRO gnome-keyring-d (5425) - partial RELRO x-session-manag (5436) - partial RELRO dbus-launch (5554) - partial RELRO dbus-daemon (5555) - partial RELRO pulseaudio (5558) - partial RELRO gconf-helper (5561) - partial RELRO gconfd-2 (5563) - partial RELRO seahorse-agent (5569) - partial RELRO gnome-keyring-d (5574) - partial RELRO gnome-settings- (5575) - partial RELRO metacity (5577) - partial RELRO gvfsd (5599) - partial RELRO gnome-panel (5600) - partial RELRO nautilus (5603) - partial RELRO bonobo-activati (5606) - partial RELRO gvfs-fuse-daemo (5610) - partial RELRO gnome-screensav (5630) - partial RELRO gvfs-hal-volume (5634) - partial RELRO gvfs-gphoto2-vo (5636) - partial RELRO trashapplet (5640) - partial RELRO gvfsd-trash (5643) - partial RELRO gvfsd-burn (5646) - partial RELRO fast-user-switc (5650) - partial RELRO mixer_applet2 (5653) - partial RELRO nm-applet (5655) - partial RELRO evolution-alarm (5658) - partial RELRO trackerd (5659) - partial RELRO update-notifier (5662) - partial RELRO tracker-applet (5663) - partial RELRO bluetooth-apple (5664) - partial RELRO python (5666) - partial RELRO gnome-power-man (5669) - partial RELRO gnome-terminal (5733) - partial RELRO gnome-pty-helpe (5735) - partial RELRO  # of Processes: 74 No RELRO      : 2 Partial RELRO : 71 Full RELRO    : 1

Testcase 4 (openSUSE 11.1): Inspect all running processes

tk@linux-0skt:~> sudo ./checkrelro.sh --proc-all init (1) - partial RELRO acpid (1599) - partial RELRO klogd (1621) - partial RELRO syslog-ng (1635) - partial RELRO dbus-daemon (1645) - partial RELRO hald (1734) - partial RELRO console-kit-dae (1746) - partial RELRO hald-runner (1818) - partial RELRO hald-addon-inpu (1880) - partial RELRO hald-addon-stor (1929) - partial RELRO rpcbind (1930) - partial RELRO hald-addon-stor (1931) - partial RELRO hald-addon-acpi (1933) - partial RELRO kdm (1966) - partial RELRO X (1982) - partial RELRO auditd (2173) - partial RELRO audispd (2175) - partial RELRO avahi-daemon (2194) - partial RELRO kdm (2227) - partial RELRO nscd (2286) - full RELRO NetworkManager (2290) - partial RELRO cupsd (2291) - partial RELRO modem-manager (2293) - partial RELRO dbus-launch (2294) - partial RELRO dbus-daemon (2297) - partial RELRO wpa_supplicant (2299) - partial RELRO nm-system-setti (2302) - partial RELRO master (2377) - partial RELRO pickup (2391) - partial RELRO qmgr (2392) - partial RELRO cron (2404) - partial RELRO dhclient (2475) - partial RELRO vmware-guestd (2484) - partial RELRO sshd (2485) - partial RELRO startpar (2488) - partial RELRO mingetty (2607) - partial RELRO mingetty (2609) - partial RELRO mingetty (2611) - partial RELRO mingetty (2613) - partial RELRO mingetty (2615) - partial RELRO mingetty (2622) - partial RELRO startkde (2658) - partial RELRO dbus-launch (3025) - partial RELRO dbus-daemon (3029) - partial RELRO kdeinit4 (3048) - partial RELRO klauncher (3052) - partial RELRO kded4 (3085) - partial RELRO kwrapper4 (3289) - partial RELRO ksmserver (3290) - partial RELRO kwin (3292) - partial RELRO plasma (3299) - partial RELRO knotify4 (3300) - partial RELRO krunner (3305) - partial RELRO nepomukserver (3307) - partial RELRO nepomukservices (3309) - partial RELRO nepomukservices (3310) - partial RELRO nepomukservices (3311) - partial RELRO kaccess (3315) - partial RELRO kmix (3325) - partial RELRO amarok (3327) - partial RELRO policykit-kde (3331) - partial RELRO pulseaudio (3334) - partial RELRO klipper (3336) - partial RELRO kupdateapplet (3340) - partial RELRO knetworkmanager (3341) - partial RELRO kdeinit (3346) - partial RELRO dcopserver (3349) - partial RELRO klauncher (3351) - partial RELRO kded (3354) - partial RELRO kio_file (3379) - partial RELRO konsole (3421) - partial RELRO bash (3423) - partial RELRO sshd (3436) - partial RELRO sshd (3439) - partial RELRO bash (3440) - partial RELRO krunner_lock (4565) - partial RELRO kblankscrn.kss (4567) - partial RELRO udevd (529) - partial RELRO  # of Processes: 78 No RELRO      : 0 Partial RELRO : 77 Full RELRO    : 1

Conclusion

In case of a bss or data overflow bug both partial and full RELRO protect the ELF internal data sections from being overwritten.

With full RELRO a working mitigation technique to successfully prevent the modification of GOT entries is available. But as the above testcases have shown, this mitigation technique is not used as default on current Linux distris. The only argument why full RELRO isn't widely used is that the startup of processes is slowed down as the linker has to perform all relocations at startup time.

In consequence the good old GOT overwrite technique can still be used today to get reliable control of the execution flow of a process while exploiting "write n bytes anywhere in memory" bugs like the one in FFmpeg. To gain reliable code execution from that point if ASLR and NX are also enabled is another story :)

There is another interesting writeup available that describes a generic way to implement a similar mitigation technique for ELF objects even if the platform doesn't support RELRO.

TKADV2009-004 vs. xine-lib

2009-02-15T14:11:00.007+01:00

Tomas Hoger from the Red Hat Security Response Team notified me that the 4xm demuxer of xine-lib seems to have the same origin with FFmpeg's version, and is therefore affected by a variant of the bug I described in TKADV2009-004.

xine-lib-1.1.16.1/src/demuxers/demux_4xm.c:

... 192 [1]   const uint32_t current_track = _X_LE_32(&header[i + 8]); 193       if (current_track + 1 > fourxm->track_count) { 194 [2]     fourxm->track_count = current_track + 1; 195 [3]     fourxm->tracks = realloc(fourxm->tracks, 196           fourxm->track_count * sizeof(audio_track_t)); 197         if (!fourxm->tracks) { 198           free(header); 199           return 0; 200         } 201       } ...

Unlike FFmpeg, "current_track" is unsigned in xine-lib (see [1]), therefore the exploitation vector described in TKADV2009-004 does not seem directly applicable. However, xine-lib's version of the 4xm demuxer is missing an integer overflow check prior to the allocation of the "fourxm->tracks" buffer (see [2] and [3]).

Tomas also identified a way to exploit this variant of TKADV2009-004: If the first track number is e.g. 0x10000000, a small "fourxm->tracks" array gets allocated in [3]. Subsequent tracks with numbers lower than 0x10000000 will not trigger the array reallocation in [3], but will cause an OOB write.

The bug is fixed in version 1.1.16.2 of xine-lib.

Thanks to Tomas for notification and filing the bug.

Exploitable Userland NULL Pointer Dereference

2009-01-28T20:51:00.018+01:00

Today I released a security advisory (TKADV2009-004) that describes the details of a very interesting vulnerability I found in FFmpeg. FFmpeg is a software solution to record, convert and stream audio and video. The FFmpeg libraries are used by a lot of popular software projects like VLC, Mplayer, Perian and Xine.

As I said, this vulnerability is quite interesting as it is another example for an exploitable NULL pointer dereference in an userland application.

The vulnerability

The initial vulnerability is a type conversion bug while converting an user controlled unsigned int value to a signed int.

.. fourxm->track_count = 0; .. current_track = AV_RL32(&header[i + 8]); ..

The AV_RL32() macro in the above code snippet reads an unsigned int value from the media file and stores the value in the signed int variable "current_track".

Later on "current_track" is checked against another value. If "current_track" is greater than this value a heap buffer pointed to by "fourxm->tracks" gets (re)allocated.

.. fourxm->tracks = NULL;  <-- [4] .. if (current_track + 1 > fourxm->track_count) {   fourxm->track_count = current_track + 1;  <-- [1]   if((unsigned)fourxm->track_count >= UINT_MAX /  <-- [3]         sizeof(AudioTrack))     return -1;   fourxm->tracks = av_realloc(fourxm->tracks,   fourxm->track_count * sizeof(AudioTrack));  <-- [2]   if (!fourxm->tracks) {     av_free(header);     return AVERROR(ENOMEM);   } } ..

If "current_track" is greater than "fourxm->track_count" the user controlled value of "current_track" is stored into "fourxm->track_count" (see [1]). The value of "fourxm->track_count" is then used to calculate the size of the heap buffer (see [2]). To avoid an integer overflow, the size of "fourxm->track_count" is checked before the allocation takes place (see [3]).

Now what happens if we supply a value >= 0x80000000 for "current_track"? Well, as there is an unchecked type conversion between unsigned and signed, "current_track" will become negative. If "current_track" is negative, the if statement shown above will always return false and the heap buffer will never be allocated. This results in "fourxm->tracks" still pointing to NULL (see [4]).

Directly after the if statement the following write operations are performed:

.. fourxm->tracks[current_track].adpcm = AV_RL32(&header[i + 12]); fourxm->tracks[current_track].channels = AV_RL32(&header[i + 36]); fourxm->tracks[current_track].sample_rate = AV_RL32(&header[i+40]); fourxm->tracks[current_track].bits = AV_RL32(&header[i + 44]); ..

As "fourxm->tracks" is pointing to NULL these write operations are leading to four classical NULL pointer dereferences. But as NULL is dereferenced by the user controlled value of "current_track" it is possible to write user controlled data to a wide range of memory locations.

Result:

NULL[current_track].offset = user_controlled_data;

As there are four write operations, four memory locations can be overwritten with arbitrary data.

Short summary:
"fourxm->tracks" is initialized with NULL
The type conversion bug allows us to avoid the allocation of "fourxm->tracks"
"fourxm->tracks" still points to NULL
The resulting NULL pointer is then dereferenced by the user controlled value of "current_track" and four 32bit values of user controlled data are assigned to the dereferenced location(s).
It is therefore possible to overwrite four user controlled memory locations with four user controlled data bytes each.

As I said, that's a beautiful bug.

Exploitability

In my advisory I wrote: "A malicious party may exploit this issue to execute arbitrary code by overwriting a sensitive memory location (such as a GOT/IAT entry, a return address, buffer length or boolean variable)". To see if this nice bug is indeed exploitable I chose the following two test cases:

VLC 0.9.8a under Windows XP SP3
Mplayer under openSUSE 11.1

As VLC and Mplayer are both using the FFmpeg libraries they are vulnerable to this bug.

Result: Reliable EIP control confirmed under both test cases

Here is the result for VLC under Windows XP SP3:

Here is the result for Mplayer under openSUSE 11.1:

tk@linux-0skt:~/Documents/ffmpeg-checkout-2009-01-02> gdb mplayer GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.  Type "show copying" and "show warranty" for details. This GDB was configured as "i586-suse-linux". For bug reporting instructions, please see: <http://bugs.opensuse.org/>... (no debugging symbols found)  (gdb) run ex_eip_control_mplayer.avi Starting program: /usr/bin/mplayer ex_eip_control_mplayer.avi (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] (no debugging symbols found) [...] MPlayer dev-SVN-r27637-4.3-openSUSE Linux 11.1 (i686)-Packman (C) 2000-2008 MPlayer Team CPU: Intel(R) Core(TM)2 Duo CPU     T7500  @ 2.20GHz (Family: 6, Model: 15, Stepping: 11) CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled with runtime CPU detection. Can't open joystick device /dev/input/js0: No such file or directory Can't init input joystick mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control.  Playing ex_eip_control_mplayer.avi. libavformat file format detected.  Program received signal SIGSEGV, Segmentation fault. 0x55555555 in ?? ()  (gdb) bt #0  0x55555555 in ?? () #1  0x77777777 in ?? () Cannot access memory at address 0x6666666a  (gdb) i r eax            0x0      0 ecx            0x8d4cce0        148163808 edx            0x160    352 ebx            0x806e13f6       -2140269578 esp            0xbfffcfbc       0xbfffcfbc ebp            0x8998f38        0x8998f38 esi            0x160    352 edi            0x8d59db0        148217264 eip            0x55555555       0x55555555 eflags         0x10297  [ CF PF AF SF IF RF ] cs             0x73     115 ss             0x7b     123 ds             0x7b     123 es             0x7b     123 fs             0x0      0 gs             0x33     5

As a bonus I developed a full working exploit (executes calc.exe) using VLC in version 0.9.8a as an injection vector.

Here is the result under Windows XP SP3.

Roundup:
This is a very nice bug ;)
Reliable EIP control confirmed while using Mplayer as injection vector under openSUSE 11.1 and VLC 0.9.8a under Windows XP SP3
Reliable code execution confirmed while using VLC 0.9.8a as injection vector under Windows XP SP3

GStreamer bugs

2009-01-22T21:07:00.004+01:00

I just released a security advisory (TKADV2009-003) describing the details of some heap buffer overflows and an array index out of bounds vulnerability I found in the GStreamer multimedia framework.

The following screenshot shows the result of a poc for the array index out of bounds vulnerability that can be exploited to write the value 0x00000001 to (nearly) any location in memory. I used Songbird as an injection vector as this music player (like many others) is using the GStreamer framework.

Note: EAX holds the user controlled value

Commercial usage of ScoopyNG

2009-01-14T22:23:00.004+01:00

Atempo Time Navigator is now officially using the VMware detection tricks of ScoopyNG. Thanks to Atempo for asking for permission instead of just using it without confirmation. I'm wondering what other software products are using ScoopyNG. Let me know if you know one.

Some statistics

2009-01-11T18:17:00.005+01:00

In my experience, open source projects are much faster in fixing security bugs than commercial vendors.

Current example:

Commercial product: Sun Solaris TKADV2009-001
Patch development time 115 days

Open source project: Amarok TKADV2009-002
Patch development time 7 days

The fact itself is not surprising as open source projects are normally not as tightly bound to business processes like commercial vendors. Nevertheless, the time difference is quite impressive.

Since a while I keep record of the "patch development time" in each of my security advisories. This is the time a vendor or open source project needed to provide a fix or patch for the vulnerability.

Here are some patch development time statistics of the vulnerabilities I reported so far:

Average patch development time of open source software projects:
(How long does it take open source projects to patch vulnerabilities?)

Average patch development time: 5.1 days
Total number of vulnerabilities: 8

Average patch development time of commercial software vendors:
(How long does it take commercial software vendors to patch vulnerabilities?)

Average patch development time: 169.9 days
Total number of vulnerabilities: 12

Well, I think these numbers are self-explanatory. I will keep these statistics updated under http://www.trapkit.de/advisories/pdts.php.