In GNOME Epiphany before 41.4 and 42.x before 42.2, an HTML document can trigger a client buffer overflow (in ephy_string_shorten in the UI process) via a long page title. The issue occurs because the number of bytes for a UTF-8 ellipsis character is not properly considered.

Merged requested to merge mcatanzaro/memory-corruption into master Apr 15, 2022

This reverts commit 232c6134.

I got my browser stuck in a crash loop today while visiting a website with a page title greater than ephy-embed.c's MAX\_TITLE\_LENGTH, the only condition in which ephy\_string\_shorten() is ever used. Turns out this commit is wrong: an ellipses is a multibyte character (three bytes in UTF-8) and so we're writing past the end of the buffer when calling strcat() here. Ooops.

Shame it took nearly four years to notice and correct this.

Edited Apr 15, 2022 by Michael Catanzaro

CVE-2022-29536: Fix memory corruption in ephy_string_shorten() (!1106) · Merge requests · GNOME / Epiphany · GitLab

Stack buffer overflow issues were found in Opensc before version 0.22.0 in various places that could potentially crash programs using the library.

@@ -159,7 +159,7 @@ static int cardos\_have\_2048bit\_package(sc\_card\_t \*card)

sc\_apdu\_t apdu;

u8 rbuf\[SC\_MAX\_APDU\_BUFFER\_SIZE\];

int r;

const u8 \*p = rbuf, \*q;

const u8 \*p = rbuf, \*q, \*pp;

size\_t len, tlen = 0, ilen = 0;

  

sc\_format\_apdu(card, &apdu, SC\_APDU\_CASE\_2\_SHORT, 0xca, 0x01, 0x88);

@@ -175,10 +175,10 @@ static int cardos\_have\_2048bit\_package(sc\_card\_t \*card)

return 0;

  

while (len != 0) {

p = sc\_asn1\_find\_tag(card->ctx, p, len, 0xe1, &tlen);

if (p == NULL)

pp = sc\_asn1\_find\_tag(card->ctx, p, len, 0xe1, &tlen);

if (pp == NULL)

return 0;

q = sc\_asn1\_find\_tag(card->ctx, p, tlen, 0x01, &ilen);

q = sc\_asn1\_find\_tag(card->ctx, pp, tlen, 0x01, &ilen);

if (q == NULL || ilen != 4)

return 0;

if (q\[0\] == 0x1c)

CVE-2021-42782: cardos: Correctly calculate the left bytes to avoid buffer overrun · OpenSC/OpenSC@1252aca

An exploitable code execution vulnerability exists in the file format parsing functionality of Graphisoft BIMx Desktop Viewer 2019.2.2328. A specially crafted file can cause a heap buffer overflow resulting in a code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

An exploitable code execution vulnerability exists in the file format parsing functionality of Graphisoft BIMx Desktop Viewer 2019.2.2328. A specially crafted file can cause a heap buffer overflow resulting in a code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

Graphisoft BIMx Desktop Viewer 2019.2.2328

**Product URLs**

https://www.graphisoft.com/downloads/bimx/bimx\_desktop.html

**CVSSv3 Score**

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

**CWE**

CWE-680 - Integer Overflow to Buffer Overflow

**Details**

BIMx Desktop Viewer allows for models created by Graphisoft ArchiCad to be shared and viewed by anyone. With Desktop Viewer, clients can view their prospective models without the need of having to install the entire suite of tools needed to create the model itself.

The modules used in this vulnerability are below:

    00007ff77c5f0000 00007ff77c818000   BIMx       (deferred)
        Image path: BIMx.exe
        Image name: BIMx.exe
        Timestamp:        Wed Jun  5 08:09:29 2019 (5CF7BF09)
        CheckSum:         00000000
        ImageSize:        00228000
        File version:     2019.2.2328.0
        Product version:  2019.2.2328.0
    

The BIMx file format is composed of a variety of resource files which are read and written to disk before processed. To begin processing a given resource file, a 520 byte chunk is read from the file.

    bimx+55c20
    .text:0000000000055C20  mov  r9, r14                 ; Input File Stream
    .text:0000000000055C23  mov  edx, 208h               ; Number of elements to read
    .text:0000000000055C28  mov  r8d, 1                  ; Size of each elements
    .text:0000000000055C2E  lea  rcx, [rbp+3F0h+var_470] ; Output buffer
    .text:0000000000055C32  call cs:fread                ; Call fread
    

This file chunk contains the name of the resource along with the number of bytes contained in this resource. This chunk looks like the following struct:

    struct ResourceHeader {
        name: [u8; 512],
        offset_to_struct: u32,
        length_of_data: u32,
    }
    

The application then allocates enough memory to fill with the resource bytes. Along with the resource bytes, themselves, the allocation can also contain an attribute or note of what the allocation is for.

    bimx+78572
    .text:0000000000078572  inc     rbx                    ; Increment note pointer
    .text:0000000000078575  cmp     byte ptr [rdx+rbx], 0  ; Check if we found the end of the note
    .text:0000000000078579  jnz     short loc_78572        ; Continue incrementing
    

The application then calculates the length of the note and then adds that to the found number of bytes for this resource for the final allocation.

    bimx+78589
    .text:0000000000078589  lea     eax, [rbx+6]
    .text:000000000007858C  cdq
    .text:000000000007858D  and     edx, 0Fh
    .text:0000000000078590  lea     edi, [rdx+rax]
    .text:0000000000078593  sar     edi, 4
    .text:0000000000078596  inc     edi
    .text:0000000000078598  shl     edi, 4
    .text:000000000007859B  lea     ecx, [rdi+r15]  ; Final add of resource bytes and note length
    .text:000000000007859F  movsxd  rcx, ecx        
    .text:00000000000785A2  call    cs:__imp_malloc
    

Assuming there is no problem with the allocation, the entire allocation is set to 0 and then filled with the resource bytes.

    bimx+785b0
    .text:00000000000785B0                 movsxd  rdi, edi        ;
    .text:00000000000785B3                 mov     edx, 0AAh       ; Memset the note bytes to 0xaa
    .text:00000000000785B8                 mov     r8, rdi         ; Allocation note size
    .text:00000000000785BB                 mov     [rsp+38h+arg_0], rbp
    .text:00000000000785C0                 mov     rcx, r14        ; void *
    .text:00000000000785C3                 call    memset
    .text:00000000000785C8                 lea     rbp, [rdi+r14]  ; Address after the allocation note
    .text:00000000000785CC                 mov     r8, r15         ; Number of resource bytes
    .text:00000000000785CF                 mov     rcx, rbp          
    .text:00000000000785D2                 xor     edx, edx        ; Fill with 0
    .text:00000000000785D4                 call    memset
    .text:00000000000785D9                 movzx   edi, bl
    .text:00000000000785DC                 mov     rdx, rsi        ; Allocation note
    .text:00000000000785DF                 mov     r8d, edi        ; Allocation note length
    .text:00000000000785E2                 mov     rcx, r14        ; New allocation
    .text:00000000000785E5                 call    memcpy
    

It is possible for an attacker to overflow the malloc allocation size after adding the resource length. This will result in an allocation that is smaller than requested. Since the allocation is smaller than expected, the memset and the memcpy cause an out of bounds write on a heap buffer, potentially resulting in a code execution.

**Crash Information**

(1bd9c.1bda4): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. \*\*\* WARNING: Unable to verify checksum for BIMx.exe VCRUNTIME140!memset\_repmovs+0x9: 00007ffb\`d8f91689 f3aa rep stos byte ptr \[rdi\]

**Timeline**

2020-03-26 - Initial contact  
2020-03-31 - Vendor disclosure  
2020-06-30 - 90 day notice  
2020-07-03 - Vendor advised reports filtered as spam  
2020-07-07 - Issued copy of reports & vendor confirmed  
2020-07-28 - Vendor advised new version will address issue mid September  
2020-09-15 - Follow up with vendor; no response  
2020-11-06 - Public Release

Discovered by Cory Duplantis of Cisco Talos.

CVE-2020-6099: TALOS-2020-1032 || Cisco Talos Intelligence Group

**SUMMARY**

An exploitable code execution vulnerability exists in the file format parsing functionality of Graphisoft BIMx Desktop Viewer 2019.2.2328. A specially crafted file can cause a heap buffer overflow resulting in a code execution. 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.

Graphisoft BIMx Desktop Viewer 2019.2.2328

**PRODUCT URLS**

BIMx Desktop Viewer - https://www.graphisoft.com/downloads/bimx/bimx\_desktop.html

**CVSSv3 SCORE**

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

**CWE**

CWE-680 - Integer Overflow to Buffer Overflow

**DETAILS**

BIMx Desktop Viewer allows for models created by Graphisoft ArchiCad to be shared and viewed by anyone. With Desktop Viewer, clients can view their prospective models without the need of having to install the entire suite of tools needed to create the model itself.

The modules used in this vulnerability are below:

    00007ff77c5f0000 00007ff77c818000   BIMx       (deferred)
        Image path: BIMx.exe
        Image name: BIMx.exe
        Timestamp:        Wed Jun  5 08:09:29 2019 (5CF7BF09)
        CheckSum:         00000000
        ImageSize:        00228000
        File version:     2019.2.2328.0
        Product version:  2019.2.2328.0
    

The BIMx file format is composed of a variety of resource files which are read and written to disk before processed. To begin processing a given resource file, a 520 byte chunk is read from the file.

    bimx+55c20
    .text:0000000000055C20  mov  r9, r14                 ; Input File Stream
    .text:0000000000055C23  mov  edx, 208h               ; Number of elements to read
    .text:0000000000055C28  mov  r8d, 1                  ; Size of each elements
    .text:0000000000055C2E  lea  rcx, [rbp+3F0h+var_470] ; Output buffer
    .text:0000000000055C32  call cs:fread                ; Call fread
    

This file chunk contains the name of the resource along with the number of bytes contained in this resource. This chunk looks like the following struct:

    struct ResourceHeader {
        name: [u8; 512],
        offset_to_struct: u32,
        length_of_data: u32,
    }
    

The application then allocates enough memory to fill with the resource bytes. Along with the resource bytes, themselves, the allocation can also contain an attribute or note of what the allocation is for.

    bimx+78572
    .text:0000000000078572  inc     rbx                    ; Increment note pointer
    .text:0000000000078575  cmp     byte ptr [rdx+rbx], 0  ; Check if we found the end of the note
    .text:0000000000078579  jnz     short loc_78572        ; Continue incrementing
    

The application then calculates the length of the note and then adds that to the found number of bytes for this resource for the final allocation.

    bimx+78589
    .text:0000000000078589  lea     eax, [rbx+6]
    .text:000000000007858C  cdq
    .text:000000000007858D  and     edx, 0Fh
    .text:0000000000078590  lea     edi, [rdx+rax]
    .text:0000000000078593  sar     edi, 4
    .text:0000000000078596  inc     edi
    .text:0000000000078598  shl     edi, 4
    .text:000000000007859B  lea     ecx, [rdi+r15]  ; Final add of resource bytes and note length
    .text:000000000007859F  movsxd  rcx, ecx        
    .text:00000000000785A2  call    cs:__imp_malloc
    

Assuming there is no problem with the allocation, the entire allocation is set to 0 and then filled with the resource bytes.

    bimx+785b0
    .text:00000000000785B0                 movsxd  rdi, edi        ;
    .text:00000000000785B3                 mov     edx, 0AAh       ; Memset the note bytes to 0xaa
    .text:00000000000785B8                 mov     r8, rdi         ; Allocation note size
    .text:00000000000785BB                 mov     [rsp+38h+arg_0], rbp
    .text:00000000000785C0                 mov     rcx, r14        ; void *
    .text:00000000000785C3                 call    memset
    .text:00000000000785C8                 lea     rbp, [rdi+r14]  ; Address after the allocation note
    .text:00000000000785CC                 mov     r8, r15         ; Number of resource bytes
    .text:00000000000785CF                 mov     rcx, rbp          
    .text:00000000000785D2                 xor     edx, edx        ; Fill with 0
    .text:00000000000785D4                 call    memset
    .text:00000000000785D9                 movzx   edi, bl
    .text:00000000000785DC                 mov     rdx, rsi        ; Allocation note
    .text:00000000000785DF                 mov     r8d, edi        ; Allocation note length
    .text:00000000000785E2                 mov     rcx, r14        ; New allocation
    .text:00000000000785E5                 call    memcpy
    

It is possible for an attacker to overflow the malloc allocation size after adding the resource length. This will result in an allocation that is smaller than requested. Since the allocation is smaller than expected, the memset and the memcpy cause an out of bounds write on a heap buffer, potentially resulting in a code execution.

**Crash Information**

(1bd9c.1bda4): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. \*\*\* WARNING: Unable to verify checksum for BIMx.exe VCRUNTIME140!memset\_repmovs+0x9: 00007ffb\`d8f91689 f3aa rep stos byte ptr \[rdi\]

**TIMELINE**

2020-03-26 - Initial contact  
2020-03-31 - Vendor disclosure  
2020-06-30 - 90 day notice  
2020-07-03 - Vendor advised reports filtered as spam  
2020-07-07 - Issued copy of reports & vendor confirmed  
2020-07-28 - Vendor advised new version will address issue mid September  
2020-09-15 - Follow up with vendor; no response  
2020-11-06 - Public Release

Discovered by Cory Duplantis of Cisco Talos.

Heap buffer overflow issues were found in Opensc before version 0.22.0 in pkcs15-oberthur.c that could potentially crash programs using the library.

'2016439?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2021-42781: Invalid Bug ID

global heap buffer overflow in skip_range in GitHub repository vim/vim prior to 8.2.4763. This vulnerability is capable of crashing software, Bypass Protection Mechanism, Modify Memory, and possible remote execution

**✍️ Description**

When fuzzing vim commit f420ff244 v8.2.4747 with clang 13 and ASan, I discovered a global buffer overflow.

**Proof of Concept**

Here is the minified poc

    r<sfile>
    0norm0V:^[
    

How to build

    LD=lld AS=llvm-as AR=llvm-ar RANLIB=llvm-ranlib CC=clang CXX=clang++ CFLAGS="-fsanitize=address" CXXFLAGS="-fsanitize=address" LDFLAGS="-ldl -fsanitize=address" ./configure --with-features=huge --enable-gui=none
    make -j$(nproc)
    

Proof of Concept

Run crafted file with this command

./vim -u NONE -X -Z -e -s -S poc_skip_range_min -c :qa!

ASan stack trace:

    aldo@vps:~/vim/src$ ASAN_OPTIONS=symbolize=1 ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer ./vim -u NONE -X -Z -e -s -S poc_skip_range_min -c :qa!
    =================================================================
    ==3301533==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000f3489b at pc 0x0000006dcf37 bp 0x7fffffff5b90 sp 0x7fffffff5b88
    READ of size 1 at 0x000000f3489b thread T0
        #0 0x6dcf36 in skip_range /home/aldo/vimtes/src/ex_docmd.c:4039:62
        #1 0x6ce745 in do_one_cmd /home/aldo/vimtes/src/ex_docmd.c:1826:11
        #2 0x6c93f2 in do_cmdline /home/aldo/vimtes/src/ex_docmd.c:992:17
        #3 0x914a95 in nv_colon /home/aldo/vimtes/src/normal.c:3191:19
        #4 0x8f7ced in normal_cmd /home/aldo/vimtes/src/normal.c:930:5
        #5 0x6fa35d in exec_normal /home/aldo/vimtes/src/ex_docmd.c:8730:6
        #6 0x6f9f63 in exec_normal_cmd /home/aldo/vimtes/src/ex_docmd.c:8693:5
        #7 0x6f9cc3 in ex_normal /home/aldo/vimtes/src/ex_docmd.c:8611:6
        #8 0x6d56c2 in do_one_cmd /home/aldo/vimtes/src/ex_docmd.c:2567:2
        #9 0x6c93f2 in do_cmdline /home/aldo/vimtes/src/ex_docmd.c:992:17
        #10 0xafb875 in do_source_ext /home/aldo/vimtes/src/scriptfile.c:1665:5
        #11 0xaf92c0 in do_source /home/aldo/vimtes/src/scriptfile.c:1791:12
        #12 0xaf8df9 in cmd_source /home/aldo/vimtes/src/scriptfile.c:1165:14
        #13 0xaf88dd in ex_source /home/aldo/vimtes/src/scriptfile.c:1191:2
        #14 0x6d56c2 in do_one_cmd /home/aldo/vimtes/src/ex_docmd.c:2567:2
        #15 0x6c93f2 in do_cmdline /home/aldo/vimtes/src/ex_docmd.c:992:17
        #16 0x6cc680 in do_cmdline_cmd /home/aldo/vimtes/src/ex_docmd.c:586:12
        #17 0xed3ca4 in exe_commands /home/aldo/vimtes/src/main.c:3104:2
        #18 0xed19d9 in vim_main2 /home/aldo/vimtes/src/main.c:780:2
        #19 0xecb2c0 in main /home/aldo/vimtes/src/main.c:432:12
        #20 0x7ffff78240b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
        #21 0x41edcd in _start (/home/aldo/vimtes/src/vim+0x41edcd)
    
    0x000000f3489b is located 5 bytes to the left of global variable '<string literal>' defined in 'ex_docmd.c:2821:27' (0xf348a0) of size 2
      '<string literal>' is ascii string '+'
    0x000000f3489b is located 53 bytes to the right of global variable '<string literal>' defined in 'ex_docmd.c:2795:9' (0xf34860) of size 6
      '<string literal>' is ascii string ''<,'>'
    SUMMARY: AddressSanitizer: global-buffer-overflow /home/aldo/vimtes/src/ex_docmd.c:4039:62 in skip_range
    Shadow bytes around the buggy address:
      0x0000801de8c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0000801de8d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0000801de8e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 f9
      0x0000801de8f0: f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9 00 00 04 f9
      0x0000801de900: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 06 f9 f9 f9
    =>0x0000801de910: f9 f9 f9[f9]02 f9 f9 f9 f9 f9 f9 f9 00 02 f9 f9
      0x0000801de920: f9 f9 f9 f9 00 03 f9 f9 f9 f9 f9 f9 07 f9 f9 f9
      0x0000801de930: f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
      0x0000801de940: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
      0x0000801de950: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 02 f9 f9
      0x0000801de960: f9 f9 f9 f9 07 f9 f9 f9 f9 f9 f9 f9 05 f9 f9 f9
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==3301533==ABORTING
    

**💥 Impact**

This vulnerability is capable of crashing software, Bypass Protection Mechanism, Modify Memory, and possible remote execution

**Impact**

This vulnerability is capable of crashing software, Bypass Protection Mechanism, Modify Memory, and possible remote execution

CVE-2022-1381: global heap buffer overflow in skip_range in vim

Buffer Overflow in uudecoder in Mutt affecting all versions starting from 0.94.13 before 2.2.3 allows read past end of input line

**Commit e5ed080c** authored Apr 05, 2022 by 

Browse files

**Fix uudecode buffer overflow.**

mutt\_decode\_uuencoded() used each line's initial "length character"
without any validation.  It would happily read past the end of the
input line, and with a suitable value even past the length of the
input buffer.

As I noted in ticket 404, there are several other changes that could
be added to make the parser more robust.  However, to avoid
accidentally introducing another bug or regression, I'm restricting
this patch to simply addressing the overflow.

Thanks to Tavis Ormandy for reporting the issue, along with a sample
message demonstrating the problem.

*   Changes 1

...

...

@@ -404,9 +404,9 @@ static void mutt\_decode\_uuencoded (STATE \*s, LOFF\_T len, int istext, iconv\_t cd)

pt \= tmps;

linelen \= decode\_byte (\*pt);

pt++;

for (c \= 0; c < linelen;)

for (c \= 0; c < linelen && \*pt;)

{

for (l \= 2; l <= 6; l += 2)

for (l \= 2; l <= 6 && \*pt && \*(pt + 1); l += 2)

{

out \= decode\_byte (\*pt) << l;

pt++;

...

...

*   mentioned in issue #404 (closed)
    
    mentioned in issue #404
    
*   mentioned in commit renatoaguiar/openbsd-ports@24d300b2b9ce07d6e212820528619b6f770fb475
    
*   mentioned in commit neomutt/neomutt@ee7cb4e461c1cdf0ac14817b03687d5908b85f84

CVE-2022-1328: Fix uudecode buffer overflow. (e5ed080c) · Commits · Mutt Project / mutt · GitLab

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.

**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-120 - Buffer Copy without Checking Size of Input (‘Classic 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:

    (27a8.2444): Access violation - code c0000005 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=00000000 ebx=0bb36b30 ecx=00000075 edx=00000001 esi=0bb36b30 edi=0a90aff0
    eip=6ef7e280 esp=0019f608 ebp=0019f624 iopl=0         nv up ei pl nz na po cy
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010203
    MSVCR110!memcpy+0x567:
    6ef7e280 660f7f4f10      movdqa  xmmword ptr [edi+10h],xmm1 ds:002b:0a90b000=????????????????????????????????
    

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

    void xwdread_read_bitmap(mys_table_function *param_1,uint param_2,XWD_read *XWDcontent,
                            undefined4 param_4,HIGDIBINFO param_5)
    
    {
    
    
      BytesPerLine = (XWDcontent->header_data).BytesPerLine;
      local_38 = 0;
      local_3c = 0;
      local_44 = 0;
      local_24 = 0;
      local_14 = 0;
      local_20 = 0;
      local_c = BytesPerLine;
      bit_depth = IGDIBStd::DIB_bit_depth_get(param_5);
      if (bit_depth == 1) {
        dst_buff_size = IO_raster_size_get(param_5);
      }
      else {
        dst_buff_size = DIBStd_raster_size_get(param_5);                                                    [1]
      }
      bitsPerPixel = (XWDcontent->header_data).BitsPerPixel;
      PixmapWidth = DIB_width_get(param_5);
      local_7c.size_buffer = DIB_height_get(param_5);
      
      [...]
      
      IOb_init(param_1,param_2,&local_7c,BytesPerLine * 5,1);
      lplValue1 = dst_buff_size;
      dst_buff = (byte *)AF_memm_alloc(param_2,dst_buff_size);                                              [2]
      if ((dst_buff != (byte *)0x0) ||
         (AVar3 = AF_err_record_set("..\\..\\..\\..\\Common\\Formats\\xwdread.c",0x3ad,-1000,0,lplValue1
                                    ,param_2,(LPCHAR)0x0), AVar3 == 0)) {
        local_8 = 0;
        if (0 < (int)local_7c.size_buffer) {
          while ((iVar6 = local_8, puVar4 = (uint *)get_data_from_file(&local_7c,BytesPerLine),
                 local_1c = puVar4, puVar4 != (uint *)0x0 ||
                 (AVar3 = AF_err_record_set("..\\..\\..\\..\\Common\\Formats\\xwdread.c",0x3b6,-0x803,0,
                                            BytesPerLine,param_2,(LPCHAR)0x0), AVar3 == 0))) {
            buff = puVar4;
            
            [...]
            
            bit_depth = IGDIBStd::DIB_bit_depth_get(param_5);
            if (true) {
              switch(bit_depth) {
              case 1:
              case 4:
              case 8:
                OS_memcpy(dst_buff,buff,BytesPerLine);                                                      [3]
                break;
              
              [...]
    }
    

The OS_memcpy function at [3] is a memcpy wrapper, so BytesPerLine bytes from buff are copied to dst_buff. The BytesPerLine value and buff’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 function DIBStd_raster_size_get, that computes the dst_buff_size value at [1], is shown here:

    AT_INT DIBStd_raster_size_get(HIGDIBINFO hdib)
    
        {
        [...]
        uVar1 = (*hdib->igdibstd_vftable->IGDIBStd::compute_raster_size)((IGDIBStd *)hdib);
        [...]
        return uVar1;
        }
    

The function call compute_raster_size:

    uint __fastcall IGDIBStd::compute_raster_size(IGDIBStd *param_1)
    
    {
    longlong lVar1;
    uint uVar2;
    ulonglong uVar3;
    
    lVar1 = (longlong)(int)(param_1->mys_struct_table_color).ptr_bits_per_channel_table *
            (longlong)(int)(param_1->mys_struct_table_color).ptr_channel_count;                             [4]
    uVar3 = __allmul((uint)lVar1,(uint)((ulonglong)lVar1 >> 0x20),param_1->size_X,
                    (int)param_1->size_X >> 0x1f);                                                          [5]
    lVar1 = (longlong)(uVar3 + 0x1f) >> 3;
                        /* if __all_mul's params2/4 are 0 the results is simply param1*param3 */
    uVar2 = (uint)lVar1 & 0xfffffffc;
    if ((-1 < lVar1) && ((0 < (int)((longlong)(uVar3 + 0x1f) >> 0x23) || (0x7ffffffe < uVar2)))) {
        wrapper_thow_exception
                ((undefined *)0xfffffe6f,(char *)0x0,(undefined *)0x0,(undefined *)0x0,
                (undefined **)0x1022fa38,(undefined *)0x29);
    }
    return uVar2;
    }
    

The calculation of dst_buff_size is based on the variable used in [4] and [5], where the first is dependent on the PixmapDepth and the latter is dependent on the PixmapWidth. The returned value 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: 2687
    
        Key  : Analysis.DebugAnalysisManager
        Value: Create
    
        Key  : Analysis.Elapsed.mSec
        Value: 10478
    
        Key  : Analysis.Init.CPU.mSec
        Value: 1015
    
        Key  : Analysis.Init.Elapsed.mSec
        Value: 63464
    
        Key  : Analysis.Memory.CommitPeak.Mb
        Value: 139
    
        Key  : Timeline.OS.Boot.DeltaSec
        Value: 206950
    
        Key  : Timeline.Process.Start.DeltaSec
        Value: 62
    
        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: 6ef7e280 (MSVCR110!memcpy+0x00000567)
    ExceptionCode: c0000005 (Access violation)
    ExceptionFlags: 00000000
    NumberParameters: 2
    Parameter[0]: 00000001
    Parameter[1]: 0a90b000
    Attempt to write to address 0a90b000
    
    FAULTING_THREAD:  00002444
    
    PROCESS_NAME:  Fuzzme.exe
    
    WRITE_ADDRESS:  0a90b000 
    
    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:  0a90b000
    
    STACK_TEXT:  
    0019f610 6e18f9a6     0a90aff0 0bb36b30 000000f5 MSVCR110!memcpy+0x567
    WARNING: Stack unwind information not available. Following frames may be wrong.
    0019f624 6e3247d2     0a90aff0 0bb36b30 000000f5 igCore19d+0xf9a6
    0019f6bc 6e325165     0019fc3c 1000001e 0019f718 igCore19d!IG_mpi_page_set+0x1387a2
    0019f6e4 6e323dfb     0019fc3c 1000001e 0a338ff8 igCore19d!IG_mpi_page_set+0x139135
    0019fbb4 6e1c13d9     0019fc3c 0a338ff8 00000001 igCore19d!IG_mpi_page_set+0x137dcb
    0019fbec 6e2008d7     00000000 0a338ff8 0019fc3c igCore19d!IG_image_savelist_get+0xb29
    0019fe68 6e200239     00000000 052d7fc0 00000001 igCore19d!IG_mpi_page_set+0x148a7
    0019fe88 6e195757     00000000 052d7fc0 00000001 igCore19d!IG_mpi_page_set+0x14209
    0019fea8 00402219     052d7fc0 0019febc 00000001 igCore19d!IG_load_file+0x47
    0019fec0 00402524     052d7fc0 052d9fe0 0523df50 Fuzzme!fuzzme+0x19
    0019ff28 0040668d     00000005 05236f38 0523df50 Fuzzme!fuzzme+0x324
    0019ff70 75330419     0029e000 75330400 0019ffdc Fuzzme!fuzzme+0x448d
    0019ff80 778b72ed     0029e000 58b504f3 00000000 KERNEL32!BaseThreadInitThunk+0x19
    0019ffdc 778b72bd     ffffffff 778d65b3 00000000 ntdll!__RtlUserThreadStart+0x2f
    0019ffec 00000000     00406715 0029e000 00000000 ntdll!_RtlUserThreadStart+0x1b
    
    
    STACK_COMMAND:  ~0s ; .cxr ; kb
    
    SYMBOL_NAME:  MSVCR110!memcpy+567
    
    MODULE_NAME: MSVCR110
    
    IMAGE_NAME:  MSVCR110.dll
    
    FAILURE_BUCKET_ID:  INVALID_POINTER_WRITE_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:  {80e9803c-2e1f-2683-6c9b-fae163af54bc}
    
    Followup:     MachineOwner
    ---------
    

**Timeline**

2021-08-30 - Initial contact  
2021-08-31 - Vendor acknowledged and created support ticket  
2021-09-10 - Vendor closed support ticket and confirmed under review with engineering team  
2021-11-30 - 60 day follow up  
2021-12-01 - 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-2021-21939: TALOS-2021-1368 || Cisco Talos Intelligence Group

**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-2021-21943: TALOS-2021-1373 || Cisco Talos Intelligence Group

A heap-based buffer overflow vulnerability exists in the DecoderStream::Append 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.

**Summary**

A heap-based buffer overflow vulnerability exists in the DecoderStream::Append 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 JPEG 2000 file can lead to a heap-based buffer overflow in DecoderStream::Append, due to a wrongly sized heap buffer caused by an integer overflow.

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

    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=41414141 ebx=ffffb007 ecx=029ebf58 edx=00000000 esi=00004ff8 edi=029ebf58
    eip=6e982f83 esp=0019f820 ebp=029ecf10 iopl=0         nv up ei ng nz na po nc
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010282
    igJPEG2K19d!CPb_JPEG2K_init+0x2e2c3:
    6e982f83 ff10            call    dword ptr [eax]      ds:002b:41414141=????????
    

This write access violation is happening in the function read_data_from_file, the second function called by DecoderStream::Append:

    undefined * __thiscall read_data_from_file(inner_struct_0x58 *this,byte *dst_buffer,uint read_size)
    
      {
        int iVar1;
        byte *current_file_position;
        byte *remaining_data_to_read;
        uint local_4;
    
        current_file_position = this->heap_mem_file_content_current_pos_ptr;
        remaining_data_to_read = this->heap_mem_file_content_end_of_file_ptr + -(int)current_file_position
        ;
        local_4 = 0;
        if (remaining_data_to_read <= read_size) {
          do {
            if (remaining_data_to_read != (byte *)0x0) {
              memcpy(dst_buffer,current_file_position,(size_t)remaining_data_to_read);                         [1]
              this->heap_mem_file_content_current_pos_ptr =
                  this->heap_mem_file_content_current_pos_ptr + (int)remaining_data_to_read;
              local_4 = (uint)(remaining_data_to_read + local_4);
              dst_buffer = dst_buffer + (int)remaining_data_to_read;
              read_size = read_size + -(int)remaining_data_to_read;
            }
            if (((byte *)read_size == (byte *)0x0) ||
              (iVar1 = (*(code *)*this->PTR_FUN_ARRAY)(), iVar1 == 0)) {                  [6]
              return (byte *)local_4;
            }
            current_file_position = this->heap_mem_file_content_current_pos_ptr;
            remaining_data_to_read =
                this->heap_mem_file_content_end_of_file_ptr + -(int)current_file_position;
          } while (remaining_data_to_read <= read_size);
        }
        if ((byte *)read_size != (byte *)0x0) {
          memcpy(dst_buffer,this->heap_mem_file_content_current_pos_ptr,read_size);
          this->heap_mem_file_content_current_pos_ptr =
              this->heap_mem_file_content_current_pos_ptr + read_size;
          local_4 = read_size + local_4;
        }
        return (undefined *)local_4;
      }
    

The read_data_from_file is called in DecoderStream::Append shown here:

    uint __thiscall
    DecoderStream::Append(int this,inner_struct_0x58 *inner_0x58,uint bytes_size,ushort param3)
    
    {
      [...]
    
      if (bytes_size != 0) {
        allocation_res = malloc_mem_wrap(*(int *)(this + 8),(int **)(this + 0x28),param3,bytes_size);          [2]
                        /* allocation_res[2] still reside in allocated memory */
        n_bytes_read = read_data_from_file(inner_0x58,(byte *)allocation_res[2],bytes_size);                   [4]
        if (n_bytes_read != (undefined *)bytes_size) {
          if (n_bytes_read < bytes_size) {
            memset((void *)((int)allocation_res[2] + (int)n_bytes_read),0xff,
                    bytes_size - (int)n_bytes_read);                                                           [5]
          }
          local_14 = 0xfffffbff;
          local_10 = "DecoderStream::Append";
          local_c = 0x8c;
          local_8 = "..\\..\\..\\iostream\\decoderstream.cpp";
          local_4 = "unexpected EOF on pulling encoded data";
          uVar1 = FUN_73ecf6a0(*(int *)(this + 8),&local_14);
          return uVar1 & 0xffffff00;
        }
      }
      return CONCAT31((int3)((uint)n_bytes_read >> 8),1);
    }
    

The heap buffer in which the heap overflow takes place is allocated in [2]. The function called at [2] allocates a buffer with a size related to bytes_size, which is directly read from the file. This buffer is than populated, with data taken from the file, in [4] . If the buffer is not full after [4], the remaining available space would be filled up with 0xff in [5].

The first instructions of malloc_mem_wrap, the function called in [2], are shown here:

    PUSH       ECX
    PUSH       EBX
    PUSH       EBP
    MOV        EBP,dword ptr [ESP + bytes_size]
    PUSH       ESI
    PUSH       EDI
    PUSH       ECX
    LEA        EDI,[EBP + 0x1c]                                                                                [3]
    PUSH       EDI
    MOV        ESI,param_2
    MOV        EBX,ECX
    CALL       Environ::AllocMem
    [...]
    

An integer oveflow could occur in [3] because of the sum of bytes_size and 0x1c, leading to allocate a wrongly sized buffer. This could lead to a heap-based buffer oveflow in [1] and/or [5], which can result in remote code execution.

The exception, shown previosly, is the consequence of exploiting the wrongly sized allocated memory due to the integer overflow in [1]. In this specific case this led to overwriting an object’s field, living in the heap, that is used to fetch a function array pointer, then used in [6].

**Crash Information**

crash output:

    0:000> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Exception Analysis                                   *
    *                                                                             *
    *******************************************************************************
    
    
    KEY_VALUES_STRING: 1
    
        Key  : AV.Dereference
        Value: String
    
        Key  : AV.Fault
        Value: Read
    
        Key  : Analysis.CPU.mSec
        Value: 2764
    
        Key  : Analysis.DebugAnalysisManager
        Value: Create
    
        Key  : Analysis.Elapsed.mSec
        Value: 14845
    
        Key  : Analysis.Init.CPU.mSec
        Value: 687
    
        Key  : Analysis.Init.Elapsed.mSec
        Value: 1088838
    
        Key  : Analysis.Memory.CommitPeak.Mb
        Value: 133
    
        Key  : Timeline.OS.Boot.DeltaSec
        Value: 24729
    
        Key  : Timeline.Process.Start.DeltaSec
        Value: 1088
    
        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:  470
    
    APPLICATION_VERIFIER_FLAGS:  0
    
    EXCEPTION_RECORD:  (.exr -1)
    ExceptionAddress: 6e982f83 (igJPEG2K19d!CPb_JPEG2K_init+0x0002e2c3)
       ExceptionCode: c0000005 (Access violation)
      ExceptionFlags: 00000000
    NumberParameters: 2
       Parameter[0]: 00000000
       Parameter[1]: 41414141
    Attempt to read from address 41414141
    
    FAULTING_THREAD:  000027cc
    
    PROCESS_NAME:  Fuzzme.exe
    
    READ_ADDRESS:  41414141 
    
    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:  00000000
    
    EXCEPTION_PARAMETER2:  41414141
    
    STACK_TEXT:  
    WARNING: Stack unwind information not available. Following frames may be wrong.
    0019f830 6e9c82c6     029e7f18 ffffffff 029f1ea8 igJPEG2K19d!CPb_JPEG2K_init+0x2e2c3
    0019f848 6e8e2ebb     0019f960 6e8e12b4 00000048 igJPEG2K19d!CPb_JPEG2K_init+0x73606
    0019f850 6e8e12b4     00000048 02a2b308 6e99cd17 igJPEG2K19d+0x2ebb
    0019f960 6e97d73e     029e0f78 02a2afc8 00000055 igJPEG2K19d+0x12b4
    0019f980 6e974109     029e0f78 02a2afc8 02a2c458 igJPEG2K19d!CPb_JPEG2K_init+0x28a7e
    0019fa58 6e96f55c     029e0f78 02a2afc8 007ebd78 igJPEG2K19d!CPb_JPEG2K_init+0x1f449
    0019faac 6e96cccd     02a2afc8 02a2aec8 02a2b044 igJPEG2K19d!CPb_JPEG2K_init+0x1a89c
    0019fb10 6e95dbba     02a2afc8 8c153897 007ebd78 igJPEG2K19d!CPb_JPEG2K_init+0x1800d
    0019fb54 6e961059     00000000 02a2aec8 00000000 igJPEG2K19d!CPb_JPEG2K_init+0x8efa
    0019fb70 6e9570a6     007ebd78 02a2aec8 8c15385f igJPEG2K19d!CPb_JPEG2K_init+0xc399
    0019fb9c 6e95711e     0019fc3c 007ebd00 00000000 igJPEG2K19d!CPb_JPEG2K_init+0x23e6
    0019fbb4 6ef013d9     0019fc3c 007ebd00 00000001 igJPEG2K19d!CPb_JPEG2K_init+0x245e
    0019fbec 6ef408d7     00000000 007ebd00 0019fc3c igCore19d!IG_image_savelist_get+0xb29
    0019fe68 6ef40239     00000000 007177a0 00000001 igCore19d!IG_mpi_page_set+0x148a7
    0019fe88 6eed5757     00000000 007177a0 00000001 igCore19d!IG_mpi_page_set+0x14209
    0019fea8 00402219     007177a0 0019febc 00000001 igCore19d!IG_load_file+0x47
    0019fec0 00402524     007177a0 007177e8 00717ad0 Fuzzme!fuzzme+0x19
    0019ff28 0040668d     00000005 00716200 00717ad0 Fuzzme!fuzzme+0x324
    0019ff70 75b90419     002fd000 75b90400 0019ffdc Fuzzme!fuzzme+0x448d
    0019ff80 77a072ed     002fd000 fead64a1 00000000 KERNEL32!BaseThreadInitThunk+0x19
    0019ffdc 77a072bd     ffffffff 77a265b0 00000000 ntdll!__RtlUserThreadStart+0x2f
    0019ffec 00000000     00406715 002fd000 00000000 ntdll!_RtlUserThreadStart+0x1b
    
    
    STACK_COMMAND:  ~0s ; .cxr ; kb
    
    SYMBOL_NAME:  igJPEG2K19d!CPb_JPEG2K_init+2e2c3
    
    MODULE_NAME: igJPEG2K19d
    
    IMAGE_NAME:  igJPEG2K19d.dll
    
    FAILURE_BUCKET_ID:  INVALID_POINTER_READ_FILL_PATTERN_41414141_c0000005_igJPEG2K19d.dll!CPb_JPEG2K_init
    
    OS_VERSION:  10.0.17763.1
    
    BUILDLAB_STR:  rs5_release
    
    OSPLATFORM_TYPE:  x86
    
    OSNAME:  Windows 10
    
    IMAGE_VERSION:  25.1.0.0
    
    FAILURE_ID_HASH:  {79891e7d-f1f3-59e0-064a-4dbbd8234ed4}
    
    Followup:     MachineOwner
    ---------
    

**Timeline**

2021-08-23 - Initial contact  
2021-08-24 - Vendor acknowledged and created support ticket  
2021-10-29 - 60 day follow up  
2021-11-30 - Vendor investigating status  
2021-12-02 - Vendor advised release planned for Q1 2022  
2021-12-07 - 30 day disclosure extension granted (2022-01-24)  
2022-01-06 - Final disclosure notification  
2022-02-23 - Public disclosure

Discovered by Francesco Benvenuto of Cisco Talos.

Tag

#buffer_overflow