
IBM Robotic Process Automation 21.0.0 through 21.0.7.1 runtime is vulnerable to information disclosure of script content if the remote REST request computer policy is enabled.  IBM X-Force ID:  263470.



  

**Summary**

IBM Robotic Process Automation runtime is vulnerable to information disclosure of script content if the remote REST request computer policy is enabled.

**Vulnerability Details**

**CVEID:**   CVE-2023-40370  
**DESCRIPTION:**   IBM Robotic Process Automation runtime is vulnerable to information disclosure of script content if the remote REST request computer policy is enabled.  
CVSS Base score: 3.7  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/263470 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N)

**Affected Products and Versions**

Affected Product(s)

Version(s)

IBM Robotic Process Automation

21.0.0 - 21.0.7.1

IBM Robotic Process Automation for Cloud Pak

21.0.0 - 21.0.7.1

**Remediation/Fixes**

**IBM strongly recommends addressing the vulnerability now.**

**Product(s)**

**Version(s) number and/or range** 

**Remediation/Fix/Instructions**

IBM Robotic Process Automation

21.0.0 - 21.0.7.1

Download 21.0.7.2 or higher and follow these instructions.

IBM Robotic Process Automation for Cloud Pak

21.0.0 - 21.0.7.1

Update to 21.0.7.2 or higher using the following instructions. 

**Workarounds and Mitigations**

None.

**References**

Off

**Acknowledgement**

Mariana Penna (IBM)

**Change History**

21 Aug 2023: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU059","label":"IBM Software w\\/o TPS"},"Product":{"code":"SSC50T","label":"IBM Robotic Process Automation"},"Component":"","Platform":\[{"code":"PF033","label":"Windows"},{"code":"PF040","label":"RedHat OpenShift"}\],"Version":"21.0.0 - 21.0.7.1","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}\]

CVE-2023-40370: IBM Robotic Process Automation is vulnerable to information disclosure of script content (CVE-2023-40370)


IBM Robotic Process Automation 21.0.0 through 21.0.7.1 and 23.0.0 through 23.0.1 server could allow an authenticated user to view sensitive information from installation logs.  IBM X-Force Id:  262293.



  

**Summary**

IBM Robotic Process Automation server could allow an authenticated user to view sensitive information from installation logs. Authenticated users are able to view database connection strings in the IBM Robotic Process Automation installation logs.

**Vulnerability Details**

**CVEID:**   CVE-2023-38733  
**DESCRIPTION:**   IBM Robotic Process Automation server could allow an authenticated user to view sensitive information from installation logs.  
CVSS Base score: 4.3  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/262293 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N)

**Affected Products and Versions**

Affected Product(s)

Version(s)

IBM Robotic Process Automation

21.0.0 - 21.0.7.3, 23.0.0 - 23.0.3

**Remediation/Fixes**

**IBM strongly recommends addressing the vulnerability now.**

**Product(s)**

**Version(s) number and/or range** 

**Remediation/Fix/Instructions**

IBM Robotic Process Automation

21.0.0 - 21.0.7.3

Download 21.0.7.4 or higher and follow these instructions.

IBM Robotic Process Automation

23.0.0 - 23.0.3

Download 23.0.4 or higher and follow these instructions.

**Workarounds and Mitigations**

**Workarounds/Mitigation guidance**:

Remove installation logs after installing the IBM Robotic Process Automation Server.

**References**

Off

**Acknowledgement**

Michael Stuy (IBM)

**Change History**

21 Aug 2023: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU059","label":"IBM Software w\\/o TPS"},"Product":{"code":"SSC50T","label":"IBM Robotic Process Automation"},"Component":"","Platform":\[{"code":"PF033","label":"Windows"},{"code":"PF040","label":"RedHat OpenShift"}\],"Version":"21.0.0 - 21.0.7.3, 23.0.0 - 23.0.3","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}\]

CVE-2023-38733: IBM Robotic Process Automation is vulnerable to sensitive information disclosure in installation logs (CVE-2023-38733)


IBM Robotic Process Automation 21.0.0 through 21.0.7.1 and 23.0.0 through 23.0.1 is vulnerable to incorrect privilege assignment when importing users from an LDAP directory.  IBM X-Force ID:  262481.



  

**Summary**

IBM Robotic Process Automation is vulnerable to incorrect privilege assignment when importing user from an LDAP directory (CVE-2023-38734).

**Vulnerability Details**

**CVEID:**   CVE-2023-38734  
**DESCRIPTION:**   IBM Robotic Process Automation is vulnerable to incorrect privilege assignment when importing users from an LDAP directory.  
CVSS Base score: 6.6  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/262481 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)

**Affected Products and Versions**

Affected Product(s)

Version(s)

IBM Robotic Process Automation

21.0.0 - 21.0.7.1, 23.0.0 - 23.0.1

**Remediation/Fixes**

**IBM strongly recommends addressing the vulnerability now.**

**Product(s)**

**Version(s) number and/or range** 

**Remediation/Fix/Instructions**

IBM Robotic Process Automation

21.0.0 - 21.0.7.1

Download 21.0.7.2 or higher and follow these instructions.

IBM Robotic Process Automation

23.0.0 - 23.0.1

Download 23.0.2 or higher and follow these instructions.

**Workarounds and Mitigations**

None

**References**

Off

**Acknowledgement**

Mariana Penna (IBM)

**Change History**

21 Aug 2023: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU059","label":"IBM Software w\\/o TPS"},"Product":{"code":"SSC50T","label":"IBM Robotic Process Automation"},"Component":"","Platform":\[{"code":"PF033","label":"Windows"},{"code":"PF040","label":"RedHat OpenShift"}\],"Version":"21.0.0 - 21.0.7.1, 23.0.0 - 23.0.1","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}\]

CVE-2023-38734: IBM Robotic Process Automation is vulnerable to incorrect privilege assignment when importing user from an LDAP directory (CVE-2023-38734).

By Habiba Rashid
The campaign, which began at the start of August 2023, revolves around malicious packages impersonating the legitimate noblox.js,…
This is a post from HackRead.com Read the original post: Luna Grabber Malware Hits Roblox Devs Through npm Packages

The campaign, which began at the start of August 2023, revolves around malicious packages impersonating the legitimate noblox.js, a popular Node.js Roblox API wrapper.

*   **Roblox developers are being targeted by a new malware called Luna Grabber**

*   **The malware is being distributed through malicious npm packages that impersonate legitimate software.**

*   **Luna Grabber is capable of stealing sensitive data from victims’ web browsers, Discord applications, and local system configurations.**

*   **The malware was downloaded approximately 1000 times, but its impact was relatively low due to the security measures in place to protect developers on the npm repository.**

*   **The incident highlights the growing trend of malicious actors employing typo squatting to exploit developers’ trust in legitimate software packages.**

Cybersecurity firm ReversingLabs has uncovered a sophisticated cyber attack targeting developers on the Roblox gaming platform. Malicious actors have been distributing malicious packages through the npm public repository, attempting to exploit users by mimicking legitimate software while incorporating malicious payloads that steal sensitive information from victims’ systems.

**Malware Campaign Overview**

The campaign, which began at the start of August 2023, revolves around malicious packages impersonating the legitimate noblox.js, a popular Node.js Roblox API wrapper. By infiltrating the npm public repository, attackers capitalized on unsuspecting developers seeking to interact with the Roblox gaming platform using scripts.

ReversingLabs researchers identified several malicious packages during the campaign, including noblox.js-vps, noblox.js-ssh, and noblox.js-secure. These packages were engineered to deliver multi-stage malicious payloads that targeted victims’ local web browsers and Discord applications. The most notable payload identified was Luna Grabber, an open-source malware designed to extract sensitive data.

**Malware Execution and Strategy**

Attackers meticulously designed the malicious packages to closely resemble the legitimate noblox.js package. By mirroring the original code and adopting similar naming conventions, the attackers aimed to deceive developers into downloading and using the compromised software.

The malicious packages leveraged a variety of techniques to compromise victims’ systems, including the incorporation of a separate file named postinstall.js. This post-installation script triggered the execution of a malicious payload after the package installation was completed. The malware then determined whether the victim was operating a Windows machine and proceeded to download and execute the Luna Grabber malware from Discord’s Content Delivery Network (CDN).

**Luna Grabber: Information Stealing Malware**

The research revealed that the primary payload of the malicious packages was Luna Grabber, a highly customizable malware capable of stealing information from victims’ web browsers, Discord applications, and local system configurations. The malware was also equipped with features that enabled it to detect virtual environments and initiate a self-destruct mechanism if necessary.

Interestingly, the attackers behind the campaign took advantage of the user-friendly nature of Luna Grabber’s builder application, simplifying the process of creating and configuring the malicious executable.

Screenshot shared by ReversingLabs shows Luna Grabber builder

While Luna Grabber’s open-source nature allowed attackers to tailor the malware to their needs, the choice of targeting developers on the Roblox platform suggests a focus on a specific user group.

**Limited Impact and Lessons Learned**

Despite the campaign’s sophistication, its impact remained relatively low. The malicious packages were downloaded approximately 1000 times, signalling that the security measures in place to protect developers on the npm repository were successful in limiting the reach of the attack.

The incident sheds light on the growing trend of malicious actors employing typo squatting to exploit developers’ trust in legitimate software packages. This approach has been previously observed in other campaigns, such as the IconBurst and Brainleeches campaigns.

Fake noblox.js-ssh’s npm website page (ReversingLabs)

While multi-stage malicious packages are common on certain open-source platforms, such as PyPI, their presence on npm—where this campaign took place—represents the ongoing challenge of maintaining secure open-source repositories and the importance of cautiousness in choosing software packages for development purposes.

1.  CISA warns of trojanized JavaScript library’s NPM package
2.  Discord.io Admits Data Breach: Info of 760K Users Sold Online
3.  6 official Python repositories plagued with cryptomining malware

Luna Grabber Malware Hits Roblox Devs Through npm Packages

Buffer Overflow vulnerability in function LoadPixelDataRLE8 in PluginBMP.cpp in FreeImage 3.18.0 allows remote attackers to run arbitrary code and cause other impacts via crafted image file.

*   Summary
*   Files
*   Reviews
*   Support
*   Mailing Lists
*   Code
*   Tickets ▾
    *   Feature Requests
    *   Patches
    *   Bugs
    *   Support Requests
*   News
*   Discussion
*   FreeImage

Menu ▾ ▴

Milestone: None

Status: pending

Labels: None

Priority: 5

Updated: 2021-04-04

Created: 2019-12-03

Private: No

There is a heap-buffer-overflow in function LoadPixelDataRLE8 of PluginBMP.cpp whick may cause a code execution or denial of service.  
The asan log as below:

\=================================================================
\==28346\==ERROR: AddressSanitizer: heap\-buffer\-overflow on address 0xf4b02ca0 at pc 0x081595db bp 0xff8e4b28 sp 0xff8e4b20
WRITE of size 1 at 0xf4b02ca0 thread T0
    #0 0x81595da in LoadPixelDataRLE8(FreeImageIO\*, void\*, int, int, FIBITMAP\*) /home/FreeImage/Source/FreeImage/PluginBMP.cpp:445:22
    #1 0x8153442 in LoadWindowsBMP(FreeImageIO\*, void\*, int, unsigned int, int) /home/FreeImage/Source/FreeImage/PluginBMP.cpp:555:11
    #2 0x8153442 in Load(FreeImageIO\*, void\*, int, int, void\*) /home/FreeImage/Source/FreeImage/PluginBMP.cpp:1135:12
    #3 0x814d00b in FreeImage\_LoadFromHandle /home/FreeImage/Source/FreeImage/Plugin.cpp:388:24
    #4 0x814d00b in FreeImage\_Load /home/FreeImage/Source/FreeImage/Plugin.cpp:408:22
    #5 0x811a7a0 in main /home/FreeImage/test.cpp:115:8
    #6 0xf7290fb8 in \_\_libc\_start\_main /build/glibc\-jYPHgv/glibc\-2.30/csu/../csu/libc\-start.c:308:16
    #7 0x806f8f5 in \_start (/home/FreeImage/test+0x806f8f5)

0xf4b02ca0 is located 0 bytes to the right of 544\-byte region \[0xf4b02a80,0xf4b02ca0)
allocated by thread T0 here:
    #0 0x80e6675 in malloc (/home/FreeImage/TestAPI/testAPI+0x80e6675)
    #1 0x812aa32 in FreeImage\_Aligned\_Malloc(unsigned int, unsigned int) /home/FreeImage/Source/FreeImage/BitmapAccess.cpp:183:19
    #2 0x812aa32 in FreeImage\_AllocateBitmap(int, unsigned char\*, unsigned int, FREE\_IMAGE\_TYPE, int, int, int, unsigned int, unsigned int, unsigned int) /home/FreeImage/Source/FreeImage/BitmapAccess.cpp:390:26
    #3 0x812b600 in FreeImage\_AllocateHeader /home/FreeImage/Source/FreeImage/BitmapAccess.cpp:482:9
    #4 0x8152bf1 in LoadWindowsBMP(FreeImageIO\*, void\*, int, unsigned int, int) /home/FreeImage/Source/FreeImage/PluginBMP.cpp:494:11
    #5 0x8152bf1 in Load(FreeImageIO\*, void\*, int, int, void\*) /home/FreeImage/Source/FreeImage/PluginBMP.cpp:1135:12
    #6 0x814d00b in FreeImage\_LoadFromHandle /home/FreeImage/Source/FreeImage/Plugin.cpp:388:24
    #7 0x814d00b in FreeImage\_Load /home/FreeImage/Source/FreeImage/Plugin.cpp:408:22
    #8 0x811a7a0 in main /home/FreeImage/test.cpp:115:8
    #9 0xf7290fb8 in \_\_libc\_start\_main /build/glibc\-jYPHgv/glibc\-2.30/csu/../csu/libc\-start.c:308:16

SUMMARY: AddressSanitizer: heap\-buffer\-overflow /home/FreeImage/Source/FreeImage/PluginBMP.cpp:445:22 in LoadPixelDataRLE8(FreeImageIO\*, void\*, int, int, FIBITMAP\*)
Shadow bytes around the buggy address:
  0x3e960540: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e960550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e960560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e960570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e960580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\=>0x3e960590: 00 00 00 00\[fa\]fa fa fa fa fa fa fa fa fa fa fa
  0x3e9605a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e9605b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e9605c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e9605d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e9605e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
\==28346\==ABORTING

**1 Attachments**

**Discussion**

Log in to post a comment.

CVE-2020-21427: FreeImage / Bugs / #298 heap-buffer-overflow in function LoadPixelDataRLE8 of PluginBMP.cpp


IBM Robotic Process Automation 21.0.0 through 21.0.7 server could allow an authenticated user to view sensitive information from application logs. IBM X-Force ID: 262289.



  

**Summary**

IBM Robotic Process Automation is vulnerable to exposure of sensitive information in application logs. In specific error conditions, a login id may be logged to the application log un-obfuscated. (CVE-2023-38732)

**Vulnerability Details**

**CVEID:**   CVE-2023-38732  
**DESCRIPTION:**   IBM Robotic Process Automation server could allow an authenticated user to view sensitive information from application logs.  
CVSS Base score: 4.3  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/262289 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N)

**Affected Products and Versions**

Affected Product(s)

Version(s)

IBM Robotic Process Automation

21.0.0 - 21.0.7

IBM Robotic Process Automation for Cloud Pak

21.0.0 - 21.0.7

**Remediation/Fixes**

**IBM strongly recommends addressing the vulnerability now.**

**Product(s)**

**Version(s) number and/or range** 

**Remediation/Fix/Instructions**

IBM Robotic Process Automation

21.0.0 - 21.0.7

Download 21.0.7.1 or higher and follow these instructions.

IBM Robotic Process Automation for Cloud Pak

21.0.0 - 21.0.7

Update to 21.0.7.1 or higher using the following instructions. 

**Workarounds and Mitigations**

**Workarounds/Mitigation guidance**:

Remove older application logs that were created in versions 21.0.0 - 21.0.7.

**References**

Off

**Acknowledgement**

Mariana Penna (IBM)

**Change History**

21 Aug 2023: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU059","label":"IBM Software w\\/o TPS"},"Product":{"code":"SSC50T","label":"IBM Robotic Process Automation"},"Component":"","Platform":\[{"code":"PF033","label":"Windows"},{"code":"PF040","label":"RedHat OpenShift"}\],"Version":"21.0.0 - 21.0.7","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}\]

CVE-2023-38732: IBM Robotic Process Automation is vulnerable to exposure of sensitive information in application logs (CVE-2023-38732)

FreeImage before 1.18.0, ReadPalette function in PluginTIFF.cpp is vulnerabile to null pointer dereference.

> tl;dr:  
> When Load TIFF format files, "bitspersample" and "samplesperpixel" are read from file. If the variable biBitCount < 16 witch calc by "bitspersample" and "samplesperpixel", FreeImage will try to write nullptr.

When the program reads a TIFF format file, it will be handed to the Load() function of the 'PluginTIFF.cpp' file. And it will call ReadPalette().  
In ReadPalette function, it call FreeImage\_GetPalette() to get variable "pal", then write to variable "pal" without check.

static void 
ReadPalette(TIFF \*tiff, uint16\_t photometric, uint16\_t bitspersample, FIBITMAP \*dib) {
    RGBQUAD \*pal \= FreeImage\_GetPalette(dib);               // <---- get pal (maybe null)

    switch(photometric) {                                   // <---- write pal every case
        case PHOTOMETRIC\_MINISBLACK:    // bitmap and greyscale image types
        case PHOTOMETRIC\_MINISWHITE:
            // Monochrome image

            if (bitspersample \== 1) {
                if (photometric \== PHOTOMETRIC\_MINISWHITE) {
                    pal\[0\].rgbRed \= pal\[0\].rgbGreen \= pal\[0\].rgbBlue \= 255;         //<---- write
                    pal\[1\].rgbRed \= pal\[1\].rgbGreen \= pal\[1\].rgbBlue \= 0;
                } else {
                    pal\[0\].rgbRed \= pal\[0\].rgbGreen \= pal\[0\].rgbBlue \= 0;          //<---- write
                    pal\[1\].rgbRed \= pal\[1\].rgbGreen \= pal\[1\].rgbBlue \= 255;
                }

            } else if ((bitspersample \== 4) ||(bitspersample \== 8)) {
                // need to build the scale for greyscale images
                int ncolors \= FreeImage\_GetColorsUsed(dib);

                if (photometric \== PHOTOMETRIC\_MINISBLACK) {
                    for (int i \= 0; i < ncolors; i++) {
                        pal\[i\].rgbRed   \=                                        //<---- write
                        pal\[i\].rgbGreen \=
                        pal\[i\].rgbBlue  \= (BYTE)(i\*(255/(ncolors\-1)));
                    }
                } else {
                    for (int i \= 0; i < ncolors; i++) {
                        pal\[i\].rgbRed   \=                                        //<---- write
                        pal\[i\].rgbGreen \=
                        pal\[i\].rgbBlue  \= (BYTE)(255\-i\*(255/(ncolors\-1)));
                    }
                }
            }

            break;

        case PHOTOMETRIC\_PALETTE:   // color map indexed
            uint16\_t \*red;
            uint16\_t \*green;
            uint16\_t \*blue;

            TIFFGetField(tiff, TIFFTAG\_COLORMAP, &red, &green, &blue); 

            // load the palette in the DIB

            if (CheckColormap(1<<bitspersample, red, green, blue) \== 16) {
                for (int i \= (1 << bitspersample) \- 1; i \>= 0; i\--) {
                    pal\[i\].rgbRed \=(BYTE) CVT(red\[i\]);                             //<---- write
                    pal\[i\].rgbGreen \= (BYTE) CVT(green\[i\]);
                    pal\[i\].rgbBlue \= (BYTE) CVT(blue\[i\]);
                }
            } else {
                for (int i \= (1 << bitspersample) \- 1; i \>= 0; i\--) {
                    pal\[i\].rgbRed \= (BYTE) red\[i\];                                 //<---- write
                    pal\[i\].rgbGreen \= (BYTE) green\[i\];
                    pal\[i\].rgbBlue \= (BYTE) blue\[i\];
                }
            }

            break;
    }
}

function FreeImage\_GetPalette() maybe return NULL.

FreeImage\_GetPalette(FIBITMAP \*dib) {
    return (dib && FreeImage\_GetBPP(dib) < 16) ? (RGBQUAD \*)(((BYTE \*)FreeImage\_GetInfoHeader(dib)) + sizeof(BITMAPINFOHEADER)) : NULL;
}

unsigned DLL\_CALLCONV
FreeImage\_GetBPP(FIBITMAP \*dib) {
    return dib ? FreeImage\_GetInfoHeader(dib)\->biBitCount : 0;
}

Variable biBitCount is calc by "bitspersample" and "samplesperpixel" in function "CreateImageType", and these two variable are read from file.  
So if variable biBitCount less than 16, FreeImage will try to write nullptr. It allows an attacker to cause Denial of Service.

windbg:

ModLoad: 10000000 105ee000   D:\\temp\\\_zzz\\FreeImage.dll
ModLoad: 752b0000 752c4000   C:\\Windows\\SysWOW64\\VCRUNTIME140.dll
ModLoad: 755e0000 75643000   C:\\Windows\\SysWOW64\\WS2\_32.dll
ModLoad: 77050000 7710f000   C:\\Windows\\SysWOW64\\RPCRT4.dll
(17dc.5d5c): Break instruction exception \- code 80000003 (first chance)
eax\=00000000 ebx\=00000000 ecx\=2b110000 edx\=00000000 esi\=77442044 edi\=7744260c
eip\=774e1b72 esp\=0095f420 ebp\=0095f44c iopl\=0         nv up ei pl zr na pe nc
cs\=0023  ss\=002b  ds\=002b  es\=002b  fs\=0053  gs\=002b             efl\=00000246
ntdll!LdrpDoDebuggerBreak+0x2b:
774e1b72 cc              int     3
0:000\> g
(17dc.5d5c): Access violation \- code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
\*\*\* WARNING: Unable to verify checksum for D:\\temp\\\_zzz\\FreeImage.dll
eax\=000000ff ebx\=069ceff8 ecx\=00000000 edx\=00000000 esi\=00000000 edi\=00000000
eip\=10034fbc esp\=0095f63c ebp\=00000000 iopl\=0         nv up ei pl zr na pe nc
cs\=0023  ss\=002b  ds\=002b  es\=002b  fs\=0053  gs\=002b             efl\=00010246
FreeImage!\_TIFFmemcmp+0x3fc:
10034fbc 884500          mov     byte ptr \[ebp\],al          ss:002b:00000000\=??
0:000\> kv
 \# ChildEBP RetAddr      Args to Child
00 0095f658 10037780     00000001 00000010 06982fc8 FreeImage!\_TIFFmemcmp+0x3fc (FPO: \[Uses EBP\] \[2,5,4\])
01 0095f8a0 1000d9de     0095f8f4 06982fc8 00000010 FreeImage!\_TIFFmemcmp+0x2bc0 (FPO: \[5,139,3\])
02 0095f8d4 1000da60     00000012 0095f8f4 06982fc8 FreeImage!FreeImage\_LoadFromHandle+0x8e (FPO: \[Uses EBP\] \[4,3,2\])
03 0095f900 00b0107b     00000012 0697efee 00000000 FreeImage!FreeImage\_Load+0x50 (FPO: \[3,4,2\])

TestFile:

data:image/tiff;base64,SUkqAAgAAAAHAAABAwABAAAAIAAAAAEBAwABAAAAIAAAABcBBAAMAAAACAAAABEBBAAEAAAACAAAABYBAwABAAAAAAQAABUBAwABAAAAEAAAAEMBAwABAAAAAQAAAAAAAAA\=

CVE-2021-40266: FreeImage / Bugs / #334 A NULL pointer dereference exists in function ReadPalette() located in PluginTIFF.cpp

Buffer overflow vulnerability in quote_for_pmake in asm/nasm.c in nasm before 2.15.05 allows attackers to cause a denial of service via crafted file.

NameLast modifiedSizeDescription

Parent Directory  -   doc/2020-08-28 09:05 - Online documentation dos/2020-08-28 09:08 - MS-DOS executables linux/2020-08-28 09:08 - Linux packages macosx/2020-08-28 09:08 - MacOS X packages win32/2020-08-28 09:08 - Windows packages (32 bit) win64/2020-08-28 09:08 - Windows packages (64 bit) git.id2020-08-28 09:08 41 Corresponding git revision ID nasm-2.15.05-xdoc.tar.bz22020-08-28 09:05 900KDownloadable documentation nasm-2.15.05-xdoc.tar.gz2020-08-28 09:05 1.0MDownloadable documentation nasm-2.15.05-xdoc.tar.xz2020-08-28 09:05 804KDownloadable documentation nasm-2.15.05-xdoc.zip2020-08-28 09:05 1.0MDownloadable documentation nasm-2.15.05.tar.bz22020-08-28 09:04 1.2MSource code nasm-2.15.05.tar.gz2020-08-28 09:04 1.6MSource code nasm-2.15.05.tar.xz2020-08-28 09:04 972KSource code nasm-2.15.05.zip2020-08-28 09:05 1.8MSource code

CVE-2022-29654: Index of /pub/nasm/releasebuilds/2.15.05

An issue discovered in XZ 5.2.5 allows attackers to cause a denial of service via decompression of crafted file.

XZ Utils is free general-purpose data compression software with a high compression ratio. XZ Utils were written for POSIX-like systems, but also work on some not-so-POSIX systems. XZ Utils are the successor to LZMA Utils.

The core of the XZ Utils compression code is based on LZMA SDK, but it has been modified quite a lot to be suitable for XZ Utils. The primary compression algorithm is currently LZMA2, which is used inside the .xz container format. With typical files, XZ Utils create 30 % smaller output than gzip and 15 % smaller output than bzip2.

XZ Utils consist of several components:

*   liblzma is a compression library with an API similar to that of zlib.
*   xz is a command line tool with syntax similar to that of gzip.
*   xzdec is a decompression-only tool smaller than the full-featured xz tool.
*   A set of shell scripts (xzgrep, xzdiff, etc.) have been adapted from gzip to ease viewing, grepping, and comparing compressed files.
*   Emulation of command line tools of LZMA Utils eases transition from LZMA Utils to XZ Utils.

While liblzma has a zlib-like API, liblzma doesn't include any file I/O functions. A separate I/O library is planned, which would abstract handling of .gz, .bz2, and .xz files with an easy to use API.

**Documentation**

Man page with a keyword index: xz(1)

Doxygen-generated liblzma API documentation is also included in the source packages since XZ Utils 5.4.2.

**Source code**

Versions 5.2.12, 5.4.3, and later have been signed with Jia Tan's OpenPGP key. The older files have been signed with Lasse Collin's OpenPGP key.

See the NEWS file for a summary of changes between versions.

**Stable**

5.4.4 was released on 2023-08-02. A minor bug fix release 5.2.12 to the old stable branch was made on 2023-05-04. This is probably the last release in the 5.2.x series.

XZ Utils releases are hosted on GitHub and thus some of the links below redirect to the XZ Utils release section on GitHub. Release files are also available in the XZ Utils files section on Sourceforge.

xz-5.4.4.tar.gz (2808 KiB) signature  
xz-5.4.4.tar.bz2 (2116 KiB) signature  
xz-5.4.4.tar.zst (1680 KiB) signature  
xz-5.4.4.tar.xz (1623 KiB) signature

Probably the last release of the old stable branch:

xz-5.2.12.tar.gz (2140 KiB) signature  
xz-5.2.12.tar.bz2 (1593 KiB) signature  
xz-5.2.12.tar.zst (1317 KiB) signature  
xz-5.2.12.tar.xz (1275 KiB) signature

**Development**

The new APIs, command line options etc. in development releases should be considered unstable. Incompatible changes to unstable features may be done before they get included in a stable release.

There currently are no development releases.

**Old versions**

Source and binary packages of old XZ Utils releases are available on a separate page.

**Git repository**

The primary repository is on GitHub:

git clone https://github.com/tukaani-project/xz

It is mirrored with some delay to git.tukaani.org:

git clone https://git.tukaani.org/xz.git

Gitweb

Branches:

*   **master**: the latest development code
*   **v5.4**: fixes for the next 5.4.x release
*   **v5.2**: fixes for the next 5.2.x release
*   **v5.0**: fixes for the next 5.0.x release (unmaintained)

Building the code from the git repository requires GNU Autotools. Here are the _minimum_ versions that should work with XZ Utils; using the latest versions is strongly recommended:

*   Autoconf 2.69
*   Automake 1.12
*   gettext 0.19.6 (Note: autopoint depends on cvs!)
*   Libtool 2.4

The following are optional dependencies. The autogen.sh script will fail if they are missing but autogen.sh takes command line arguments to disable these dependencies.

*   po4a is needed for translated documentation (man pages). To build without po4a, use --no-po4a with autogen.sh.
*   Doxygen is needed to generate liblzma API documentation. To build without Doxygen, use --no-doxygen with autogen.sh.

**Security issues****xzgrep CVE-2022-1271, ZDI-CAN-16587**

A patch to fix a security vulnerability in xzgrep (CVE-2022-1271, ZDI-CAN-16587) was made public on 2022-04-07. The patch applies to 4.999.9beta to 5.2.5, 5.3.1alpha, and 5.3.2alpha. Newer XZ Utils releases include an improved fix for the problem.

It is a severe issue if an attacker can control the filenames that are given on the xzgrep command line. The vulnerability was discovered by cleemy desu wayo working with Trend Micro Zero Day Initiative. For more information, see the detailed description in the patch file linked below.

xzgrep-ZDI-CAN-16587.patch  
xzgrep-ZDI-CAN-16587.patch.sig

**Bindings****Python**

Python 3.3 includes bindings for liblzma. A backport of these bindings are available for Python 2 in the backports.lzma package.

lzmaffi is another Python binding which adds random-access decompression support.

The original Python 2 binding for liblzma is PylibLZMA.

**Perl**

Perl bindings for liblzma: IO-Compress-Lzma and Compress-Raw-Lzma.

**Haskell**

Haskell bindings.

**Delphi and Free Pascal**

Bindings and example programs for Delphi and Free Pascal are available here.

**Pre-built binaries**

Many free software operating systems already provide easy-to-install XZ Utils binaries. It doesn't make sense to provide links to all those here. Instead, binaries or links to websites providing binaries are listed here only for operating systems that don't have well-known repositories where users would get software like this.

If you have a website that provides up-to-date XZ Utils binaries for an operating system that meets the the criteria above, let me know and I will include a link here. Note that I won't host the binaries themselves without a good reason.

**Windows**

The Windows version of XZ Utils includes binaries for 32-bit and 64-bit x86. The binaries only depend on msvcrt.dll, which is available on Windows 98 and later out of the box.

*   Command line tools: xz, xzdec, lzmadec, lzmainfo
*   Shared (DLL) and static liblzma, required C header files, and liblzma.def to create import libraries for non-GNU toolchains (no import library is needed with GNU toolchain)
*   Documentation is in plain text (UTF-8) format. The man pages of the command line tools are included also as PDF.

5.2.10, 5.2.11, or 5.2.12 do not have anything significant for Windows so only 5.2.9 is here. 5.4.x builds are not provided for now.

xz-5.2.9-windows.zip (1473 KiB) signature  
xz-5.2.9-windows.7z (708 KiB) signature

**DOS**

The DOS version of XZ Utils includes only the xz command line tool and some documentation. The xz tool should work e.g. on FreeDOS (also in DOSEMU), MS-DOS, and Windows 95/98/98SE/ME. This doesn't necessarily work in DOSBox at all, and at least some problems are expected under Windows XP Command Prompt (signal handling doesn't work).

Since the DOS version is naturally going to get very little testing, it is recommended to use the Windows version instead of the DOS version if you need xz under Windows 98 or later. It is likely that that the DOS version will be updated only occasionally.

5.2.0 and later have experimental support for 8.3 filenames. See xz-dos.txt in the binary package or dos/README.txt in the source package for details.

xz-5.4.0-dos.zip (277 KiB) signature

The package includes some copylefted code from DJGPP and CWSDPMI. The relevant source code is available from their home pages, and copies are also available below.

djlsr205.zip (2000 KiB)  
djtst205.zip (1061 KiB)  
csdpmi7s.zip (88 KiB)

Juan Manuel Guerrero has made a more complete port of XZ Utils to DOS. It also has support for short file names (8.3), but the naming method is different from the one found in 5.2.0 and later. It is available from DJGPP mirrors under /current/v2apps (e.g. xz-500b.zip for 5.0.0 binaries).

**Supported platforms**

Below is an incomplete and somewhat vague (version numbers mostly missing) list of operating systems on which XZ Utils should work. The compiler(s) or toolchains are mentioned in parenthesis. GCC refers to GCC 3 or later. If you have additions or corrections, please email them to me.

*   GNU/Linux (GCC, Clang, ICC, IBM XL C)
*   GNU/HURD (GCC)
*   DragonflyBSD (GCC)
*   FreeBSD (GCC, Clang)
*   MirBSD (GCC)
*   NetBSD (GCC)
*   OpenBSD (Clang, GCC)
*   MINIX 3 (GCC) \[1\]
*   Haiku (GCC4)
*   Mac OS X (GCC)
*   Solaris 8, 9, 10, 11 (GCC, Sun Studio) \[3\]
*   Solaris 2.6, 7 (GCC)
*   HP-UX (GCC, HP ANSI C) \[2\]
*   Tru64 (GCC, Compaq C compiler) \[1\]
*   IRIX (MIPSpro) \[1\]
*   AIX (GCC, IBM XL C)
*   z/OS (IBM XL C)
*   QNX (compilers?)
*   OpenVMS (HP C compiler) \[1\]
*   OpenVOS 17 (GCC)
*   SCO OpenServer 5.0.7 (GCC 3.4.6, 4.2.4) \[4\]
*   Windows 95 and later (GCC/MinGW, GCC/MinGW-w64, GCC/Cygwin, GCC/Interix, Visual Studio (VS can only build liblzma)) \[1\]
*   OS/2, eComStation (GCC)
*   DOS e.g. FreeDOS and MS-DOS (GCC/DJGPP) \[1\]

\[1\] See also the platform-specific notes in the INSTALL file.

\[2\] 2010-09-22: HP ANSI C compiler crashes when compiling XZ Utils on PA-RISC. On Itanium there are no problems.

\[3\] On Solaris 8 and 9 one may need to pass ac\_cv\_prog\_cc\_c99= to configure if using Sun Studio.

\[4\] Use --disable-threads when running configure.

**Licensing**

The most interesting parts of XZ Utils (e.g. liblzma) are in the public domain. You can do whatever you want with the public domain parts.

Some parts of XZ Utils (e.g. build system and some utilities) are under different free software licenses such as GNU LGPLv2.1, GNU GPLv2, or GNU GPLv3.

See the file COPYING for more details.

CVE-2020-22916: XZ Utils

A heap overflow vulnerability in FreeImage 1.18.0 via the ofLoad function in PluginTIFF.cpp.

*   Summary
*   Files
*   Reviews
*   Support
*   Mailing Lists
*   Code
*   Tickets ▾
    *   Feature Requests
    *   Patches
    *   Bugs
    *   Support Requests
*   News
*   Discussion
*   FreeImage

Menu ▾ ▴

Status: open

Owner: nobody

Labels: None

Priority: 5

Updated: 2021-08-26

Created: 2021-08-26

Private: No

> tl;dr:  
> When Load TIFF files, "ImageWidth" and "TileWidth" is read from file. FreeImage alloc memory size is controlled by "ImageWidth", but FreeImage write memory size if controlled by "TileWidth". if result of "TileWidth" diff with "ImageWidth", it will writing data more than the allocated memory.

When the program reads a TIFF file, it will be handed to the Load function of the 'PluginTIFF.cpp' file,  
in Load function, we alloc memory by CreateImageType(), and write memory in Load function with "memcpy". And the "height", "width", "bitspersample", "samplesperpixel", "tileRowSize" and "imageRowSize" is read from file.

static FIBITMAP \* DLL\_CALLCONV
Load(FreeImageIO \*io, fi\_handle handle, int page, int flags, void \*data) {
......
    uint32\_t height \= 0; 
    uint32\_t width \= 0; 
    uint16\_t bitspersample \= 1;
    uint16\_t samplesperpixel \= 1;
......
        TIFFGetField(tif, TIFFTAG\_IMAGEWIDTH, &width);
        TIFFGetField(tif, TIFFTAG\_IMAGELENGTH, &height);
        TIFFGetField(tif, TIFFTAG\_SAMPLESPERPIXEL, &samplesperpixel);
        TIFFGetField(tif, TIFFTAG\_BITSPERSAMPLE, &bitspersample);
        TIFFGetField(tif, TIFFTAG\_ROWSPERSTRIP, &rowsperstrip);             
        TIFFGetField(tif, TIFFTAG\_ICCPROFILE, &iccSize, &iccBuf);
        TIFFGetFieldDefaulted(tif, TIFFTAG\_PLANARCONFIG, &planar\_config);
.......
        // \---------------------------------------------------------------------------------

        if(loadMethod \== LoadAsRBGA) {
......
        } else if(loadMethod \== LoadAsTiled) {
            // \---------------------------------------------------------------------------------
            // Tiled image loading
            // \---------------------------------------------------------------------------------

            uint32\_t tileWidth, tileHeight;
            uint32\_t src\_line \= 0;

            // create a new DIB                                                     v\-------- alloc memory there
            dib \= CreateImageType( header\_only, image\_type, width, height, bitspersample, samplesperpixel);
......
                // calculate src line and dst pitch
                unsigned dst\_pitch \= FreeImage\_GetPitch(dib);
                uint32\_t tileRowSize \= (uint32\_t)TIFFTileRowSize(tif);
                uint32\_t imageRowSize \= (uint32\_t)TIFFScanlineSize(tif);

                // In the tiff file the lines are saved from up to down 
                // In a DIB the lines must be saved from down to up

                BYTE \*bits \= FreeImage\_GetScanLine(dib, height \- 1);

                for (uint32\_t y \= 0; y < height; y += tileHeight) {                 // <---- write memory there     
                    int32\_t nrows \= (y + tileHeight \> height ? height \- y : tileHeight);                    

                    for (uint32\_t x \= 0, rowSize \= 0; x < width; x += tileWidth, rowSize += tileRowSize) {
                        memset(tileBuffer, 0, tileSize);

                        // read one tile
                        if (TIFFReadTile(tif, tileBuffer, x, y, 0, 0) < 0) {
                            free(tileBuffer);
                            throw "Corrupted tiled TIFF file";
                        }
                        // convert to strip
                        if(x + tileWidth \> width) {
                            src\_line \= imageRowSize \- rowSize;
                        } else {
                            src\_line \= tileRowSize;
                        }
                        BYTE \*src\_bits \= tileBuffer;
                        BYTE \*dst\_bits \= bits + rowSize;
                        for(int k \= 0; k < nrows; k++) {
                            memcpy(dst\_bits, src\_bits, MIN(dst\_pitch, src\_line));
                            src\_bits += tileRowSize;
                            dst\_bits \-= dst\_pitch;
                        }
                    }

                    bits \-= nrows \* dst\_pitch;
                }
......
}

CreateImageType() alloc memory by "width","height","bitspersample" and "samplesperpixel".

static FIBITMAP\* 
CreateImageType(BOOL header\_only, FREE\_IMAGE\_TYPE fit, int width, int height, uint16\_t bitspersample, uint16\_t samplesperpixel) {
    FIBITMAP \*dib \= NULL;
......
    int bpp \= bitspersample \* samplesperpixel;      //<---- bpp == bitspersample \* samplesperpixel
......
    dib \= FreeImage\_AllocateHeader(header\_only, width, height, bpp, FI\_RGBA\_RED\_MASK, FI\_RGBA\_GREEN\_MASK, FI\_RGBA\_BLUE\_MASK);
......
    return dib;
}

FIBITMAP \* DLL\_CALLCONV
FreeImage\_AllocateHeader(BOOL header\_only, int width, int height, int bpp, unsigned red\_mask, unsigned green\_mask, unsigned blue\_mask) {
    return FreeImage\_AllocateBitmap(header\_only, NULL, 0, FIT\_BITMAP, width, height, bpp, red\_mask, green\_mask, blue\_mask);
}

static FIBITMAP \* 
FreeImage\_AllocateBitmap(BOOL header\_only, BYTE \*ext\_bits, unsigned ext\_pitch, FREE\_IMAGE\_TYPE type, int width, int height, int bpp, unsigned red\_mask, unsigned green\_mask, unsigned blue\_mask) {
......

        size\_t dib\_size \= FreeImage\_GetInternalImageSize(header\_only || ext\_bits, width, height, bpp, need\_masks);      //<---- calc alloc size by bpp, width and height

        if(dib\_size \== 0) {
            // memory allocation will fail (probably a malloc overflow)
            free(bitmap);
            return NULL;
        }

        bitmap\->data \= (BYTE \*)FreeImage\_Aligned\_Malloc(dib\_size \* sizeof(BYTE), FIBITMAP\_ALIGNMENT);   //<---- real alloc function
.......
}

in FreeImage\_GetInternalImageSize(), it calc alloc size

static size\_t
FreeImage\_GetInternalImageSize(BOOL header\_only, unsigned width, unsigned height, unsigned bpp, BOOL need\_masks) {
size\_t dib\_size \= sizeof(FREEIMAGEHEADER);
......
if(!header\_only) {
const size\_t header\_size \= dib\_size;

// pixels are aligned on a 16 bytes boundary
dib\_size += (size\_t)CalculatePitch(CalculateLine(width, bpp)) \* (size\_t)height;    //<--- alloc size by line lenght \* height, line lenght calc by width and bpp( \= bitspersample \* samplesperpixel)
......
}

return dib\_size;
}

but when we write memory, the read size calc by "tileWidth" and "width", loop (tileHeight//height) \* (tileWidth//width) times.

                for (uint32\_t y \= 0; y < height; y += tileHeight) {                                            //<-- loop tileHeight//height times
                    int32\_t nrows \= (y + tileHeight \> height ? height \- y : tileHeight);                    

                    for (uint32\_t x \= 0, rowSize \= 0; x < width; x += tileWidth, rowSize += tileRowSize) { //<-- loop tileWidth//width times
                        memset(tileBuffer, 0, tileSize);

                        // read one tile
                        if (TIFFReadTile(tif, tileBuffer, x, y, 0, 0) < 0) {
                            free(tileBuffer);
                            throw "Corrupted tiled TIFF file";
                        }
                        // convert to strip
                        if(x + tileWidth \> width) {
                            src\_line \= imageRowSize \- rowSize;
                        } else {
                            src\_line \= tileRowSize;
                        }
                        BYTE \*src\_bits \= tileBuffer;
                        BYTE \*dst\_bits \= bits + rowSize;
                        for(int k \= 0; k < nrows; k++) {
                            memcpy(dst\_bits, src\_bits, MIN(dst\_pitch, src\_line));
                            src\_bits += tileRowSize;
                            dst\_bits \-= dst\_pitch;
                        }
                    }

                    bits \-= nrows \* dst\_pitch;
                }

Finally, it will cause the heap overflow if we make the result of "TileWidth" diff with "ImageWidth". Moreover, it may has the risk of arbitrary code execution.

windbg:

ModLoad: 10000000 105ee000   D:\\temp\\\_zzz\\FreeImage.dll
ModLoad: 752b0000 752c4000   C:\\Windows\\SysWOW64\\VCRUNTIME140.dll
ModLoad: 755e0000 75643000   C:\\Windows\\SysWOW64\\WS2\_32.dll
ModLoad: 77050000 7710f000   C:\\Windows\\SysWOW64\\RPCRT4.dll
(8b8c.710): Break instruction exception \- code 80000003 (first chance)
eax\=00000000 ebx\=00000000 ecx\=dd680000 edx\=00000000 esi\=77442044 edi\=7744260c
eip\=774e1b72 esp\=006ff63c ebp\=006ff668 iopl\=0         nv up ei pl zr na pe nc
cs\=0023  ss\=002b  ds\=002b  es\=002b  fs\=0053  gs\=002b             efl\=00000246
ntdll!LdrpDoDebuggerBreak+0x2b:
774e1b72 cc              int     3
0:000\> g
(8b8c.710): Access violation \- code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
\*\*\* WARNING: Unable to verify checksum for D:\\temp\\\_zzz\\FreeImage.dll
eax\=00000049 ebx\=00000008 ecx\=00000001 edx\=00000001 esi\=06667fd0 edi\=06662000
eip\=102a6e8f esp\=006ff86c ebp\=006ffa58 iopl\=0         nv up ei pl nz na po nc
cs\=0023  ss\=002b  ds\=002b  es\=002b  fs\=0053  gs\=002b             efl\=00010202
FreeImage!memcpy+0x51f:
102a6e8f 8807            mov     byte ptr \[edi\],al          ds:002b:06662000\=??
0:000\> db edi\-0x20
06661fe0  00 00 00 00 00 00 00 00\-2a 2a 2a 2a 2a 2a 2a 2a  ........\*\*\*\*\*\*\*\*
06661ff0  49 49 49 49 49 49 49 49-49 49 49 49 49 49 49 49  IIIIIIIIIIIIIIII
06662000  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
06662010  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
06662020  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
06662030  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
06662040  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
06662050  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:000\> kv
 \# ChildEBP RetAddr      Args to Child              
00 006ff870 100378e8     06662000 06667fd0 00000001 FreeImage!memcpy+0x51f (FPO: \[3,0,2\]) (CONV: cdecl) \[d:\\agent\\\_work\\4\\s\\src\\vctools\\crt\\vcruntime\\src\\string\\i386\\memcpy.asm @ 669\] 
01 006ffabc 1000d9de     006ffb10 06619fc8 06667fd0 FreeImage!\_TIFFmemcmp+0x2d28 (FPO: \[5,139,3\])
02 006ffaf0 1000da60     00000012 006ffb10 06619fc8 FreeImage!FreeImage\_LoadFromHandle+0x8e (FPO: \[Uses EBP\] \[4,3,2\])
03 006ffb1c 00b0107b     00000012 06615fee 00000000 FreeImage!FreeImage\_Load+0x50 (FPO: \[3,4,2\])

TestFile:

data:image/tiff;base64,SUkqAAgAAAAGAAABAwABAAAAMAAwMAEBAwABAAAAMAAwMBcBBAAYAAAACAAAABEBAwABAAAAMAABABYBAwABAAAAMAABAEIBAwABAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\=

**2 Attachments**

**Discussion**

Log in to post a comment.

Tag

#windows