Talos Vulnerability Report

TALOS-2017-0279

May 4, 2017

CVE Number

CVE-2017-2783

Summary

An exploitable heap corruption vulnerability exists in the FillRowFormat functionality of AntennaHouse DMC HTMLFilter that is shipped with MarkLogic 8.0-6. A specially crafted xls file can cause a heap corruption resulting in arbitrary code execution.
An attacker can send/provide malicious xls file to trigger this vulnerability.

Product URLs

CVSSv3 Score

Details

This vulnerability is present in the AntennaHouse DMC HTMLFilter which is used, among others, to convert xls files to (x)html form.
This product is mainly used by MarkLogic for xls document conversions as part of their web based document search and rendering engine.
A specially crafted XLS file can lead to an heap corruption and ultimately to remote code execution.

Let's investigate this vulnerability: after executing the XLS to html converter with malformed xls file as an input we can easily observe the following problem using Valgrind:

Allocation of buffer overflowed in FillRowFormat takes place exactly at line 10. Calculating allocation size value : 256 * 728 = 186368 we see its equal to the
value presented by valgrind. Of course an important fact to note is that this value is fixed.
Switching to the place where overflow appears, we see the following situation:

At line 8, we see the Size parameter of memset is the result of the multiplication of constant value 728 with the result of the subtraction of two WORD fields.
In this case, its size is equal to 0x5b2d8 which is much higher than allocated space for this buffer ( 186368 == 0x2d800).

Manipulations on 0x200 value are made at lines marked by an //XXX comment. As we can notice at line 5 that value is read directly from the file via the Exc_GetWord function and later stored at line 16.
During this entire procedure the value is checked once, at line 15 whether its bigger than some field. There is NO CHECK for an upper limit. We know now, seeing the code above that the value used for memset as a size argument
is read almost directly from the file. Looking for this value in our PoC file we can find it at offset : 0x3155. The entire record looks as follows:

`
An unsigned integer that specifies the zero-based column index of the column in the
sheet that contains this structure. MUST be greater than or equal to the colMic field of the
Dimensions record of the sheet that contains this structure and MUST be less than the colMac
field of the Dimensions record of the sheet that contains this structure. MUST be less than or equal
to 0x00FF.
`

We saw in the previous analysis that there was a check to see whether col is bigger than colMic, but that there was no check to ensure that col does not exceed colMac or 0x00FF, which led to the overflow.