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.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

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

Buffer Overflow vulnerability in clj_media_size function in devices/gdevclj.c in Artifex Ghostscript 9.50 allows remote attackers to cause a denial of service or other unspecified impact(s) via opening of crafted PDF document.

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

Please press **Back** and try again.

CVE-2020-21890: Invalid Bug ID

Heap-based Buffer Overflow in function bfd_getl32 in Binutils objdump 3.37.

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

Please press **Back** and try again.

CVE-2021-46174: Invalid Bug ID

Buffer Overflow vulnerability in _nc_find_entry in tinfo/comp_hash.c:70 in ncurses 6.1 allows remote attackers to cause a denial of service via crafted command.

*   *   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-2020-19190: fuzzpoc/infotocap_poc6.md at master · zjuchenyuan/fuzzpoc

Buffer Overflow vulnerability in fmt_entry function in progs/dump_entry.c:1116 in ncurses 6.1 allows remote attackers to cause a denial of service via crafted command.

CVE-2020-19188: fuzzpoc/infotocap_poc4.md at master · zjuchenyuan/fuzzpoc

Buffer Overflow vulnerability in postprocess_terminfo function in tinfo/parse_entry.c:997 in ncurses 6.1 allows remote attackers to cause a denial of service via crafted command.

CVE-2020-19189: fuzzpoc/infotocap_poc5.md at master · zjuchenyuan/fuzzpoc

Buffer Overflow vulnerability in function ID3_Support::ID3v2Frame::getFrameValue in exempi 2.5.0 and earlier allows remote attackers to cause a denial of service via opening of crafted audio file with ID3V2 frame.

poc

**0x00 Introduction**

In exempi 2.5.0, I found a heap-based buffer over-read bug in function ID3\_Support::ID3v2Frame::getFrameValue, the ASAN report is as below.

    liwc@ubuntu:~/exempi-master_asan/exempi$ ./exempi -x poc
    processing file poc
    dump_xmp for file poc
    =================================================================
    ==79549==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000eed1 at pc 0x0000004be2ae bp 0x7fffc062ec30 sp 0x7fffc062ec20
    READ of size 4 at 0x60200000eed1 thread T0
        #0 0x4be2ad in GetUns32BE ../../../source/EndianUtils.hpp:152
        #1 0x4c2256 in ID3_Support::ID3v2Frame::getFrameValue(unsigned char, unsigned int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) /home/liwc/exempi-master/XMPFiles/source/FormatSupport/ID3_Support.cpp:702
        #2 0x4de2a0 in MP3_MetaHandler::ProcessXMP() /home/liwc/exempi-master/XMPFiles/source/FileHandlers/MP3_Handler.cpp:334
        #3 0x48aafd in XMPFiles::GetXMP(TXMPMeta<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >*, char const**, unsigned int*, XMP_PacketInfo*) /home/liwc/exempi-master/XMPFiles/source/XMPFiles.cpp:1471
        #4 0x47fac8 in WXMPFiles_GetXMP_1 /home/liwc/exempi-master/XMPFiles/source/WXMPFiles.cpp:331
        #5 0x41e353 in TXMPFiles<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::GetXMP(TXMPMeta<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, XMP_PacketInfo*) (/home/liwc/exempi-master_asan/exempi/exempi+0x41e353)
        #6 0x40c0f1 in xmp_files_get_new_xmp /home/liwc/exempi-master/exempi/exempi.cpp:346
        #7 0x408d07 in get_xmp_from_file /home/liwc/exempi-master/exempi/main.cpp:244
        #8 0x408ece in dump_xmp /home/liwc/exempi-master/exempi/main.cpp:257
        #9 0x409b54 in process_file /home/liwc/exempi-master/exempi/main.cpp:348
        #10 0x408728 in main /home/liwc/exempi-master/exempi/main.cpp:194
        #11 0x7f7b7b20482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
        #12 0x407a58 in _start (/home/liwc/exempi-master_asan/exempi/exempi+0x407a58)
    
    0x60200000eed3 is located 0 bytes to the right of 3-byte region [0x60200000eed0,0x60200000eed3)
    allocated by thread T0 here:
        #0 0x7f7b7c53b712 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x99712)
        #1 0x4c10c6 in ID3_Support::ID3v2Frame::read(XMP_IO*, unsigned char) /home/liwc/exempi-master/XMPFiles/source/FormatSupport/ID3_Support.cpp:579
        #2 0x4dd4ae in MP3_MetaHandler::CacheFileData() /home/liwc/exempi-master/XMPFiles/source/FileHandlers/MP3_Handler.cpp:220
        #3 0x48874f in DoOpenFile /home/liwc/exempi-master/XMPFiles/source/XMPFiles.cpp:1076
        #4 0x488f8a in XMPFiles::OpenFile(char const*, unsigned int, unsigned int) /home/liwc/exempi-master/XMPFiles/source/XMPFiles.cpp:1179
        #5 0x47e415 in WXMPFiles_OpenFile_1 /home/liwc/exempi-master/XMPFiles/source/WXMPFiles.cpp:233
        #6 0x41dab4 in TXMPFiles<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::OpenFile(char const*, unsigned int, unsigned int) (/home/liwc/exempi-master_asan/exempi/exempi+0x41dab4)
        #7 0x40bd79 in xmp_files_open_new /home/liwc/exempi-master/exempi/exempi.cpp:294
        #8 0x408ccb in get_xmp_from_file /home/liwc/exempi-master/exempi/main.cpp:242
        #9 0x408ece in dump_xmp /home/liwc/exempi-master/exempi/main.cpp:257
        #10 0x409b54 in process_file /home/liwc/exempi-master/exempi/main.cpp:348
        #11 0x408728 in main /home/liwc/exempi-master/exempi/main.cpp:194
        #12 0x7f7b7b20482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow ../../../source/EndianUtils.hpp:152 GetUns32BE
    Shadow bytes around the buggy address:
      0x0c047fff9d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff9d90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff9db0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 00
      0x0c047fff9dc0: fa fa fd fd fa fa fd fa fa fa fd fa fa fa 00 00
    =>0x0c047fff9dd0: fa fa 01 fa fa fa 04 fa fa fa[03]fa fa fa 03 fa
      0x0c047fff9de0: fa fa 00 04 fa fa 05 fa fa fa 00 04 fa fa fd fd
      0x0c047fff9df0: fa fa 00 05 fa fa fd fa fa fa 05 fa fa fa 00 00
      0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff9e20: 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
      Heap right redzone:      fb
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack partial redzone:   f4
      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
    ==79549==ABORTING

**0x01 Analysis**

I debugged the poc with gdb so that I found the key of this issue.

    bool ID3v2Frame::getFrameValue ( XMP_Uns8 /*majorVersion*/, XMP_Uns32 logicalID, std::string* utf8string )
    {
    
    	XMP_Assert ( (this->content != 0) && (this->contentSize >= 0) && (this->contentSize < 20*1024*1024) );
    
    	if ( this->contentSize == 0 ) {
    		utf8string->erase();
    		return true; // ...it is "of interest", even if empty contents.
    	}
    
    	XMP_Int32 pos = 0;
    	XMP_Uns8 encByte = 0;
    	// WCOP does not have an encoding byte, for all others: use [0] as EncByte, advance pos
    	if ( logicalID != 0x57434F50 ) { // pos1
    		encByte = this->content[0];
    		pos++;
    	}
    
    	// mode specific forks, COMM or USLT
    	bool commMode = ( (logicalID == 0x434F4D4D) || (logicalID == 0x55534C54) );
    
    	switch ( encByte ) { // pos2
    
    		case 0: //ISO-8859-1, 0-terminated
    		{
    			if ( commMode && (! advancePastCOMMDescriptor ( pos )) ) return false; // not a frame of interest!
    
    			char* localPtr  = &this->content[pos];
    			size_t localLen = this->contentSize - pos;
    			ReconcileUtils::Latin1ToUTF8 ( localPtr, localLen, utf8string );
    			break;
    
    		}
    
    		case 1: // Unicode, v2.4: UTF-16 (undetermined Endianess), with BOM, terminated 0x00 00
    		case 2: // UTF-16BE without BOM, terminated 0x00 00
    		{
    			...
    		}
    
    		case 3: // UTF-8 unicode, terminated \0
    		{
    			if ( commMode && (! advancePastCOMMDescriptor ( pos )) ) return false; // not a frame of interest!
    		
    			if ( (GetUns32BE ( &this->content[pos]) & 0xFFFFFF00 ) == 0xEFBBBF00 ) { // pos3
    				pos += 3;	// swallow any BOM, just in case
    			}
    
    			utf8string->assign ( &this->content[pos], (this->contentSize - pos) );
    			break;
    		}
    
    		default:
    			XMP_Throw ( "unknown text encoding", kXMPErr_BadFileFormat ); //COULDDO assume latin-1 or utf-8 as best-effort
    			break;
    
    	}
    
    	return true;
    
    }	// ID3v2Frame::getFrameValue

At pos1, the logicalID did not equal 0x57434f50，so the if branch was satisfied and pos would incremented. Now the encByte was 0x3, the case 3 of switch statement at pos2 was satisfied. We noticed the size of heap buffer this->content was only 3 bytes and it started from 0x60200000eed0.

     →  655	 	if ( logicalID != 0x57434F50 ) {
        656	 		encByte = this->content[0];
        657	 		pos++;
        658	 	}
        659	 
        660	 	// mode specific forks, COMM or USLT
    ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────
    [#0] Id 1, Name: "exempi", stopped, reason: SINGLE STEP
    ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── trace ────
    ...
    ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
    gef➤  p logicalID 
    $1 = 0x54504f53
    gef➤  p this->content
    $2 = 0x60200000eed0 "\003\062\061"
    

Then it called the inline function GetUns32BE in EndianUtils.hpp:150 at pos3, and GetUns32BE read 4 bytes from the given addr. At this call site the given addr was 0x60200000eed1, so a 2-bytes heap-based buffer over-read happened.

We can patch this issue by check the length of this->content firstly.

**0x02 Reproduce**

    OS:Ubuntu 16.04 x86_64
    export CFLAGS="-fsanitize=address -ggdb"
    export CXXFLAGS="-fsanitize=address -ggdb"
    export LDFLAGS="-fsanitize=address -ggdb"
    sudo apt install libboost-dev
    sudo apt install libboost-test-dev
    ./autogen.sh
    ./configure --disable-shared
    make
    
    ./exampi/exempi -x POC -o out

**0x03 Discoverer**

WenChao Li of VARAS@IIE

CVE-2020-18651: A heap-based buffer over-read was found in ID3_Support.cpp (#13) · Issues · libopenraw / exempi · GitLab

Buffer Overflow vulnerability in function H5S_close in H5S.c in HDF5 1.10.4 allows remote attackers to run arbitrary code via creation of crafted file.

Tag

#buffer_overflow