Talos Vulnerability Report

Summary

A vulnerability was discovered within the Ichitaro word processor. Ichitaro is published by JustSystems and is considered one of the more popular word processors used within Japan. Ichitaro handles Microsoft Excel’s .xls file format. When processing a record type of 0x3c from a Workbook stream from an .xls, the application trusts that the size is greater than zero, subtracts one from the length, and uses this result as the size for a memcpy. This results in a heap-based buffer overflow and can lead to code-execution under the context of the application.

Tested Versions

JustSystems Ichitaro

Product URLs

http://www.ichitaro.com/

CVSSv3 Score

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Details

This vulnerability revolves around an unchecked integer underflow of the size of a Record of type 0x3c within a Workbook stream in an .xls file handled by Ichitaro.

The modules involved in the vulnerability are below (as described by lm vm in windbg):

start    end        module name
44aa0000 44ba3000   JCXCALC  C (export symbols)       C:\Program Files (x86)\JustSystems\JSLIB32\JCXCALC.DLL
    File version:     6.0.11.0
    Product version:  6.0.11.0

While reading a record of type 0x3c, the application calculates the number of bytes it needs to copy into memory. This calculation involves subtracting one from a value read from the file itself (offset 0x1afef in the provided sample) causing an integer underflow.

JCXCALC!JCXCCALC_Jsfc_ExConvert+0xa4b1e:
44b48cda 8b461e          mov     eax,dword ptr [esi+1Eh] // File data from 0x3c Record
44b48cdd 668b4802        mov     cx,word ptr [eax+2]     // Size from file (in our case 0)
...
44b48ce4 6649            dec     cx                      // Underflow the 0 to be 0xffff
...
44b48ce8 894d08          mov     dword ptr [ebp+8],ecx   // Store the 0xffff for later use

Later in the same function, this underflowed value is passed to the function handling the copying of file data.

JCXCALC!JCXCCALC_Jsfc_ExConvert+0xa4b46:
44b48d04 0fb75508        movzx   edx,word ptr [ebp+8]   // Store 0xffff into edx
...
44b48d1f 52              push    edx                    // Push size
44b48d20 51              push    ecx                    // Push destination address
44b48d21 83c005          add     eax,5
44b48d24 52              push    edx                    // Push size
44b48d25 50              push    eax                    // Push source address
44b48d26 e8c5f7ffff      call    JCXCALC!JCXCCALC_Jsfc_ExConvert+0xa4334 (44b484f0)

The main copy function does have a check to ensure that the size is greater than zero. The underflow value flys under the radar though and passes all checks. Below is the copy function commented with relevant variable names. Note, due to the same register being pushed in the above assembly, both size and size_ in the below C code 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 an allocation with size also from the file of the surrounding element with type 0x1b6 (offset 0x1afe5 in the provided sample). This size is multiplied by 2 before being passed to a malloc.

JCXCALC!JCXCCALC_Jsfc_ExConvert+0xa4a1c:
442c8bd8 668b470e        mov     ax,word ptr [edi+0Eh] // Size from 0x1b6 element
442c8bdc 50              push    eax
442c8bdd e88b87f6ff      call    JCXCALC!JCXCCALC_Jsfc_ExConvert+0xd1b1 (4423136d)

JCXCALC!JCXCCALC_Jsfc_ExConvert+0xd1b1:
4423136d 0fb7442404      movzx   eax,word ptr [esp+4]
44231372 d1e0            shl     eax,1
44231374 50              push    eax
44231375 ff1580d42f44    call    ds:malloc
4423137b 59              pop     ecx
4423137c c3              ret

Now that an attacker can control both the size of the allocation, trusted from the file, and the size of a memcpy, by leveraging an integer underflow, a heap-based buffer overflow can occur, which can lead to arbitary code execution.

Timeline

2016-08-29 - Vendor Disclosure
2017-02-24 - Public Release