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.

CVE-2021-21948: TALOS-2021-1376 || 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

A heap-based buffer overflow vulnerability exists in the sphere.c start_read() functionality of Sound Exchange libsox 14.4.2 and master commit 42b3557e. A specially-crafted 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 sphere.c start\_read() functionality of Sound Exchange libsox 14.4.2 and master commit 42b3557e. A specially-crafted file can lead to a heap buffer overflow. 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.

Sound Exchange libsox 14.4.2  
Sound Exchange libsox master commit 42b3557e

**PRODUCT URLS**

libsox - http://sox.sourceforge.net/Main/HomePage

**CVSSv3 SCORE**

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

**CWE**

CWE-122 - Heap-based Buffer Overflow

**DETAILS**

Libsox is a well-aged library used for cross-platform audio editing software, originally written in 1991. After decades of development, a wide range of file formats are supported, including .wav, .flac, and .mp3 (with the aid of an external library).

Out of the multitude of file formats that Sound Exchange’s libsox can deal with, today we discuss the extremely obscure NIST Speech Header Resources (SPHERE) file format, which apparently is used for speech recognition. But regardless of the purpose, libsox will still process a given file as a .sph assuming that the file header matches:

     static char const * auto_detect_format(sox_format_t * ft, char const * ext)
    {
      char data[AUTO_DETECT_SIZE];
      size_t len = lsx_readbuf(ft, data, ft->seekable? sizeof(data) : PIPE_AUTO_DETECT_SIZE);
      #define CHECK(type, p2, l2, d2, p1, l1, d1) if (len >= p1 + l1 && \
          !memcmp(data + p1, d1, (size_t)l1) && !memcmp(data + p2, d2, (size_t)l2)) return #type;
      // [...]
      CHECK(sph   , 0, 0, ""     , 0,  7, "NIST_1A")
    

This auto_detect_format will be hit from either sox_open_mem_read or sox_open_read, but only if the filetype is not specified by the arguments. Either way, since it’s possible to hit the processing in sphere.c via autodetection, let us look at the start_read function for the SPHERE file format:

    static int start_read(sox_format_t * ft)
    {
      unsigned long header_size_ul = 0, num_samples_ul = 0;   
      size_t     header_size, bytes_read;  
      // [...]
      char           fldname[64], fldtype[16], fldsval[128];
      char           * buf;
    
      /* Magic header */
      if (lsx_reads(ft, fldname, (size_t)8) || strncmp(fldname, "NIST_1A", (size_t)7) != 0) {   // [1]
        lsx_fail_errno(ft, SOX_EHDR, "Sphere header does not begin with magic word `NIST_1A'");
        return (SOX_EOF);
      }
    
      if (lsx_reads(ft, fldsval, (size_t)8)) {                                                  // [2]
        lsx_fail_errno(ft, SOX_EHDR, "Error reading Sphere header");
        return (SOX_EOF);
      }
    
      /* Determine header size, and allocate a buffer large enough to hold it. */
      sscanf(fldsval, "%lu", &header_size_ul);                                                  // [3]
      if (header_size_ul < 16) {
        lsx_fail_errno(ft, SOX_EHDR, "Error reading Sphere header");
        return (SOX_EOF);
      }
    
      buf = lsx_malloc(header_size = header_size_ul);                                           // [4]
    

So far the code is pretty standard. We read eight bytes at \[1\], make sure the “NIST\_1A” magic bytes are there, and then read another eight bytes at \[2\], this time populating them into the unsigned long header_size_ul at \[3\]. At \[4\], we then allocate a buffer of that size. Again, pretty standard. Continuing on:

      /* Skip what we have read so far */
      header_size -= 16;
    
      if (lsx_reads(ft, buf, header_size) == SOX_EOF) {       // [5]
        lsx_fail_errno(ft, SOX_EHDR, "Error reading Sphere header");
        free(buf);
        return (SOX_EOF);
      }
    
      header_size -= (strlen(buf) + 1);
    

At \[5\] we see the main function used for reading our input buffer, lsx_reads. Suffice to say, this function is essentially fgets (although I’m not actually sure which function has seniority), and buf will contain a new line of text from our input buffer every time lsx_reads is called. We now finally reach our main processing loop:

      while (strncmp(buf, "end_head", (size_t)8) != 0) {    // [6]
      
        if (strncmp(buf, "sample_n_bytes", (size_t)14) == 0)
          sscanf(buf, "%63s %15s %u", fldname, fldtype, &bytes_per_sample);
        else if (strncmp(buf, "channel_count", (size_t)13) == 0)
          sscanf(buf, "%63s %15s %u", fldname, fldtype, &channels);
          // [...] 
          else {
            lsx_fail_errno(ft, SOX_EFMT, "sph: unsupported coding `%s'", fldsval);
            free(buf);
            return SOX_EOF;
          }
        }
        else if (strncmp(buf, "sample_byte_format", (size_t)18) == 0) {
          sscanf(buf, "%53s %15s %127s", fldname, fldtype, fldsval);
          if (strcmp(fldsval, "01") == 0)         /* Data is little endian. */
            ft->encoding.reverse_bytes = MACHINE_IS_BIGENDIAN;
          else if (strcmp(fldsval, "10") == 0)    /* Data is big endian. */
            ft->encoding.reverse_bytes = MACHINE_IS_LITTLEENDIAN;
          else if (strcmp(fldsval, "1")) {
            lsx_fail_errno(ft, SOX_EFMT, "sph: unsupported coding `%s'", fldsval);
            free(buf);
            return SOX_EOF;
          }
        }
    
        if (lsx_reads(ft, buf, header_size) == SOX_EOF) {   // [7]
          lsx_fail_errno(ft, SOX_EHDR, "Error reading Sphere header");
          free(buf);
          return (SOX_EOF);
        }
    
        header_size -= (strlen(buf) + 1); 
    

At \[6\], we can see that we’re looping until a end_head header is found, but in the meantime, we search for various headers in the file (e.g. "channel_count", "sample_byte_format", etc.). After going through the specific buffer line, we read a new one in at \[7\], then subtract the length of our new buffer plus one at \[8\]. The + 1 compensates for the \n or \x00 bytes that delimit the headers of our file.

But let’s examine a situation in which we provide a file that does not contain a valid end_head header:

      while (strncmp(buf, "end_head", (size_t)8) != 0) {  // [6]
      
        if (strncmp(buf, "sample_n_bytes", (size_t)14) == 0)
          sscanf(buf, "%63s %15s %u", fldname, fldtype, &bytes_per_sample);
        else if (strncmp(buf, "channel_count", (size_t)13) == 0)
            // [...]
        }
    
        if (lsx_reads(ft, buf, header_size) == SOX_EOF) { // [7] 
          lsx_fail_errno(ft, SOX_EHDR, "Error reading Sphere header");
          free(buf);
          return (SOX_EOF);
        }
    
        header_size -= (strlen(buf) + 1); 
    

At \[6\] again, we start our loop, which eventually processes our header strings inside, but then at \[7\] the next header is read via lsx_reads. A quick look at lsx_reads reveals an important detail:

    int lsx_reads(sox_format_t * ft, char *c, size_t len)
    {
        char *sc;
        char in;
    
        sc = c;
        do  // [8]
        {
            if (lsx_readbuf(ft, &in, (size_t)1) != 1)
            {
                *sc = 0;
                return (SOX_EOF);
            }
            if (in == 0 || in == '\n')
                break;
    
            *sc = in;
            sc++;
        } while (sc - c < (ptrdiff_t)len);  // [9]
        *sc = 0;
        return(SOX_SUCCESS);
    }
    

Since lsx_reads utilizes a do/while loop (\[8\], \[9\]), even though the conditional at \[9\] depends on a less-than sign and not a less-than-equals-to sign. If our input len parameter is 22, then 22 bytes of data are copied over, followed by the null byte write. So in effect, 23 bytes of data get written from a 22 byte len, which is an off-by-one. Curiously, in spite of lsx_reads ubiquitous usage in libsox, all the other call sites compensate for this off-by-one, usually with a -1 to the input len parameter when calling. However, in the sphere.c code, we see a different compensation:

        if (lsx_reads(ft, buf, header_size) == SOX_EOF) {   // [10]
          lsx_fail_errno(ft, SOX_EHDR, "Error reading Sphere header");
          free(buf);
          return (SOX_EOF);
        }
    
        header_size -= (strlen(buf) + 1);                   // [11]
    

At \[11\], we can see that an extra byte is subtracted from our header_size parameter to compensate for the off-by-one in lsx_reads. Thus, if the header_size is 22 and our next buffer is read in, lsx_reads will stop at 22 bytes (regardless of the length of the rest of the buffer). Then we subtract 23 from header_size, resulting in an integer underflow.

With regards to exploitation: While normally such a situation might result in a wild copy (i.e. we couldn’t stop the bug from writing into things we don’t want it to and crashing), we’re bailed out by the overall structure of this function. We’d simply have our next read be our overflow string of any size that we wanted, and then the following read just being "end_head". This would allow us to arbitrarily overwrite data on the heap while also allowing us to continue into the code to actually utilize the heap overflow.

**Crash Information**

    ==778467==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6060000000ba at pc 0x0000004bea6e bp 0x7ffeacb7c950 sp 0x7ffeacb7c118
    WRITE of size 203 at 0x6060000000ba thread T0
        #0 0x4bea6d in __interceptor_fread (/doop/boop/sox/triage_built/fuzz_sox.bin+0x4bea6d)
        #1 0x7ff5dc360ea7 in lsx_readbuf /doop/boop/sox/triage_built/triage_sox/src/formats_i.c:98:16
        #2 0x7ff5dc4b9bc0 in start_read /doop/boop/sox/triage_built/triage_sox/src/sphere.c:119:18
        #3 0x7ff5dc46c864 in open_read /doop/boop/sox/triage_built/triage_sox/src/formats.c:545:32
        #4 0x7ff5dc46d2bb in sox_open_mem_read /doop/boop/sox/triage_built/triage_sox/src/formats.c:595:10
        #5 0x55623a in LLVMFuzzerTestOneInput /doop/boop/sox/./fuzz_sox_harness.cpp:51:10
        #6 0x456ff3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) fuzzer.o
        #7 0x442b32 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) fuzzer.o
        #8 0x448a5b in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) fuzzer.o
        #9 0x471ef2 in main (/doop/boop/sox/triage_built/fuzz_sox.bin+0x471ef2)
        #10 0x7ff5dbfa1fcf in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
        #11 0x7ff5dbfa207c in __libc_start_main csu/../csu/libc-start.c:409:3
        #12 0x41f7a4 in _start (/doop/boop/sox/triage_built/fuzz_sox.bin+0x41f7a4)
    
    0x6060000000ba is located 0 bytes to the right of 58-byte region [0x606000000080,0x6060000000ba)
    allocated by thread T0 here:
        #0 0x521d83 in __interceptor_realloc (/doop/boop/sox/triage_built/fuzz_sox.bin+0x521d83)
        #1 0x7ff5dc47b388 in lsx_realloc /doop/boop/sox/triage_built/triage_sox/src/xmalloc.c:37:14
        #2 0x7ff5dc4b9376 in start_read /doop/boop/sox/triage_built/triage_sox/src/sphere.c:55:9
        #3 0x7ff5dc46c864 in open_read /doop/boop/sox/triage_built/triage_sox/src/formats.c:545:32
        #4 0x7ff5dc46d2bb in sox_open_mem_read /doop/boop/sox/triage_built/triage_sox/src/formats.c:595:10
        #5 0x55623a in LLVMFuzzerTestOneInput /doop/boop/sox/./fuzz_sox_harness.cpp:51:10
        #6 0x456ff3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) fuzzer.o
        #7 0x442b32 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) fuzzer.o
        #8 0x448a5b in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) fuzzer.o
        #9 0x471ef2 in main (/doop/boop/sox/triage_built/fuzz_sox.bin+0x471ef2)
        #10 0x7ff5dbfa1fcf in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/doop/boop/sox/triage_built/fuzz_sox.bin+0x4bea6d) in __interceptor_fread
    Shadow bytes around the buggy address:
      0x0c0c7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c0c7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c0c7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c0c7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c0c7fff8000: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
    =>0x0c0c7fff8010: 00 00 00 00 00 00 00[02]fa fa fa fa fa fa fa fa
      0x0c0c7fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
    
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
    ==692318==ABORTING
    

**TIMELINE**

2021-12-22 - Initial contact  
2022-01-14 - Follow up with vendor; vendor acknowledged  
2022-03-23 - Vendor disclosure

Discovered by Lilith >\_> of Cisco Talos.

CVE-2021-40426: TALOS-2021-1434 || Cisco Talos Intelligence Group

A memory corruption vulnerability exists in the cgi.c unescape functionality of ArduPilot APWeb master branch 50b6b7ac - master branch 46177cb9. A specially-crafted HTTP request can lead to memory corruption. An attacker can send a network request to trigger this vulnerability.

**Summary**

A memory corruption vulnerability exists in the cgi.c unescape functionality of ArduPilot APWeb master branch 50b6b7ac - master branch 46177cb9. A specially-crafted HTTP request can lead to memory corruption. An attacker can send a network request to trigger this vulnerability.

**Tested Versions**

ArduPilot APWeb master commit 50b6b7ac - master commit 46177cb9

**Product URLs**

APWeb - https://github.com/ArduPilot/APWeb

**CVSSv3 Score**

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

**CWE**

CWE-20 - Improper Input Validation

**Details**

APWeb is the web server for ArduPilot.

The ArduPilot’s APWeb component, has a file named cgi.c that contains CGI helper functions. One of these functions is unescape:

    void unescape(char *p)
    {
        unsigned v;
    
        while (*p) {                                                                                        [1]
            if (*p == '+') *p = ' ';
            if (*p == '%' && sscanf(p+1, "%02x", &v) == 1) {                                                [2]
                *p = (char)v;                                                                               [3]
                memcpy(p+1, p+3, strlen(p+3)+1);                                                            [4]
            }
            p++;
        }
    }
    

This function takes as argument a string. If the string is URL-encoded, this function will decode it. The while loop, starting at [1], will traverse the input searching for the characters % or +. When the % character is found, at [2], the following two characters are converted from hex values to a single character. At [3] the converted character replaces the % character. At [4], the string after the just-parsed URL-encoded character is moved left by two positions. This will replace the parsed characters. A string like “A…B%41%42” would go through the following steps:

    |A|...|B|%|4|1|%|4|2|NULL|           at    [1]/[2]
    |A|...|B|A|4|1|%|4|2|NULL|           after [3]
    |A|...|B|A|%|4|2|NULL|2|NULL|        after [4]
    

Eventually, after a second iteration of the loop we would end up like this:

    |A|...|B|A|B|NULL|2|NULL|2|NULL|     after [4]
    

The unescape function assumes, wrongly, that after a % there are always at least two characters. If this is not the case, the instruction at [4] would cause a out-of-bounds read, and could cause an out-of-bounds and write.

**Vendor Response**

This fixes a vulnerability in unescape which can lead to memory overwrite

https://github.com/ArduPilot/APWeb/pull/20

**Timeline**

2022-04-11 - Vendor Disclosure  
2022-04-11 - Vendor Patch Release  
2022-07-27 - Public Release  

Discovered by Francesco Benvenuto of Cisco Talos.

Tag

#intel