MP4Box is a component of GPAC-2.0.0, which is a widely-used third-party package on RPM Fusion. When MP4Box tries to parse a MP4 file, it calls the function `diST_box_read()` to read from video. In this function, it allocates a buffer `str` with fixed length. However, content read from `bs` is controllable by user, so is the length, which causes a buffer overflow.

Expand Up

@@ -1128,20 +1128,12 @@ void diST\_box\_del(GF\_Box \*s)

  

GF\_Err diST\_box\_read(GF\_Box \*s, GF\_BitStream \*bs)

{

u32 i;

char str\[1024\];

GF\_DIMSScriptTypesBox \*p \= (GF\_DIMSScriptTypesBox \*)s;

  

i\=0;

str\[0\]\=0;

while (1) {

str\[i\] \= gf\_bs\_read\_u8(bs);

if (!str\[i\]) break;

i++;

}

ISOM\_DECREASE\_SIZE(p, i);

  

p\->content\_script\_types \= gf\_strdup(str);

p\->content\_script\_types \= gf\_malloc(sizeof(char) \* (s\->size+1));

if (!p\->content\_script\_types) return GF\_OUT\_OF\_MEM;

gf\_bs\_read\_data(bs, p\->content\_script\_types, s\->size);

p\->content\_script\_types\[s\->size\] \= 0;

return GF\_OK;

}

  

Expand Down

CVE-2022-1441: fixed #2175 · gpac/gpac@3dbe11b

FreeType commit 1e2eb65048f75c64b68708efed6ce904c31f3b2f was discovered to contain a heap buffer overflow via the function sfnt_init_face.

I compile freetype with ASAN and call FT_New_Face with the following code:

    #include "ft2build.h"
    #include FT_FREETYPE_H
    
    int main (int argc, char **argv) {
        FT_Library lib;
        FT_Face face;
    
        FT_Init_FreeType(&lib);
        FT_New_Face(lib, argv[1], -4939615758108852224, &face);
    }

and run with this file testface

I think FT_New_Face should return a non-zero value. However, ASAN reports like following:

    ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000088 at pc 0x7fd51dd1048d bp 0x7ffdffb48a10 sp 0x7ffdffb48a08
    READ of size 8 at 0x602000000088 thread T0
        #0 0x7fd51dd1048c in sfnt_init_face
        #1 0x7fd51dd60277 in tt_face_init
        #2 0x7fd51db84bf1 in open_face
        #3 0x7fd51db583c2 in ft_open_face_internal
        #4 0x7fd51db5764a in FT_New_Face
        #5 0x4c6c0b in main
        #6 0x7fd51d4f80b2 in __libc_start_main
        #7 0x41c2fd in _start
    
    0x602000000088 is located 8 bytes to the left of 8-byte region [0x602000000090,0x602000000098)
    allocated by thread T0 here:
        #0 0x494a3d in malloc
        #1 0x7fd51dbb8ea4 in ft_alloc
        #2 0x7fd51db7c1b1 in ft_mem_qalloc
        #3 0x7fd51db4cdb3 in ft_mem_alloc
        #4 0x7fd51dd298f3 in sfnt_open_font
        #5 0x7fd51dd1018c in sfnt_init_face
        #6 0x7fd51dd60277 in tt_face_init
        #7 0x7fd51db84bf1 in open_face
        #8 0x7fd51db583c2 in ft_open_face_internal
        #9 0x7fd51db5764a in FT_New_Face
        #10 0x4c6c0b in main
        #11 0x7fd51d4f80b2 in __libc_start_main 
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow in sfnt_init_face
    Shadow bytes around the buggy address:
      0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff8000: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
    =>0x0c047fff8010: fa[fa]00 fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    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
    ==3906462==ABORTING

Edited Mar 17, 2022 by

CVE-2022-27404: heap-buffer-overflow on creating a face with strange file and invalid index (#1138) · Issues · FreeType / FreeType

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.

Tag

#buffer_overflow