An issue was discovered in PostgreSQL 12.2 allows attackers to cause a denial of service via repeatedly sending SIGHUP signals.

CVE-2020-21469: Buffer overflow when continuously send SIGHUP to postgres

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

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

Menu ▾ ▴

Milestone: None

Status: pending

Labels: None

Priority: 5

Updated: 2021-04-04

Created: 2019-12-04

Private: No

There is a heap-buffer-overflow in function C\_IStream::read of PluginEXR.cpp whick may cause a code execution or denial of service. Version of Freeimage is 3180. This vulneribility can be reproduced with the attachment image file.  
Asan log as below:

\==2194\==ERROR: AddressSanitizer: heap\-buffer\-overflow on address 0xf3b06d00 at pc 0x08087ebd bp 0xffe389d8 sp 0xffe385b0
WRITE of size 329845 at 0xf3b06d00 thread T0
    #0 0x8087ebc in fread (/home/FreeImage/test+0x8087ebc)
    #1 0x883a341 in \_ReadProc(void\*, unsigned int, unsigned int, void\*) /home/FreeImage/Source/FreeImage/FreeImageIO.cpp:32:19
    #2 0x816a96f in C\_IStream::read(char\*, int) /home/FreeImage/Source/FreeImage/PluginEXR.cpp:66:26
    #3 0x851cd1f in Imf\_2\_2::(anonymous namespace)::readPixelData(Imf\_2\_2::InputStreamMutex\*, Imf\_2\_2::ScanLineInputFile::Data\*, int, char\*&, int&) /home/FreeImage/Source/OpenEXR/IlmImf/ImfScanLineInputFile.cpp:440:25
    #4 0x8519bd7 in Imf\_2\_2::(anonymous namespace)::newLineBufferTask(IlmThread\_2\_2::TaskGroup\*, Imf\_2\_2::InputStreamMutex\*, Imf\_2\_2::ScanLineInputFile::Data\*, int, int, int, Imf\_2\_2::OptimizationMode) /home/FreeImage/Source/OpenEXR/IlmImf/ImfScanLineInputFile.cpp:1033:14
    #5 0x8519bd7 in Imf\_2\_2::ScanLineInputFile::readPixels(int, int) /home/FreeImage/Source/OpenEXR/IlmImf/ImfScanLineInputFile.cpp:1612:44
    #6 0x849dba8 in Imf\_2\_2::InputFile::readPixels(int, int) /home/FreeImage/Source/OpenEXR/IlmImf/ImfInputFile.cpp:815:23
    #7 0x81638a2 in Load(FreeImageIO\*, void\*, int, int, void\*) /home/FreeImage/Source/FreeImage/PluginEXR.cpp:428:9
    #8 0x814d00b in FreeImage\_LoadFromHandle /home/FreeImage/Source/FreeImage/Plugin.cpp:388:24
    #9 0x814d00b in FreeImage\_Load /home/FreeImage/Source/FreeImage/Plugin.cpp:408:22
    #10 0x811a7a0 in main /home/FreeImage/test.cpp:115:8
    #11 0xf71fefb8 in \_\_libc\_start\_main /build/glibc\-jYPHgv/glibc\-2.30/csu/../csu/libc\-start.c:308:16
    #12 0x806f8f5 in \_start (/home/FreeImage/test+0x806f8f5)

0xf3b06d00 is located 0 bytes to the right of 6144\-byte region \[0xf3b05500,0xf3b06d00)
allocated by thread T0 here:
    #0 0x80e6675 in malloc (/home/FreeImage/test+0x80e6675)
    #1 0x8510c1f in Imf\_2\_2::EXRAllocAligned(unsigned int, unsigned int) /home/FreeImage/Source/OpenEXR/IlmImf/ImfSystemSpecific.h:139:12
    #2 0x8510c1f in Imf\_2\_2::ScanLineInputFile::initialize(Imf\_2\_2::Header const&) /home/FreeImage/Source/OpenEXR/IlmImf/ImfScanLineInputFile.cpp:1132:58
    #3 0x8511e19 in Imf\_2\_2::ScanLineInputFile::ScanLineInputFile(Imf\_2\_2::Header const&, Imf\_2\_2::IStream\*, int) /home/FreeImage/Source/OpenEXR/IlmImf/ImfScanLineInputFile.cpp:1190:5
    #4 0x8496904 in Imf\_2\_2::InputFile::initialize() /home/FreeImage/Source/OpenEXR/IlmImf/ImfInputFile.cpp:553:32
    #5 0x8498d15 in Imf\_2\_2::InputFile::InputFile(Imf\_2\_2::IStream&, int) /home/FreeImage/Source/OpenEXR/IlmImf/ImfInputFile.cpp:450:13
    #6 0x8161d1f in Load(FreeImageIO\*, void\*, int, int, void\*) /home/FreeImage/Source/FreeImage/PluginEXR.cpp:193:18
    #7 0x814d00b in FreeImage\_LoadFromHandle /home/FreeImage/Source/FreeImage/Plugin.cpp:388:24
    #8 0x814d00b in FreeImage\_Load /home/FreeImage/Source/FreeImage/Plugin.cpp:408:22
    #9 0x811a7a0 in main /home/FreeImage/test.cpp:115:8
    #10 0xf71fefb8 in \_\_libc\_start\_main /build/glibc\-jYPHgv/glibc\-2.30/csu/../csu/libc\-start.c:308:16

SUMMARY: AddressSanitizer: heap\-buffer\-overflow (/home/FreeImage/test+0x8087ebc) in fread
Shadow bytes around the buggy address:
  0x3e760d50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e760d60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e760d70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e760d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e760d90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\=>0x3e760da0:\[fa\]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e760db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e760dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e760dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e760de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e760df0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
\==2194\==ABORTING

**1 Attachments**

**Discussion**

Log in to post a comment.

CVE-2020-21426: FreeImage / Bugs / #300 heap-buffer-overflow in function C_IStream::read of PluginEXR.cpp

dpic 2021.04.10 has a Heap Buffer Overflow in themakevar() function in dpic.y

Skip to content

**Heap-based Buffer Overflow in the makevar() function**

Hi,

I found a **heap buffer overflow write of size 1** in the makevar() function, in dpic.y on dpic 2021.04.10 (commit: d317e406)

Heap buffer overflow issue: for loop in https://gitlab.com/aplevich/dpic/-/blob/master/dpic.y#L5769 as given below:

    void
    makevar(char *s, int ln, double varval)
    {
      nametype *vn, *lastvar, *namptr;
      int j, tstval;
      for (j = 0; j < ln; j++) { chbuf[chbufi + j] = s[j]; }
      ...

And, as per the code, https://gitlab.com/aplevich/dpic/-/blob/master/main.c#L1777

chbuf = malloc (sizeof (chbufarray)); if (chbuf==NULL){ fatal(9); } the sizeof chbufarray of char datatype is: https://gitlab.com/aplevich/dpic/-/blob/master/dpic.h#L78

    typedef Char chbufarray[CHBUFSIZ + 1];

and upper limit of chbuf buffers is CHBUFSIZ which is of 4095 limit so sizeof (chbufarray) becomes 4096 and while running the executable, the value of chbufi can be seen as 4089 for this test file, so it means any value which is greater than 6 will cause heap buffer overflow write in the makevar() function for loop, in this case.

    if ln (second input parameter of makevar()) is 7:
        chbuf[4089 + 6] = s[6];
        chbuf[4095] = s[6];
    
    if ln is greater than 7 like 8 or 9:
        chbuf[4089 + 7] = s[6];
        which is, chbuf[4096] = s[6]; // heap buffer overflow of write 1 byte

And, as per the code: https://gitlab.com/aplevich/dpic/-/blob/master/dpic.y#L5735 as given below, it can be seen as many makevar() function has second input parameter greater than 7

    void
    mkOptionVars(void)
    {
        makevar("dpicopt", 7, drawmode);
        if (safemode) { i = 1; } else { i = 0; }
        makevar("optsafe", 7, i);
        makevar("optMFpic", 8, MFpic);
        makevar("optMpost", 8, MPost);
        makevar("optPDF", 6, PDF);
        makevar("optPGF", 6, PGF);
        makevar("optPict2e", 9, Pict2e);
        makevar("optPS", 5, PS);
        makevar("optPSfrag", 9, PSfrag);
        makevar("optPSTricks", 11, PSTricks);
        makevar("optSVG", 6, SVG);
        makevar("optTeX", 6, TeX);
        makevar("opttTeX", 7, tTeX);
        makevar("optxfig", 7, xfig);
        ...

    DISTRIB_ID=Ubuntu
    DISTRIB_RELEASE=20.04
    DISTRIB_CODENAME=focal
    DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"

Attaching a reproducer: heap\_bof\_write\_test

the issue can be reproduced by running:

dpic heap_bof_write_test

With ASAN report

    =================================================================
    ==582741==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x621000001100 at pc 0x000000538ae3 bp 0x7ffead55dc90 sp 0x7ffead55dc88
    WRITE of size 1 at 0x621000001100 thread T0
        #0 0x538ae2 in makevar /home/bsdboy/projects/again/dpic/dpic.y:5769:48
        #1 0x511042 in mkOptionVars /home/bsdboy/projects/again/dpic/dpic.y:5748:5
        #2 0x4de391 in yyparse /home/bsdboy/projects/again/dpic/dpic.y:495:19
        #3 0x4dbcb4 in main /home/bsdboy/projects/again/dpic/main.c:1813:13
        #4 0x7f9a899740b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #5 0x41c65d in _start (/home/bsdboy/projects/again/dpic/dpic+0x41c65d)
    
    0x621000001100 is located 0 bytes to the right of 4096-byte region [0x621000000100,0x621000001100)
    allocated by thread T0 here:
        #0 0x4978bd in malloc (/home/bsdboy/projects/again/dpic/dpic+0x4978bd)
        #1 0x4dbb9d in main /home/bsdboy/projects/again/dpic/main.c:1779:11
        #2 0x7f9a899740b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/bsdboy/projects/again/dpic/dpic.y:5769:48 in makevar
    Shadow bytes around the buggy address:
      0x0c427fff81d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c427fff81e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c427fff81f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c427fff8200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c427fff8210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c427fff8220:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fff8230: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fff8240: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fff8250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fff8260: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c427fff8270: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==582741==ABORTING

Edited May 09, 2021 by Neeraj Pal

CVE-2021-33388: Heap-based Buffer Overflow in the makevar() function (#8) · Issues · Dwight Aplevich / dpic · GitLab

dpic 2021.04.10 has a use-after-free in thedeletestringbox() function in dpic.y. A different vulnerablility than CVE-2021-32421.

Skip to content

**Heap Use After Free in the deletestringbox() function (different than #7)**

Hi,

While fuzzing dpic 2021.04.10 (commit: d317e406), I found a heap use-after-free in the cmpstring() function, in dpic.y:L5724.

I have already confirmed the previous issue: #7 (closed) and that is already patched but this seems to be similar but not the same with this input test file and in the same deletestringbox() function.

    DISTRIB_ID=Ubuntu
    DISTRIB_RELEASE=20.04
    DISTRIB_CODENAME=focal
    DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"

Attaching a reproducer: heap-uaf-read-test-deletestringbox

the issue can be reproduced by running:

dpic heap-uaf-read-test-deletestringbox

    =================================================================
    ==3692838==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d000000060 at pc 0x0000005094cf bp 0x7ffdf2d88ed0 sp 0x7ffdf2d88ec8
    READ of size 8 at 0x60d000000060 thread T0
        #0 0x5094ce in deletestringbox /home/bsdboy/projects/again/dpic/dpic.y:5724:19
        #1 0x4fce1a in yyparse /home/bsdboy/projects/again/dpic/dpic.y:2839:4
        #2 0x4d69ac in main /home/bsdboy/projects/again/dpic/main.c:1813:13
        #3 0x7f638b8eb0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #4 0x41c3dd in _start (/home/bsdboy/projects/again/dpic/dpic+0x41c3dd)
    
    0x60d000000060 is located 32 bytes inside of 136-byte region [0x60d000000040,0x60d0000000c8)
    freed by thread T0 here:
        #0 0x4973d2 in free (/home/bsdboy/projects/again/dpic/dpic+0x4973d2)
        #1 0x501778 in deletetree /home/bsdboy/projects/again/dpic/dpic.y:3917:12
        #2 0x50989b in deletestringbox /home/bsdboy/projects/again/dpic/dpic.y:5732:3
        #3 0x4fce1a in yyparse /home/bsdboy/projects/again/dpic/dpic.y:2839:4
        #4 0x4d69ac in main /home/bsdboy/projects/again/dpic/main.c:1813:13
        #5 0x7f638b8eb0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    previously allocated by thread T0 here:
        #0 0x49763d in malloc (/home/bsdboy/projects/again/dpic/dpic+0x49763d)
        #1 0x507b27 in newprim /home/bsdboy/projects/again/dpic/dpic.y:4984:13
        #2 0x4deb1a in yyparse /home/bsdboy/projects/again/dpic/dpic.y:892:19
        #3 0x4d69ac in main /home/bsdboy/projects/again/dpic/main.c:1813:13
        #4 0x7f638b8eb0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    SUMMARY: AddressSanitizer: heap-use-after-free /home/bsdboy/projects/again/dpic/dpic.y:5724:19 in deletestringbox
    Shadow bytes around the buggy address:
      0x0c1a7fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1a7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1a7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1a7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c1a7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c1a7fff8000: fa fa fa fa fa fa fa fa fd fd fd fd[fd]fd fd fd
      0x0c1a7fff8010: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa
      0x0c1a7fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1a7fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1a7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c1a7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==3692838==ABORTING

CVE-2021-33390: Heap Use After Free in the deletestringbox() function (different than #7) (#10) · Issues · Dwight Aplevich / dpic · GitLab

dpic 2021.01.01 has a Global buffer overflow in theyylex() function in main.c and reads out of the bound array.

Skip to content

GitLab

*   *   GitLab: the DevOps platform
    *   Explore GitLab
    *   Install GitLab
    *   How GitLab compares
    *   Get started
    *   GitLab docs
    *   GitLab Learn
    
*   Pricing
*   Talk to an expert

*   /
    
*   

*   Help
    
    *   Help
    *   Support
    *   Community forum
    
    *   Submit feedback
    *   Contribute to GitLab
    *   Switch to GitLab Next
    
*   *   
    
    Projects Groups Topics Snippets
    
*   Register
*   Sign in

*   Dwight Aplevich
*   dpic
*   Commits
*   d317e406

**Commit d317e406** authored Apr 10, 2021 by  **Dwight Aplevich**

Browse files

**Improved robustness to fuzzed input**

parent 68ab9432

*   Changes 33

Expand all Hide whitespace changes

Inline Side-by-side

*   Neeraj Pal @bsdb0y
    
    mentioned in issue #8 (closed)
    
    · May 09, 2021
    
    mentioned in issue #8 (closed)
    
    mentioned in issue #8
    
    Toggle commit list
    
*   Neeraj Pal @bsdb0y
    
    mentioned in issue #9 (closed)
    
    · May 09, 2021
    
    mentioned in issue #9 (closed)
    
    mentioned in issue #9
    
    Toggle commit list
    
*   Neeraj Pal @bsdb0y
    
    mentioned in issue #10 (closed)
    
    · May 09, 2021
    
    mentioned in issue #10 (closed)
    
    mentioned in issue #10
    
    Toggle commit list
    
*   Neeraj Pal @bsdb0y
    
    mentioned in issue #11 (closed)
    
    · May 09, 2021
    
    mentioned in issue #11 (closed)
    
    mentioned in issue #11
    
    Toggle commit list
    

0% or .

You are about to add **0 people** to the discussion. Proceed with caution.

Finish editing this message first!

Please register or sign in to comment

CVE-2021-32422: Improved robustness to fuzzed input (d317e406) · Commits · Dwight Aplevich / dpic · GitLab

An issue was discovered in GNU Binutils 2.34. It is a memory leak when process microblaze-dis.c. This one will consume memory on each insn disassembled.

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

Please press **Back** and try again.

CVE-2020-21490: Invalid Bug ID

A reflected cross site scripting (XSS) vulnerability was discovered on Samsung sww-3400rw Router devices via the m2 parameter of the sess-bin/command.cgi

CVE-2020-22181

Buffer Overflow vulnerability in PSDParser.cpp::ReadImageLine() in FreeImage 3.19.0 [r1859] allows remote attackers to ru narbitrary code via use of crafted psd file.

1.PluginICO.cpp/LoadStandardIcon( )/heap\_overflow  
When the program reads a ico file, it will be handed to the Load function of the 'PluginICO.cpp' file, but in the '332' line of the program, when the 'io->read\_proc' function is executed, the size of the "height \* pitch" are not considered, which will cause the heap\_overflow.  
  
  
From the above,we can find that the "FreeImage\_GetBits" function return a pointer,which corresponds to the buffer as follows.  
  
The buffer size is (0x259aa44df50 + 0x663 - 259aa44df50) 0xa3  
  
  
At the same time ,the "handle" stores the pointer to the ICO data we read in. Moreover,we can see that the buffer has read the ico data when the 'io->read\_proc' function is executed.  
  
Also the size of the "height \* pitch" can be controlled.  
Finally,it will cause the heap overflow if we make the "height \* pitch" is greater than the size of buffer. Moreover, it may has the risk of arbitrary code execution.

2.PSDParser.cpp/ReadImageLine( )/heap\_overflow  
When the program reads a psd file, it will be handed to the Load function of the 'PSDParser.cpp' file, but in the '1298' line of the program, when the 'memcpy' function is executed, the size of the "lineSize" are not considered, which will cause the heap\_overflow.  
  
  
  
The lineSize is determined by the nWidth we passed in,which is controllable.  
  
The buffer size of "dst" is (0x19f53cdffe0 + 0x2013 -0x0000019f53ce1f90) 0x63  
  
  
Also the content of "src" comes from the psd file we read in.  
Finally,it will cause the heap overflow when the 'memcpy' function is executed,if we make the 'lineSize' is greater than the size of buffer.Moreover, it may has the risk of arbitrary code execution.

3.PSDParser.cpp/UnpackRLE( )/Integer overflow  
A Integer overflow in line "1328" of the "psdParser::UnpackRLE" function in "PSDParser.cpp". Where the "srcSize" is an unsigned integer. But it is still recognized as a positive number in the memory when "srcSize-=len" is a negative number(0xffffff94). Eventually results in "srcSize > 0", which causes rle\_line to generate an out-of-bounds read.  
  

4.PSDParser.cpp/psdThumbnail::Read( )/heap\_overflow  
When the program reads a psd file, it will be handed to the Load function of the 'PSDParser.cpp' file, but in the '801' line of the "psdThumbnail::Read", when the 'memcpy' function is executed, the size of the "\_Width \* \_BitPerPixel" are not considered, which will cause the heap\_overflow.  
  
The buffer size of "dst\_line\_start" is (0x231fdfde8f0 + 0x70b - 0x00000231fdfdefe4 ) 0x17 and the "\_Width \* \_BitPerPixel" is determined by the nWidth we passed in,which is controllable.  
  
In the code above，the "io->read\_proc(line\_start, \_WidthBytes, 1, handle)" function is executed, where the "handle" stores the pointer to the psd data we read in. Also the "\_WidthBytes" is controllable,which means the content of "line\_start" is controllable.  
  
Finally,it will cause the heap overflow when the 'memcpy' function is executed,if we make the "\_Width \* \_BitPerPixel" is greater than the size of buffer.Moreover, it may has the risk of arbitrary code execution.

Author by avscx.z@dbappsecurity.com.cn

 

Last edit: Avscx 2020-08-07

CVE-2020-24295: FreeImage / Discussion / Developers: Four Vulnerabilities about Freeimage 3.19.0

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

Cross Site Scripting (XSS) vulnerability in Cacti 1.2.21 via crafted POST request to graphs_new.php.

XSS vulnerability in Cacti https://github.com/Cacti/cacti version v1.2.21

The path of the vulnerability. In file https://github.com/Cacti/cacti/blob/develop/graphs\_new.php

//line 40
switch (get\_request\_var('action')) {
              case 'save':
                            form\_save();
 
//line 117 the source in $\_POST
function form\_save() {
              if (isset\_request\_var('save\_component\_graph')) {
                            /\* summarize the 'create graph from host template/snmp index' stuff into an array \*/
                            foreach ($\_POST as $var => $val) {
                            //…..
                           if (strpos($var, 'sgg\_') !== false) {
                                                         // Note: the source in $snmp\_query\_id then function store\_get\_selected\_dq\_index will be called
                                                         $snmp\_query\_id = str\_replace('sgg\_', '', $var);
                                                        store\_get\_selected\_dq\_index($snmp\_query\_id);
                                          }
                            }
            //…….
}
// line 100
Note the source in $snmp\_query\_id
function store\_get\_selected\_dq\_index($snmp\_query\_id) {
              // ….
              } elseif (isset\_request\_var('sgg\_' . $snmp\_query\_id)) {
                             // Note: get\_filter\_request\_var will be called
                            $selected = get\_filter\_request\_var('sgg\_' . $snmp\_query\_id);
              }
//….
}

In file https://github.com/Cacti/cacti/blob/develop/lib/html\_utility.php

//line 424
// the source in the argument $name
function get\_filter\_request\_var($name, $filter = FILTER\_VALIDATE\_INT, $options = array()) {
//….
//line 503
if ($value === false) {
                                          if ($filter == FILTER\_VALIDATE\_IS\_REGEX) {
                                                         //….
                                          } else {
                                                         // Note: function die\_html\_input\_error will be called
                                                         die\_html\_input\_error($name, get\_nfilter\_request\_var($name));
                                          }
                            }

In file https://github.com/Cacti/cacti/blob/develop/lib/html\_validate.php

//line 47
// Note: the source in $variable
function die\_html\_input\_error($variable = '', $value = '', $message = '') {
              //….
 
              if ($message == '') {
              // Note: the $message will include the $variable as I will explain later, then it will be printed
              $message = \_\_('Validation error for variable %s with a value of %s.  See backtrace below for more details.', $variable, $value);
              }
              //Note: the print of the $message
             $variable = ($variable != '' ? ', Variable:' . $variable : '');
              $value    = ($value    != '' ? ', Value:'    . $value    : '');
 
              if (defined('CACTI\_CLI\_ONLY')) {
                            cacti\_debug\_backtrace('Validation Error' . $variable . $value, false);
                            print $message . PHP\_EOL;
                            exit(1);
              } elseif (isset\_request\_var('json')) {
                            cacti\_debug\_backtrace('Validation Error' . $variable . $value, false);
                            print json\_encode(
                                          array(
                                                         'status' => '500',
                                                         'statusText' => \_\_('Validation Error'),
                                                         'responseText' => $message
                                          )
                            );
              } else {
                            cacti\_debug\_backtrace('Validation Error' . $variable . $value, true);
 
                            print "<table style='width:100%;text-align:center;'><tr><td>$message</td></tr></table>";
                            bottom\_footer();
              }
 
              exit;
}
}

In file https://github.com/Cacti/cacti/blob/develop/include/global\_languages.php

//line 432
function \_\_() {
              global $l10n;
 
              $args = func\_get\_args();
              $num  = func\_num\_args();
 
              //….
                            else{
                                          $args\[0\] = \_\_gettext($args\[0\]);
                            }
 
                            /\* process return string against input arguments \*/
                            return \_\_uf(call\_user\_func\_array('sprintf', $args));
              }
}
 
//line 393
function \_\_gettext($text, $domain = 'cacti') {
              //….
 
              if (!isset($translated)) {
                            $translated = $text;
              } 
 
              //…..
              return \_\_uf($translated);
}
 
//line 428
function \_\_uf($text) {
              return str\_replace('%%', '%', $text);
}

The vulnerability is confirmed by the developers. The email sent on 18/06/2022.