Secunia: Oracle Outside-In Technology SDW File Processing Buffer Overflow Vulnerability

[Rss Bot 1]

On October 18, 2016, Oracle released an update for Oracle Outside-In Technology as part of the Oracle Critical Patch Update for October 2016 [1] to fix a heap-based buffer overflow and a use-after-free vulnerability that have been discovered by Secunia Research [2]. Both of which may ultimately result in a system compromise through an application that uses and exposes the affected functionality of Oracle Outside-In Technology and thus are rated as “Highly Critical” by Secunia Research.

Additionally, Oracle addressed three further vulnerabilities discovered by Secunia Research that may result in a so-called “Denial of Service” (DoS) condition of an application using Oracle Outside-In Technology.

This blog post focusses on the heap-based buffer overflow vulnerability.

Product Background:

Oracle Outside-In Technology provides software developers with a comprehensive solution to access, transform, and control the contents of over 500 unstructured file formats [3].

This Oracle product is frequently bundled and used in many popular applications such as Microsoft Exchange, Novell GroupWise, and IBM WebSphere Portal.

File Format Background:

StarWriter files (SDW) are the default file format used by the StarWriter component of StarOffice versions prior to 5.x.

Vulnerability Summary:

The vulnerability is caused due to a boundary error within the “VwStreamRead()” function (vssdw.dll), which can be exploited to cause an out-of-bounds write memory access via a specially crafted SDW file and subsequently cause a crash of, or potentially execute arbitrary code within the context of, an application using the product Oracle Outside-In.

The vulnerability is confirmed in version 8.5.3 (vssdw.dll version 8.5.3.1604151004).

Technical Details:

A fixed-size heap memory block gets allocated by “VwAllocProc()” function, which is being used while processing SDW files:

.text:67AA1400                 push    esi
.text:67AA1401                 push    8FCh            ; dwBytes
.text:67AA1406                 push    0               ; dwFlags
.text:67AA1408                 call    ds:GetProcessHeap
.text:67AA140E                 push    eax             ; hHeap
.text:67AA140F                 call    ds:HeapAlloc
.text:67AA1415                 mov     esi, eax
.text:67AA1417                 test    esi, esi
.text:67AA1419                 jnz     short loc_67AA141D
.text:67AA141B                 pop     esi
.text:67AA141C                 retn
.text:67AA141D ; ---------------------------------------------------------------------------
.text:67AA141D
.text:67AA141D loc_67AA141D:                           ; CODE XREF: VwAllocProc+19
.text:67AA141D                 push    8FCh            ; size_t
.text:67AA1422                 push    0               ; int
.text:67AA1424                 push    esi             ; void *
.text:67AA1425                 call    memset
.text:67AA142A                 add     esp, 0Ch
.text:67AA142D                 mov     [esi+8F8h], esi
.text:67AA1433                 mov     eax, esi
.text:67AA1435                 pop     esi
.text:67AA1436                 retn
.text:67AA1436 VwAllocProc     endp

The function “VwStreamRead()” uses and manages this memory block while processing the SDW file. After some initialization, the function tries to read the bitmap stream embedded in the SDW file:

.text:67AA39F3 loc_67AA39F3:                           ; CODE XREF: VwStreamRead+13A4
.text:67AA39F3                 mov     eax, [esi+3Ch]
.text:67AA39F6                 dec     dword ptr [eax]
.text:67AA39F8                 js      short loc_67AA3A09
.text:67AA39FA                 mov     ecx, [esi+3Ch]
.text:67AA39FD                 mov     eax, [ecx+10h]
.text:67AA3A00                 movzx   edx, byte ptr [eax]
.text:67AA3A03                 inc     eax
.text:67AA3A04                 mov     [ecx+10h], eax
.text:67AA3A07                 jmp     short loc_67AA3A17
.text:67AA3A09 ; ---------------------------------------------------------------------------
.text:67AA3A09
.text:67AA3A09 loc_67AA3A09:                           ; CODE XREF: VwStreamRead+1378
.text:67AA3A09                 push    dword ptr [esi+3Ch]
.text:67AA3A0C                 call    sub_67AA3D90
.text:67AA3A11                 add     esp, 4
.text:67AA3A14                 movsx   edx, ax
.text:67AA3A17
.text:67AA3A17 loc_67AA3A17:                           ; CODE XREF: VwStreamRead+1387
.text:67AA3A17                 movzx   eax, di
.text:67AA3A1A                 inc     edi
.text:67AA3A1B                 mov     [eax+esi+470h], dl
.text:67AA3A22                 test    dl, dl
.text:67AA3A24                 jnz     short loc_67AA39F3

This loop ends when it reaches a Null byte in the stream. As the stream is user-controlled and there are no boundary checks, it’s possible to trigger an out-of-bounds write memory access. By overwriting vftable pointers, it’s possible to change the application’s flow:

.text:67AA3A59                 lea     ecx, [esi+470h]
.text:67AA3A5F                 lea     eax, [edi-2]
.text:67AA3A62                 mov     [ecx], ax
.text:67AA3A65                 push    dword ptr [esi+8F0h]
.text:67AA3A6B                 mov     eax, [esi+854h]
.text:67AA3A71                 push    dword ptr [esi+8ECh]
.text:67AA3A77                 push    ecx
.text:67AA3A78                 push    edi
.text:67AA3A79                 push    326h
.text:67AA3A7E                 call    eax
.text:67AA3A80                 push    dword ptr [esi+8F0h]
.text:67AA3A86                 mov     eax, [esi+854h]
.text:67AA3A8C                 push    dword ptr [esi+8ECh]
.text:67AA3A92                 push    0
.text:67AA3A94                 push    0
.text:67AA3A96                 push    327h
.text:67AA3A9B                 call    eax
.text:67AA3A9D                 push    dword ptr [esi+8F0h]
.text:67AA3AA3                 mov     eax, [esi+854h]
.text:67AA3AA9                 mov     ebx, 1
.text:67AA3AAE                 push    dword ptr [esi+8ECh]
.text:67AA3AB4                 push    0
.text:67AA3AB6                 push    0
.text:67AA3AB8                 push    325h
.text:67AA3ABD                 call    eax
.text:67AA3ABF                 mov     eax, 0E10h
.text:67AA3AC4                 add     esp, 3Ch
.text:67AA3AC7                 cmp     word ptr [esp+0D8h+var_C4], ax

0:000> g
ModLoad: 777d0000 77830000   C:WindowsSysWOW64IMM32.DLL
ModLoad: 75f40000 7600c000   C:Windowssyswow64MSCTF.dll
ModLoad: 709c0000 709ea000   C:UsersbehzadDesktopvw-8-5-3-win-x86-32sdkdemoscclo.dll
ModLoad: 709b0000 709bb000   C:UsersbehzadDesktopvw-8-5-3-win-x86-32sdkdemoSCCSD.DLL
ModLoad: 709a0000 709ad000   C:UsersbehzadDesktopvw-8-5-3-win-x86-32sdkdemoSCCXT.DLL
ModLoad: 70990000 70999000   C:UsersbehzadDesktopvw-8-5-3-win-x86-32sdkdemovssdw.dll
(c04.f64): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=34333231 ebx=00000d0d ecx=070bdb70 edx=00000000 esi=070bd700 edi=0001041d
eip=34333231 esp=0044e6bc ebp=070bffd8 iopl=0         nv up ei ng nz ac pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010297
34333231 ??              

This control puts an attacker ultimately in the position to potentially compromise an application using Oracle Outside-In Technology.

References:

[1] http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html#AppendixFMW[2] http://secunia.com/advisories/65000/[3] http://www.oracle.com/us/technologies/embedded/025613.htm

View the full article