Home / exploits

PDF

Intuit Help System Heap Corruption / Memory Leak

Posted on 31 March 2012

Intuit Help System Protocol URL Heap Corruption and Memory Leak

Derek Soeder
ds.adv.pub@gmail.com

Reported to security@intuit.com on March 15, 2012; vendor did not respond.
Reported to CERT on March 22, 2012; vendor did not respond.
Responsible disclosure failed with error code 10060.

Published: March 30, 2012

AFFECTED VENDOR
---------------
Intuit, Inc.

AFFECTED ENVIRONMENTS
---------------------
QuickBooks 2009 through QuickBooks 2012, in conjunction with Microsoft
Internet Explorer

UNAFFECTED ENVIRONMENTS
-----------------------
Unknown: other products, versions, and Web browsers have not been tested

IMPACT
------
The vulnerability described in this document can potentially be
exploited by malicious HTML and/or Javascript to execute arbitrary
code as the user viewing the malicious content.

VULNERABILITY DETAILS
---------------------
The Intuit Help System Async Pluggable Protocol ("intu-help-qb5:" in
QuickBooks 2012), implemented in HelpAsyncPluggableProtocol.dll, is
intended to provide access to ZIP-archived content stored on the local
file system for use in displaying QuickBooks' help pages. A URL takes
the following form:

 intu-help-qb#:path/archive.zip::file.ext?...

Here, '#' is a digit specific to the installed version of QuickBooks,
currently from 1 to 5; "path/archive.zip" is the path and file name of
a ZIP archive; "file.ext" is a non-empty file to retrieve from the
archive; and the ellipsis represents any number of optional query
field name-value pairs which may follow the question mark. Note that
if the "::" or "?" delimiter is missing, the process in which
HelpAsyncPluggableProtocol.dll is parsing the URL will crash on a null
pointer read. Due to a number of unchecked wcscpy_s and wcscat_s
calls targeting fixed-size buffers, most paths exceeding 260
characters--whether supplied explicitly or constructed
internally--will also cause the process to terminate.

For reference, QuickBooks 2012 recognizes the following query field names:

 qbexepath
 ocdpath
 img_pkg
 css_pkg
 js_pkg
 ocd_imgpkg
 ocd_csspkg
 ocd_jspkg
 fileref

Upon receiving a URL, HelpAsyncPluggableProtocol.dll first creates a
URL-decoded copy in a separate heap buffer. Decoding is performed by
a very simple loop that assumes each '%' character will be followed by
two hexadecimal digits, which it converts to an integer using
MSVCR90!wcstoul. Even if the loop encounters a '%' sequence in either
of the last two characters of the URL, it will still skip ahead by the
two characters after the '%', meaning it will skip over the null
terminator. The loop does not perform length checking, and so it will
continue to copy characters and decode '%' sequences even after the
bounds of the source and destination buffers have been exceeded. The
destination buffer (on the private heap) may therefore be overflowed
with the data following the source buffer (on the process heap).

EXPLOITATION
------------
One formidable complication in exploiting the overflow is that, while
the URLs passed to HelpAsyncPluggableProtocol.dll are wide character,
null-terminated strings (not BSTRs) allocated on the default process
heap, the buffers that HelpAsyncPluggableProtocol.dll allocates
internally with MSVCR90!malloc reside on a private heap belonging to
MSVCR90.DLL. Consequently, it is important to understand the sequence
of allocations, frees, and virtual calls pertaining to this heap. The
following log attempts to summarize the relevant operations: (Note
that all variable-size string buffers are allocated to the exact size
necessary to hold the source string and null terminator. All strings
are wide character unless noted otherwise.)

 A = new[0x1C] -- vtables at +0x00 and +0x04
 A->pvtbl_0->pfn_0__QueryInterface(A, IID_IInternetProtocolInfo, x)
 A->pvtbl_0->pfn_34(A, 1)
 delete A
 B = new[0x24] -- vtables at +0x00, +0x08, and +0x0C
 B->pvtbl_0->pfn_0__QueryInterface(B, IID_IUnknown, x)
 B->pvtbl_0->pfn_0__QueryInterface(B, IID_IInternetProtocol, x)
 B->pvtbl_8->pfn_4__AddRef(B+8)
 B->pvtbl_0->pfn_8__Release(B)
 B->pvtbl_8->pfn_4__AddRef(B+8)
 B->pvtbl_8->pfn_8__Release(B+8)
 B->pvtbl_8->pfn_0__QueryInterface(B+8, IID_IInternetPriority, x)
 B->pvtbl_0->pfn_0__QueryInterface(B, IID_IWinInetCacheHints, x)
 B->pvtbl_0->pfn_0__QueryInterface(B, IID_IInternetProtocolEx, x)
 B->pvtbl_8->pfn_C__IInternetProtocolRoot__Start(B+8, URL, x, x, x, x)
 C = new[0x18] -- no vtables
 D = malloc(0x208) -- persistent buffer for "<qbexepath><img_pkg>"
 E = malloc(0x208) -- persistent buffer for "<ocdpath><ocd_imgpkg>"
 F = malloc(0x208) -- persistent buffer for "fileref" value
 G = malloc(0x200) -- persistent buffer for MIME type
 H = malloc(x) -- *** buffer for URL-decoded URL ***
 *** URL decoding occurs, potential buffer overflow ***
 I = malloc(x) -- buffer for scheme ("intu-help-qb#")
 J = malloc(x) -- buffer for archive path and file name
 K = malloc(x) -- buffer for inner file path and name
 L = malloc(x) -- buffer for query string
 M1 = malloc(x) -- buffer for "qbexepath" value, if present
 M2 = malloc(x) -- buffer for "ocdpath" value, if present
 M3 = malloc(x) -- buffer for "img_pkg" value, if present
 M4 = malloc(x) -- buffer for "css_pkg" value, if present
 M5 = malloc(x) -- buffer for "js_pkg" value, if present
 M6 = malloc(x) -- buffer for "ocd_imgpkg" value, if present
 M7 = malloc(x) -- buffer for "ocd_csspkg" value, if present
 M8 = malloc(x) -- buffer for "ocd_jspkg" value, if present
 M9 = malloc(x) -- buffer for "fileref" value, if present
 free(L)
 free(I)
 free(J)
 free(K)
 free(M1)
 free(M2)
 free(M3)
 free(M4)
 free(M5)
 free(M6)
 free(M7)
 free(M8)
 free(M9)
 N = malloc(0x200)
 O = malloc(0x208)
 P = malloc(0x208)
 Q = malloc(0x208)
 free(P)
 R = new[0x18] -- vtable at +0x00
 S = malloc(x) -- buffer for wide character archive path and file name
 T = malloc(x) -- buffer for wide character inner file path and name
 U = malloc(x) -- buffer for multibyte archive path and file name
 V = malloc(x) -- buffer for multibyte inner file path and name
---- if archive was opened successfully ----
 W = malloc(0x404) -- destination buffer for MSVCR90!fread
 X = malloc(0x1000) -- MSVCR90!fread internal buffer
 free(W) -- if MSVCR90!fopen failed
 Y = malloc(0x80)
 ---- if inner file was found in archive ----
 Z = malloc(0x6C)
 AA = malloc(0x4000) -- decompression buffer
 BB = malloc(x) -- buffer for entire decompressed file
 free(AA)
 free(Z)
 ----
 free(X)
 free(Y)
----
 free(U)
 free(V)
 R->pvtbl_0->pfn_4(R)
---- if archive was opened successfully ----
 B->pvtbl_8->pfn_24__IInternetProtocol__Read(B+8, x, x, x)
 R->pvtbl_0->pfn_8(R, x, x, x)
 B->pvtbl_8->pfn_24__IInternetProtocol__Read(B+8, x, x, x)
 R->pvtbl_0->pfn_0(R)
 free(S)
 free(T)
 free(BB)
 R->pvtbl_0->pfn_C(R, 1)
 delete R
----
 B->pvtbl_8->pfn_18__IInternetProtocolRoot__Terminate(B+8, x)
 free(N)
 free(O)
 free(P) -- if not freed above
 free(Q)
 free(H)
 free(D)
 free(E)
 free(G)
 free(F)
 delete C
 B->pvtbl_0->pfn_8__Release(B)
 B->pvtbl_0->pfn_C(B, 1)
---- if archive was not opened ----
 R->pvtbl_0->pfn_C(R, 1)
 free(S)
 free(T)
 delete R
----
 delete B

The heap buffer labeled "H" is the buffer into which the original URL
is decoded. As it is assumed that the decoded URL may be the same
length as or shorter than the original URL, "H" is allocated with a
size of (wcslen(URL) * 2 + 2).

The "M" allocations can be performed in any order and can be repeated,
based on the sequence of field name-value pairs in the query string,
but each "M" free occurs only once. Therefore, if the query string
contains multiple instances of a particular recognized name-value
pair, only the buffer allocated for the last instance will be freed;
this allows an attacker to leak arbitrarily sized blocks of private
heap memory, up to roughly 4KB per malicious URL requested.

To summarize the above: The overflowable buffer, as well as some
targets of interest, are maintained on a private heap used exclusively
by MSVCR90.DLL, typically allocated and freed in roughly last-in,
first-out order. The most interesting targets are class instances
containing vtable pointers. Allocation of the overflowable buffer
occurs fairly early during URL processing and is followed immediately
by the vulnerable URL-decoding operation, meaning a successful attack
must 1) target whatever heap block header follows the overflowable
buffer; 2) cause the overflowable buffer to be allocated in a hole
that precedes a heap block of interest; and/or 3) attempt to use
asynchronous activity in the process to cause a worthwhile allocation
on the private heap, after the overflowable buffer is allocated but
before the overflow occurs. Abuse of other libraries that link to the
same version of MSVCR90.DLL and make use of its private heap is not
explored here.

Heap header overwrites are of course complicated by heap protections
in modern versions of Windows (as MSVCR90!malloc uses Windows' heap
management functions), and asynchronous activity sounds like more
trouble than it's worth for this particular vulnerability, so this
examination will focus on arranging for the overflowable buffer to
precede some target block, more specifically a class instance. As
depicted above, the only class instance that exists at the time of the
overflow and uses a vtable is the one labeled "B". Its size is 0x24
bytes, which Windows rounds up to a 0x28-byte allocation (in a 32-bit
environment); for comparison, the smallest URL that triggers the
overflow without ensuring process termination--the null-terminated,
wide character string "intu-help-qb#:::?%"--is 0x26 bytes, which also
rounds up to 0x28 bytes.

Unfortunately, however, "B" is the first block to be allocated (other
than the transient "A" block) and the last to be freed during URL
processing, and therefore it will typically occupy the first
sufficient free block. This means "B" will typically reside at the
same address each time it's allocated, unless some separate
functionality can be used to obstruct that address. Although query
string processing confers the ability to allocate and either free or
leak arbitrarily sized blocks in any order, these operations still
happen after "B" is allocated and before it is freed; assuming
classical heap behavior, they cannot help us. While sophisticated
heap manipulation based on special behaviors of the Windows heap
cannot be ruled out, it appears that this vulnerability accidentally
defies at least simple and obvious exploitation.

For the sake of completeness, the problem of crafting the source data
deserves mention. The URL passed to HelpAsyncPluggableProtocol.dll is
a null-terminated string which cannot contain embedded nulls--any
attempt to include a null character simply terminates the URL that
HelpAsyncPluggableProtocol.dll receives. Other than nulls and
unmatched surrogates (0xD800..0xDBFF not followed by 0xDC00..0xDFFF,
or the latter not preceded by the former), the URL can be constructed
to contain any desired characters, using either "uXXXX" sequences or
the "unescape" function in conjunction with "%uXXXX" encodings in
Javascript. However, because the decoding loop becomes indefinite
only after a "%<nul>" or "%X<nul>" sequence is encountered (which must
happen at the very end of the original URL, because nulls cannot be
embedded), and because the overflowable buffer is allocated to the
same apparent size as the original URL string, the fact is that the
overflow data cannot be included in the URL--the process heap must be
manipulated so that the URL string passed to
HelpAsyncPluggableProtocol.dll is followed shortly by the overflow
data. The overflow data need not be immediately adjacent--additional
"%XX" sequences can be placed within the URL to increase the distance
before the end of the destination buffer where post-URL data begins
filling the buffer.

If a null character is encountered in post-URL data before the buffer
is overflowed, it prevents the overflow but may present an opportunity
for information leakage. To avoid crashing the process, the
fully-decoded URL would still have to contain "::" and "?" delimiters,
meaning either the copied post-URL data must contain any missing
delimiters in proper order, or else it must be appended to the query
string. The only field currently believed to be transmissible to the
attacker is the archive path and file name field (which precedes the
"::" delimiter), and unfortunately this field is passed to wcstombs_s
before the archive is accessed, either stripping the string of most
useful information or stymieing the attack entirely if conversion
fails.

As a final note, the latest version of HelpAsyncPluggableProtocol.dll
supports SafeSEH but not ASLR, although its default image base address
of 0x10000000 increases its likelihood of being relocated due to
collision, assuming that other images sharing that base address are
not themselves being relocated by ASLR. The DLL remains loaded once
an "intu-help-qb#" URL has been accessed.

MITIGATION
----------

* Disable the Intuit Help System protocol

Delete, rename, or restrict read access to the
"HKEY_LOCAL_MACHINESOFTWARE[Wow6432Node]ClassesPROTOCOLSHandlerintu-help-qb#"
registry key (where '#' is a digit from 1 to 5 as of this writing), or
delete, rename, or restrict execute access to the
"HelpAsyncPluggableProtocol.dll" file in the QuickBooks installation
directory, and then restart Internet Explorer and any application that
uses it as an embedded Web browser. Note that disabling the protocol
will prevent QuickBooks from displaying help pages.

CONCLUSION
----------
This document describes a heap corruption vulnerability in Intuit
QuickBooks which could potentially be exploited via an Internet
Explorer-borne attack in order to execute arbitrary code as the
current user (and with low integrity, in the case of modern versions
of Internet Explorer on supporting operating systems). Successful
exploitation of the vulnerability has been neither proven nor ruled
out, although creation of a simple and straightforward exploit appears
unlikely.

GREETINGS
---------
www.ridgewayis.com
www.ftmband.com

 

TOP