The Japanese version of the WPS remote code execution vulnerability detailed analysis-vulnerability warning-the black bar safety net

Overview

Word processing and work product in the vulnerability is the threat actors to exploit the useful target. Users often encounter in everyday life these software packages use the file type, and may in the email to open such a file, or be prompted to download from the website this file does not produce suspicion.

Some of the word processing software in the use of specific language in the community is widely used, but in other places, but little known. For example, Hancom Hangul word processing tools in South Korea widely used, from JustSystems’s Ichitaro Office Suite is widely used in Japan and the Japanese-Speaking communities. The use of these software and other similar word processing system of the vulnerability, an attacker can attack the target location to a specific country or its intended victim’s language community. Presumably, the attacker may believe, these system attacks are likely not too will be safe the researchers found, because they may lack the exploits of the necessary software.

Recently, Talos found 2 A use of the Hangul word processing tools to complex attacks. <http://blog.talosintelligence.com/2017/02/korean-maldoc.html&gt;, which emphasizes the attacker can create a malicious file with the necessary technology, and this malicious file is designed to aim its office software Suite.

Talos in Ichitaro Office Suite found three vulnerabilities, which software is Japanese most popular word processing program.

There is no indication that we are in Ichitaro Office Suite in the discovery of three vulnerabilities in any of the one already in the wild being used. However, these three kinds of vulnerability can cause an arbitrary code execution. We chose these vulnerabilities in a to explain in more detail how to exploit such a vulnerability, and by starting the calc. exe to demonstrate remote code execution meaning.

About this particular vulnerability of the recommendations, please visit <http://www.talosintelligence.com/reports/TALOS-2016-0197&gt;

In-depth exploration of - TALOS-2016-0197（CVE-2017-2790 - the JUSTSYSTEMS ICHITARO OFFICE EXCEL file code execution vulnerability

This vulnerability revolves around an unchecked integer underflow problem, the problem is because the Ichitaro processing XLS files to a workbook within the stream type is 0x3c when recording is not strictly check its length.

Read in next record of type 0x3c, app calculation needs to be copied to memory in number of bytes. This calculation relates to from the file itself to read the value of subtracting a value, which led to an integer underflow.

JCXCALC! JCXCCALC_Jsfc_ExConvert+0xa4b1e:
44b48cda 8b461e mov eax,dword ptr [esi+1Eh] // next record of the file data
44b48cdd 668b4802 mov cx,word ptr [eax+2] // taken from the file’s record length(in our case 0)
…
44b48ce4 6649 dec cx // 0 underflow to 0xffff
…
44b48ce8 894d08 mov dword ptr [ebp+8],ecx // save the value 0xffff behind the use of

Later in the same function, the underflow value is passed to the processing file data Copy Function.

JCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xa4b46: the

44b48d04 0fb75508 movzx edx, word ptr [ebp + 8] //0xffff is stored into edx
… …
44b48d1f 52 push edx //is pressed into the length of the
44b48d20 51 push ecx //is pressed into the destination address
44b48d21 83c005 add eax, 5 the
44b48d24 52 push edx //is pressed into the length of the
44b48d25 50 push eax //is pressed into the source address
44b48d26 e8c5f7ffff call JCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xa4334（44b484f0）

The main copy function does have a check to make sure that the length is greater than zero. Underflow the value of fly under the radar and pass all checks. The following is a use associated variable name comment the Copy Function. Note that, since in the above-described assemblies is pressed into the same register, the following C-code in the size and size_ are equal.

int JCXCALC! JCXCCALC_Jsfc_ExConvert+0xa4334(int src, int size, int dst, int size_)
{
int result;
result = 0;
if ( ! size_ )
return size;
if ( size > size_ )
return 0;
if ( size > 0 )
{
result = size;
do
{
*dst = *src++;
++dst;
–size;
}
while ( size );
}
return result;
}

the dst address is the address to the allocated memory, its size is also taken from the files of the TxO Record Type 0x1b6 it. This size is passed to malloc prior to the first multiplied by 2.

JCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xa4a1c: the
442c8bd8 668b470e mov ax, word ptr [edi + 0Eh] //from a TxO the size of the element
442c8bdc 50 push eax
442c8bdd e88b87f6ff call JCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xd1b1（4423136d）
JCXCALC it! JCXCCALC_Jsfc_ExConvert + 0xd1b1: the
4423136d 0fb7442404 movzx eax, word ptr [esp + 4]
44231372 d1e0 shl eax, 1 in //attacker size* 2
44231374 50 push eax
44231375 ff1580d42f44 call ds: malloc //controlled malloc
4423137b 59 pop ecx
4423137c c3 ret

All in all, the vulnerability to an attacker provides the following structure:

*Memory allocation length is controlled by the value multiplied by 2
*memcpy into a length of 0xffff in the memory allocation, the value is from the attacker-controlled file data to obtain the

Coverage of the target

If we want to on Windows 7 to exploit this vulnerability, the question now becomes, using memcpy coverage of Best goals? One approach might be to try to use virtual function overrides object’s vtable, so we can use the user control’s pointer to control the program counter.

In order to make the above become feasible, we need to use the following parameters to create:

*The object must be to be predicted the size of the allocation to the heap area
*The object must use a virtual function and has virtual table vtable to.
*The object must be in coverage occurs after being destroyed.

The XLS file consists of a plurality of document streams, where each stream are divided into different records. Each record can be described as a type - length - value TLV）structure. This means that each record will be the first few bytes specify its type, followed by the length of the record, the last is included in the recording by the length of the specified bytes of data.

A small figure as shown below:

• ------ + -------- + ------------ +
  | Type| length| value|
• ------ + -------- + ------------ +
  struct Record {
  uint16_t type;
  uint16_t length;
  byte [length] value;
  }}

As an example, the following is the type of 0x3c contains the 0xdeadbeef value of the record length is 4, because 0xdeadbeef is 4 bytes.

[1] [2] [3] [4] next