Talos Vulnerability Report


Oracle OIT ImageExport libvs_bmp BMP BI_RLE8 Width Code Execution Vulnerability

July 19, 2016


A vulnerability in libvs_eshr can lead to remote code execution while parsing a specially crafted Word document containing a reference to Escher drawing.

Tested Versions

  • Oracle Outside In Technology Content Access SDK 8.5.1.

Product URLs



While parsing a malformed OLE file with a crafted DggInfo element contents a vulnerability in Escher drawing parsing library, libvs_eshr can be triggered. Changing the ID of the first child of DggContainer is changed form 0xF006 (Dgg) to 0xF007 (BSE) leads to parser confusion and ultimately a 4 byte value from the file is used as a pointer in a cmp instruction. If the comparison fails, the same pointer is used in an indirect call instruction leading to arbitrary code execution.

Technical information below:

In a supplied testcase, inside 1Table record, a DggInfo record is referenced startingat offset 0x25A8:

00025a0: 0108 0000 0600 0000 0f00 00f0 3800 0000  ............8...
00025b0: 0000 07f0 1800 0000 0204 0000 0200 0000  ................
00025c0: 0100 0000 0100 0000 0100 0000 0200 0000  ................
00025d0: 4000 1ef1 1000 0000 ffff 0000 0000 ff00  @...............
00025e0: 8080 8000 f700 0010 000f 0002 f092 0000  ................
00025f0: 0010 0008 f008 0000 0001 0000 0001 0400  ................
0002600: 000f 0003 f030 0000 000f 0004 f028 0000  .....0.......(..
0002610: 0001 0009 f010 0000 005f 3230 3132 5f54  ........._2012_T
0002620: 656d 706c 6174 652e 6402 000a f008 0000  emplate.d.......
0002630: 0000 0400 0005 0000 000f 0004 f042 0000  .............B..
0002640: 0012 000a f008 0000 0001 0400 0000 0e00  ................
0002650: 0053 000b f01e 0000 00bf 0100 0010 00cb  .S..............

There, a common header with DggContainer starts. In an unmodified file, the DggContainer contains a Dgg record (type 0xF006) starting at offset 0x25b2, but in the supplied testcase, this is changed to type 0xF007, or BSE record.

Details of the format can be found in http://www.digitalpreservation.gov/formats/digformatspecs/Word97-2007BinaryFileFormat(doc)Specification.pdf page 23 and http://www.digitalpreservation.gov/formats/digformatspecs/OfficeDrawing97-2007BinaryFormatSpecification.pdf detailing the OfficeDrawing format.

In the supplied testcase, with record type changed to 0xF007, a value at offset 0x2746 is used as an indirect operand in cmp instruction:

.text:B72766F2 push    ebp
.text:B72766F3 push    edi
.text:B72766F4 push    esi
.text:B72766F5 sub     esp, 10h
.text:B72766F8 mov     edi, eax
.text:B72766FA mov     [esp+1Ch+var_10], edx
.text:B72766FE cmp     word ptr [edx+7B4Ch], 59Eh [1]
.text:B7276707 jz      short loc_B7

At [1] the value of edx is used in a comparisson. Function at 0xB72766F2 (with image base 0xB7272000) uses usercall calling convention with edx containing the second parameter. If the value in edx doesn’t point to a readable memory address, the process will crash on a read access violation. If, however, it does point to valid memory, the execution will continue and the same value is subsequently used in the following basic block:

.text:B7284388 mov     ecx, [esp+1BCh+arg_C] 			[1]
.text:B728438F mov     eax, [ecx+95FCh]
.text:B7284395 mov     [esp+1BCh+var_1A8], eax
.text:B7284399 mov     eax, [ecx+95F8h]
.text:B728439F mov     [esp+1BCh+var_1AC], eax
.text:B72843A3 lea     eax, [esp+1BCh+var_48]
.text:B72843AA mov     [esp+1BCh+var_1B0], eax
.text:B72843AE mov     edx, edi
.text:B72843B0 movzx   eax, dl
.text:B72843B3 sub     eax, 1
.text:B72843B6 mov     [esp+1BCh+var_1B4], eax
.text:B72843BA mov     [esp+1BCh+var_1B8], 14B00000h
.text:B72843C2 lea     eax, [esp+1BCh+var_15A]
.text:B72843C6 mov     [esp+1BCh+var_1BC], eax
.text:B72843C9 call    dword ptr [ecx+94B 				[2]

At [1], a function argument value is copied from the stack into ecx and is ultimately used in an indirect call at [2]. Again, the value in ecx comes from the 4 byte little endian value at offset 0x2746 in the modified file.

Following gdb log shows the state of the process at the time of the crash:

Program received signal SIGSEGV, Segmentation fault.
0x6cc483f0 in ?? ()
(gdb) i r ecx
ecx            0xb7414141	-1220460223
(gdb) bt 3
#0  0x6cc483f0 in ?? ()
#1  0xb72843cf in ?? () from /home/ea/oit_office/sdk/demo/libvs_eshr.so
#2  0x00000001 in ?? ()
(More stack frames follow...)
(gdb) x/i 0xb72843cf-6
   0xb72843c9:	call   *0x94b4(%ecx)

Having full control over the value in ecx register, code execution can be achieved by pointing it to a controled piece of memory containing a pointer to the arbitrary code.

The vulnerability can be triggered with the supplied testcase in the ixsample application supplied with the SDK.


2015-10-19 - Discovery
2016-04-20 - Initial vendor communication
2016-07-19 - Public release


Discovered by Aleksandar Nikolic of Cisco Talos.

This vulnerability has not been disclosed and cannot be viewed at this time.