Security
Headlines
HeadlinesLatestCVEs

Headline

CVE-2021-21943: TALOS-2021-1373 || Cisco Talos Intelligence Group

A heap-based buffer overflow vulnerability exists in the XWD parser functionality of Accusoft ImageGear 19.10. A specially-crafted file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability.

CVE
#vulnerability#mac#windows#microsoft#cisco#intel#perl#pdf#buffer_overflow

Summary

A heap-based buffer overflow vulnerability exists in the XWD parser functionality of Accusoft ImageGear 19.10. A specially-crafted file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability.

Tested Versions

Accusoft ImageGear 19.10

Product URLs

ImageGear - https://www.accusoft.com/products/imagegear-collection/

CVSSv3 Score

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

CWE

CWE-122 - Heap-based Buffer Overflow

Details

The ImageGear library is a document-imaging developer toolkit that offers image conversion, creation, editing, annotation and more. It supports more than 100 formats such as DICOM, PDF, Microsoft Office and others.

A specially-crafted XWD file can lead to a heap-based buffer overflow in the XWD parser, due to a missing size check.

Trying to load a malformed XWD file, we end up in the following situation:

(1b14.213c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=016304c8 ebx=000000f5 ecx=0000003b edx=00000001 esi=0aa34b38 edi=0bc05000
eip=6e9fe13d esp=0019f45c ebp=0019f474 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
MSVCR110!memcpy+0x21e:
6e9fe13d f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

The access violation is originated at [3] in the xwdread_pixmapformat_0_or_1 function:

void xwdread_pixmapformat_0_or_1
            (mys_table_function *param_1,uint param_2,XWD_read *xwd,undefined4 param_4,
            HIGDIBINFO param_5)

{
[...]

local_8 = DAT_102bcea8 ^ (uint)&stack0xfffffffc;
local_1d4 = param_2;
bytePerLine = (xwd->header_data).BytesPerLine;
error_code = 0;
local_1dc = xwd;
local_1e0 = param_5;
local_1ac = 0;
bytePerLine_ = bytePerLine;
dVar2 = IGDIBStd::DIB_bit_depth_get(param_5);
if (dVar2 == 1) {
    dst_buff_size = IO_raster_size_get(param_5);                                                        [1]
}
else {
    dst_buff_size = DIBStd_raster_size_get(param_5);
}
[...]

dst_buff = (byte *)AF_memm_alloc(local_1d4,dst_buff_size);                                              [2]

[...]
if ((error_code == 0) && (local_1d0 = error_code, height = DIB_height_get(local_1e0), 0 < height)) {
    do {
    depth_done = 0;
    if (pixmapDepth_ != 0) {
        io_buffer = local_1a8;
        do {
        src_buff = (byte *)get_data_from_file(io_buffer,bytePerLine_);
        array_of_source_buff[depth_done] = src_buff;
        if (src_buff == (byte *)0x0) {
            local_1ac = AF_err_record_set("..\\..\\..\\..\\Common\\Formats\\xwdread.c",0x2fc,-0x803,
                                        0,bytePerLine_,local_1d4,(LPCHAR)0x0);
            uVar11 = local_1d4;
            if (local_1ac != 0) goto LAB_101a44d0;
        }
        depth_done = depth_done + 1;
        piVar8 = (io_buffer *)&piVar8->size_buffer;
        } while (depth_done < pixmapDepth_);
        uVar11 = local_1d4;
        if (local_1ac != 0) break;
    }
    bytePerLine__ = bytePerLine_;
    [...]
    bit_depth = IGDIBStd::DIB_bit_depth_get(local_1e0);
    if (bit_depth == 1) {
        OS_memcpy(dst_buff,array_of_source_buff[0],bytePerLine__);                                      [3]
    }

The OS_memcpy function at [3] is a memcpy wrapper, so BytesPerLine bytes from array_of_source_buff[0] are copied to dst_buff. The BytesPerLine value and array_of_source_buff[0]’s content are taken directly from the XWD file. The destination buffer dst_buff is allocated at [2] using dst_buff_size as size.

The return value of the function IO_raster_size_get, that computes the dst_buff_size value at [1], in this specific case, is essentially: (PixmapWidth + 0x1f) >> 3) & 0xfffffffc.

It is evident that the size of dst_buff_size is only dependent on the PixmapWidth. The returned value of IO_raster_size_get is then used at [2] to allocate the dst_buff that is used as a temporary buffer to store, one at the time, the content of the bitmap’s “rows”. The problem is that neither PixmapWidth nor the calculated size are ever compared with the BytesPerLine variable. This allows the allocation of less space than required, leading to a heap-based buffer overflow.

Crash Information

0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


KEY_VALUES_STRING: 1

    Key  : AV.Fault
    Value: Write

    Key  : Analysis.CPU.mSec
    Value: 3046

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 9918

    Key  : Analysis.Init.CPU.mSec
    Value: 499

    Key  : Analysis.Init.Elapsed.mSec
    Value: 59454

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 141

    Key  : Timeline.OS.Boot.DeltaSec
    Value: 38712

    Key  : Timeline.Process.Start.DeltaSec
    Value: 59

    Key  : WER.OS.Branch
    Value: rs5_release

    Key  : WER.OS.Timestamp
    Value: 2018-09-14T14:34:00Z

    Key  : WER.OS.Version
    Value: 10.0.17763.1

    Key  : WER.Process.Version
    Value: 1.0.1.1


NTGLOBALFLAG:  2000000

APPLICATION_VERIFIER_FLAGS:  0

APPLICATION_VERIFIER_LOADED: 1

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 6e9fe13d (MSVCR110!memcpy+0x0000021e)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 0bc05000
Attempt to write to address 0bc05000

FAULTING_THREAD:  0000213c

PROCESS_NAME:  Fuzzme.exe

WRITE_ADDRESS:  0bc05000 

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

EXCEPTION_CODE_STR:  c0000005

EXCEPTION_PARAMETER1:  00000001

EXCEPTION_PARAMETER2:  0bc05000

STACK_TEXT:  
0019f460 6ebff9a6     0bc04ff8 0aa34b30 000000f5 MSVCR110!memcpy+0x21e
WARNING: Stack unwind information not available. Following frames may be wrong.
0019f474 6ed94489     0bc04ff8 0aa34b30 000000f5 igCore19d+0xf9a6
0019f6bc 6ed9517f     0019fc3c 1000001e 0019f718 igCore19d!IG_mpi_page_set+0x138459
0019f6e4 6ed93dfb     0019fc3c 1000001e 0ad9cff8 igCore19d!IG_mpi_page_set+0x13914f
0019fbb4 6ec313d9     0019fc3c 0ad9cff8 00000001 igCore19d!IG_mpi_page_set+0x137dcb
0019fbec 6ec708d7     00000000 0ad9cff8 0019fc3c igCore19d!IG_image_savelist_get+0xb29
0019fe68 6ec70239     00000000 05287fd0 00000001 igCore19d!IG_mpi_page_set+0x148a7
0019fe88 6ec05757     00000000 05287fd0 00000001 igCore19d!IG_mpi_page_set+0x14209
0019fea8 00402219     05287fd0 0019febc 00000001 igCore19d!IG_load_file+0x47
0019fec0 00402524     05287fd0 05289fe0 051edf50 Fuzzme!fuzzme+0x19
0019ff28 0040668d     00000005 051e6f50 051edf50 Fuzzme!fuzzme+0x324
0019ff70 765f0419     0030c000 765f0400 0019ffdc Fuzzme!fuzzme+0x448d
0019ff80 777a72ed     0030c000 ccadecfe 00000000 KERNEL32!BaseThreadInitThunk+0x19
0019ffdc 777a72bd     ffffffff 777c65e6 00000000 ntdll!__RtlUserThreadStart+0x2f
0019ffec 00000000     00406715 0030c000 00000000 ntdll!_RtlUserThreadStart+0x1b


STACK_COMMAND:  ~0s ; .cxr ; kb

SYMBOL_NAME:  MSVCR110!memcpy+21e

MODULE_NAME: MSVCR110

IMAGE_NAME:  MSVCR110.dll

FAILURE_BUCKET_ID:  INVALID_POINTER_WRITE_STRING_DEREFERENCE_NXCODE_FILL_PATTERN_AVRF_c0000005_MSVCR110.dll!memcpy

OS_VERSION:  10.0.17763.1

BUILDLAB_STR:  rs5_release

OSPLATFORM_TYPE:  x86

OSNAME:  Windows 10

IMAGE_VERSION:  11.0.50727.1

FAILURE_ID_HASH:  {4dd4b8b0-04bb-4a7d-d82a-fdf37d88888e}

Followup:     MachineOwner

Timeline

2021-09-10 - Initial contact
2021-09-14 - Vendor acknowledged and created support ticket
2021-09-21 - Vendor closed support ticket and confirmed under review with engineering team
2021-11-30 - 60 day follow up
2021-12-02 - Vendor advised release planned for Q1 2022
2021-12-07 - 30 day disclosure extension granted
2022-01-06 - Final disclosure notification
2022-02-23 - Public disclosure

Discovered by Francesco Benvenuto of Cisco Talos.

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907