Libsixel prior to v1.8.3 contains a stack buffer overflow in the function gif_process_raster at fromgif.c.

Our fuzzer detected several crashes when converting gif file against 2df6437 (compiled with Address Sanitizer). The command to trigger that is img2sixel $POC -o /tmp/test.six where $POC can be:  
https://github.com/ntu-sec/pocs/blob/master/libsixel-2df6437/crashes/so\_fromgif.c%3A310\_1.gif  
https://github.com/ntu-sec/pocs/blob/master/libsixel-2df6437/crashes/so\_fromgif.c%3A310\_2.gif

gdb output is like:

    GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
    Copyright (C) 2018 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "x86_64-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.
    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from /home/hongxu/FOT/libsixel/install/bin/img2sixel...done.
    Starting program: /home/hongxu/FOT/libsixel/install/bin/img2sixel hbo_fromgif.c:310_1.gif -o /tmp/test.six
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    =================================================================
    ==17533==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffa7d8 at pc 0x7ffff7b5f160 bp 0x7fffffff5950 sp 0x7fffffff5948
    WRITE of size 2 at 0x7fffffffa7d8 thread T0
        #0 0x7ffff7b5f15f in gif_process_raster /home/hongxu/FOT/libsixel/src/fromgif.c:310:31
        #1 0x7ffff7b5c303 in gif_load_next /home/hongxu/FOT/libsixel/src/fromgif.c:462:22
        #2 0x7ffff7b5a25e in load_gif /home/hongxu/FOT/libsixel/src/fromgif.c:599:22
        #3 0x7ffff7b11198 in load_with_builtin /home/hongxu/FOT/libsixel/src/loader.c:858:18
        #4 0x7ffff7b10116 in sixel_helper_load_image_file /home/hongxu/FOT/libsixel/src/loader.c:1352:18
        #5 0x7ffff7b69d98 in sixel_encoder_encode /home/hongxu/FOT/libsixel/src/encoder.c:1737:14
        #6 0x515787 in main /home/hongxu/FOT/libsixel/converters/img2sixel.c:457:22
        #7 0x7ffff61a6b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
        #8 0x41a239 in _start (/home/hongxu/FOT/libsixel/install/bin/img2sixel+0x41a239)
    
    Address 0x7fffffffa7d8 is located in stack of thread T0 at offset 18296 in frame
        #0 0x7ffff7b5999f in load_gif /home/hongxu/FOT/libsixel/src/fromgif.c:555
    
      This frame has 4 object(s):
        [32, 208) 's' (line 556)
        [272, 18296) 'g' (line 557) <== Memory access at offset 18296 overflows this variable
        [18560, 18568) 'frame' (line 559)
        [18592, 18600) 'fnp' (line 560)
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow /home/hongxu/FOT/libsixel/src/fromgif.c:310:31 in gif_process_raster
    Shadow bytes around the buggy address:
      0x10007fff74a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff74b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff74c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff74d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff74e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x10007fff74f0: 00 00 00 00 00 00 00 00 00 00 00[f2]f2 f2 f2 f2
      0x10007fff7500: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
      0x10007fff7510: f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2
      0x10007fff7520: 00 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff7530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10007fff7540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      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
    ==17533==ABORTING
    
    Program received signal SIGABRT, Aborted.
    __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
    51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    #0  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
    #1  0x00007ffff61c5801 in __GI_abort () at abort.c:79
    #2  0x000000000050376b in __sanitizer::Abort() ()
    #3  0x0000000000500a98 in __sanitizer::Die() ()
    #4  0x00000000004e2d1d in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) ()
    #5  0x00000000004e374b in __asan_report_store2 ()
    #6  0x00007ffff7b5f160 in gif_process_raster (s=0x7fffffff6080, g=0x7fffffff6170) at fromgif.c:310
    #7  0x00007ffff7b5c304 in gif_load_next (s=0x7fffffff6080, g=0x7fffffff6170, bgcolor=0x0) at fromgif.c:462
    #8  0x00007ffff7b5a25f in load_gif (buffer=0x62d000000400 "GIF89a\f", size=0xca, bgcolor=0x0, reqcolors=0x100, fuse_palette=0x1, fstatic=0x0, loop_control=0x0, fn_load=0x7ffff7b6a090 <load_image_callback>, context=0x610000000040, allocator=0x604000000190) at fromgif.c:599
    #9  0x00007ffff7b11199 in load_with_builtin (pchunk=0x603000000e20, fstatic=0x0, fuse_palette=0x1, reqcolors=0x100, bgcolor=0x0, loop_control=0x0, fn_load=0x7ffff7b6a090 <load_image_callback>, context=0x610000000040) at loader.c:858
    #10 0x00007ffff7b10117 in sixel_helper_load_image_file (filename=0x7fffffffc9ed "hbo_fromgif.c:310_1.gif", fstatic=0x0, fuse_palette=0x1, reqcolors=0x100, bgcolor=0x0, loop_control=0x0, fn_load=0x7ffff7b6a090 <load_image_callback>, finsecure=0x0, cancel_flag=0x13b61c0 <signaled>, context=0x610000000040, allocator=0x604000000190) at loader.c:1352
    #11 0x00007ffff7b69d99 in sixel_encoder_encode (encoder=0x610000000040, filename=0x7fffffffc9ed "hbo_fromgif.c:310_1.gif") at encoder.c:1737
    #12 0x0000000000515788 in main (argc=0x4, argv=0x7fffffffc488) at img2sixel.c:457

CVE-2020-21050: AddressSanitizer: stack-buffer-overflow at fromgif.c:310 · Issue #75 · saitoha/libsixel

Multiple camera devices by UDP Technology, GeutebrÃ¼ck and other vendors allow unauthenticated remote access to sensitive files due to default user authentication settings. This can lead to manipulation of the device and denial of service.

CVE-2021-33543: UDP Technology IP Camera vulnerabilities

A code execution vulnerability exists in the DL_Dxf::handleLWPolylineData functionality of Ribbonsoft dxflib 3.17.0. A specially-crafted .dxf file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

A code execution vulnerability exists in the DL\_Dxf::handleLWPolylineData functionality of Ribbonsoft dxflib 3.17.0. A specially-crafted .dxf file can lead to a heap buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

Ribbonsoft dxflib 3.17.0

**Product URLs**

https://www.qcad.org/en/90-dxflib

**CVSSv3 Score**

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

**CWE**

CWE-191 - Integer Underflow (Wrap or Wraparound)

**Details**

dxflib is a C++ library utilized by QCAD, kicad, and other CAD software to parse DXF files for reading and writing. The DXF file fomat was originally created in 1982 by AutoCAD, and fills the same roll as the newer .dwg file format, mainly describing objects to be drawn.

The .dxf file fomat itself is rather simple, consisting solely of groupCode, groupValue pairs, separated by a newline. For example:

    0        // groupCode:  0 => new entity
    SECTION  // groupValue: 'SECTION' => type of the new entity
    2        // groupCode
    HEADER   // groupValue
    9        // groupCode
    $ACADVER // groupValue
    

Each groupCode acts like an opcode, and the groupValue is put to an opcode-specific purpose. The backtrace of the codeflow handling this looks like:

    #0  DL_Dxf::processDXFGroup (this=?, creationInterface=?, groupCode=?, groupValue=...) at dl_dxf.cpp:366                         //[1]
    #1  0x00007fb91bf89814 in DL_Dxf::readDxfGroups (this=0x61c000000080, fp=0x615000000580, creationInterface=?) at dl_dxf.cpp:187  //[2]
    #2  0x00007fb91bf8955e in DL_Dxf::in (this=0x61c000000080, file=..., creationInterface=?) at dl_dxf.cpp:118                      //[3]
    

Whereby DL_Dxf::in\[3\] reads a file and loops DL_Dxf::readDxfGroups\[2\] until it fails. DL_Dxf::readDxfGroups just loops and converts the next two lines of the file (i.e. the next groupCode and groupValue) into digits and then passes them to DL_Dxf::processDXFGroup, which does the groupCode/groupValue specific processing. A quick example of what this looks like:

    bool DL_Dxf::processDXFGroup(DL_CreationInterface* creationInterface,
                                 int groupCode, const std::string& groupValue) {
    
    // [...]
    
    // Indicates comment or dxflib version:
    if (groupCode==999) {
        if (!groupValue.empty()) {
            if (groupValue.substr(0, 6)=="dxflib") {
                libVersion = getLibVersion(groupValue.substr(7));
            }
    
            addComment(creationInterface, groupValue);  // [1]
        }
    }
    

While most of this code is self-explanatory, the line at \[1\] is not. The addComment function calls a function defined by the creationInterface, an object that is defined by whatever program is importing dxflib. This point is made only to say that any function starting with add* is defined by the program importing dxflib, not by dxflib itself. As such, we ignore all these functions. Everything else that gets processed by dxflib can be found below (all the handle* functions):

       // Group code does not indicate start of new entity or setting,
        // so this group must be continuation of data for the current
        // one.
        if (groupCode<DL_DXF_MAXGROUPCODE) {
    
            bool handled = false;
    
            switch (currentObjectType) {
            case DL_ENTITY_MTEXT:
                handled = handleMTextData(creationInterface);
                break;
    
            case DL_ENTITY_LWPOLYLINE:
                handled = handleLWPolylineData(creationInterface); // [1]
                break;
    
            case DL_ENTITY_SPLINE:
                handled = handleSplineData(creationInterface);
                break;
    
            case DL_ENTITY_LEADER:
                handled = handleLeaderData(creationInterface);
                break;
    
            case DL_ENTITY_HATCH:
                handled = handleHatchData(creationInterface);
                break;
    
            case DL_XRECORD:
                handled = handleXRecordData(creationInterface);
                break;
    
            case DL_DICTIONARY:
                handled = handleDictionaryData(creationInterface);
                break;
    
            case DL_LINETYPE:
                handled = handleLinetypeData(creationInterface);
                break;
    
            default:
                break;
            }
    
            // Always try to handle XData, unless we're in an XData record:
            if (currentObjectType!=DL_XRECORD) {
                handled = handleXData(creationInterface);
            }
    
            if (!handled) {
                // Normal group / value pair:
                values[groupCode] = groupValue;
            }
    

For this writeup we deal with the handleLWPolylineData function at \[1\], which handles structures constising of four vertices represented by doubles. To proceed, the function and then an example LWPOLYLINE:

    bool DL_Dxf::handleLWPolylineData(DL_CreationInterface* /*creationInterface*/) {
    // Allocate LWPolyline vertices (group code 90): // [1]
    if (groupCode==90) {   
        maxVertices = toInt(groupValue);
        if (maxVertices>0) {
            if (vertices!=NULL) {
                delete[] vertices;
            }
            vertices = new double[4*maxVertices]; // [2]
            for (int i=0; i<maxVertices; ++i) {
                vertices[i*4] = 0.0;
                vertices[i*4+1] = 0.0;
                vertices[i*4+2] = 0.0;
                vertices[i*4+3] = 0.0;
            }
        }
          
        vertexIndex=-1;
        return true;
    
    }
    
    // Process LWPolylines vertices (group codes 10/20/30/42):
    else if (groupCode==10 || groupCode==20 ||
             groupCode==30 || groupCode==42) {
    
        if (vertexIndex<maxVertices-1 && groupCode==10) {
            vertexIndex++;
        }
    
        if (groupCode<=30) {
            if (vertexIndex>=0 && vertexIndex<maxVertices) {
                vertices[4*vertexIndex + (groupCode/10-1)] = toReal(groupValue); // write one of the first 3 vertex 
            }
        } else if (groupCode==42 && vertexIndex<maxVertices) { // vertexIndex is signed, can be -1...
            vertices[4*vertexIndex + 3] = toReal(groupValue);  // oob write here, fully controlled value
        }
        return true;
    }
    return false; }
    

Once we see an opcode of 90 \[1\], we allocate a buffer times the next value. Once this buffer has been allocated, we can process further, writing into the buffer with opcodes 10, 20, 30, and 42, each different opcode changing which index to write to. Thus, in the below example, we’d write 1, 2, 3, and 1094795585 to the second set of vertices in the buffer:

    0
    LWPOLYLINE
     90
    4
     10
    1
     20
    2
     30
    3
     42
    1094795585
    

Something worth noting: when we allocate a buffer via opcode 90, our vertexIndex is assigned -1, and if we omit the groupCode of 10 from our LWPOLYLINE object, we will skip the following section of code:

        if (vertexIndex<maxVertices-1 && groupCode==10) {
            vertexIndex++;
        }
    

Thus, with a LWPOLYLINE looking something like:

    0 
    LWPOLYLINE
     90
    4  
     42
    1094795585
    

We allocate a buffer (4 \* 4 \* sizeof(double)), but then immediately hit the opcode 42 branch:

        } else if (groupCode==42 && vertexIndex<maxVertices) { // [1]
            vertices[4*vertexIndex + 3] = toReal(groupValue);    // [2]
        }
    

Since both vertexIndex and maxVertices are signed integers, the check becomes -1 < (value_we_control), which will always pass for any positive value we give for maxVertices in opcode 90. Thus, when we get to \[2\], we end up writing a value we control to vertices[(4*-1)+3], which results in an OOB heap write to the first eight bytes before the heap chunk’s data. Depending on the heap implimentation, overwriting this space can very quickly lead to code execution.

**Crash Information**

    ==215422==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6210000050f8 at pc 0x7ffff7d51476 bp 0x7fffffffd150 sp 0x7fffffffd148                                                                                                                   [143/343]
    WRITE of size 8 at 0x6210000050f8 thread T0      
    [Detaching after fork from child process 215427]                 
        #0 0x7ffff7d51475 in DL_Dxf::handleLWPolylineData(DL_CreationInterface*) /root/boop/assorted_fuzzing/kicad/dxflib/dxflib-3.17.0-src/src/dl_dxf.cpp:1455:41
        #1 0x7ffff7d4235e in DL_Dxf::processDXFGroup(DL_CreationInterface*, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /root/boop/assorted_fuzzing/kicad/dxflib/dxflib-3.17.0-src/src/dl_dxf.cpp:708:27
        #2 0x7ffff7d41813 in DL_Dxf::readDxfGroups(_IO_FILE*, DL_CreationInterface*) /root/boop/assorted_fuzzing/kicad/dxflib/dxflib-3.17.0-src/src/dl_dxf.cpp:187:9
        #3 0x7ffff7d4155d in DL_Dxf::in(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, DL_CreationInterface*) /root/boop/assorted_fuzzing/kicad/dxflib/dxflib-3.17.0-src/src/dl_dxf.cpp:118:16
        #4 0x554ec7 in LLVMFuzzerTestOneInput (/root/boop/assorted_fuzzing/kicad/dxflib/dxf_fuzzer.bin+0x554ec7)
        #5 0x45aa01 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/root/boop/assorted_fuzzing/kicad/dxflib/dxf_fuzzer.bin+0x45aa01)
        #6 0x446172 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/root/boop/assorted_fuzzing/kicad/dxflib/dxf_fuzzer.bin+0x446172)
        #7 0x44bc26 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/root/boop/assorted_fuzzing/kicad/dxflib/dxf_fuzzer.bin+0x44bc26)
        #8 0x4748e2 in main (/root/boop/assorted_fuzzing/kicad/dxflib/dxf_fuzzer.bin+0x4748e2)
        #9 0x7ffff79a40b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #10 0x42083d in _start (/root/boop/assorted_fuzzing/kicad/dxflib/dxf_fuzzer.bin+0x42083d)
    
    0x6210000050f8 is located 8 bytes to the left of 4736-byte region [0x621000005100,0x621000006380)
    allocated by thread T0 here:                                                                                                       
        #0 0x54fdcd in operator new[](unsigned long) (/root/boop/assorted_fuzzing/kicad/dxflib/dxf_fuzzer.bin+0x54fdcd)
        #1 0x7ffff7d510cc in DL_Dxf::handleLWPolylineData(DL_CreationInterface*) /root/boop/assorted_fuzzing/kicad/dxflib/dxflib-3.17.0-src/src/dl_dxf.cpp:1430:24
        #2 0x7ffff7d4235e in DL_Dxf::processDXFGroup(DL_CreationInterface*, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /root/boop/assorted_fuzzing/kicad/dxflib/dxflib-3.17.0-src/src/dl_dxf.cpp:708:27
        #3 0x7ffff7d41813 in DL_Dxf::readDxfGroups(_IO_FILE*, DL_CreationInterface*) /root/boop/assorted_fuzzing/kicad/dxflib/dxflib-3.17.0-src/src/dl_dxf.cpp:187:9
        #4 0x7ffff7d4155d in DL_Dxf::in(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, DL_CreationInterface*) /root/boop/assorted_fuzzing/kicad/dxflib/dxflib-3.17.0-src/src/dl_dxf.cpp:118:16
        #5 0x554ec7 in LLVMFuzzerTestOneInput (/root/boop/assorted_fuzzing/kicad/dxflib/dxf_fuzzer.bin+0x554ec7)
        #6 0x45aa01 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/root/boop/assorted_fuzzing/kicad/dxflib/dxf_fuzzer.bin+0x45aa01)
        #7 0x446172 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/root/boop/assorted_fuzzing/kicad/dxflib/dxf_fuzzer.bin+0x446172)
        #8 0x44bc26 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/root/boop/assorted_fuzzing/kicad/dxflib/dxf_fuzzer.bin+0x44bc26)
        #9 0x4748e2 in main (/root/boop/assorted_fuzzing/kicad/dxflib/dxf_fuzzer.bin+0x4748e2)
        #10 0x7ffff79a40b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /root/boop/assorted_fuzzing/kicad/dxflib/dxflib-3.17.0-src/src/dl_dxf.cpp:1455:41 in DL_Dxf::handleLWPolylineData(DL_CreationInterface*)
    Shadow bytes around the buggy address:
      0x0c427fff89c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 
      0x0c427fff89d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 
      0x0c427fff89e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 
      0x0c427fff89f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 
      0x0c427fff8a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 
    =>0x0c427fff8a10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]
      0x0c427fff8a20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
      0x0c427fff8a30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
      0x0c427fff8a40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
      0x0c427fff8a50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
      0x0c427fff8a60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==215422==ABORTING
    [Thread 0x7ffff3179700 (LWP 215426) exited]
    [Inferior 1 (process 215422) exited with code 01]
    

**Timeline**

2021-08-04 - Vendor Disclosure  
2021-08-21 - Follow up with vendor  
2021-08-27 - Vendor patched

2021-09-07 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2021-21897: TALOS-2021-1346 || Cisco Talos Intelligence Group

A parsing issue in the handling of directory paths was addressed with improved path validation. This issue is fixed in macOS Big Sur 11.3, iOS 14.5 and iPadOS 14.5, watchOS 7.4, tvOS 14.5. A local user may be able to modify protected parts of the file system.

CVE-2021-1815: About the security content of iOS 14.5 and iPadOS 14.5

NTFS-3G versions < 2021.8.22, a stack buffer overflow can occur when correcting differences in the MFT and MFTMirror allowing for code execution or escalation of privileges when setuid-root.

**The world counts on us for data and storage management**

Our storage management and networking software powers billions of devices, cars, and public cloud platforms around the world, bringing people closer to all the data they store, use, and share. Tuxera’s customers include car makers, device manufacturers, industrial equipment manufacturers, data-driven enterprises, and many more. We help them solve complex challenges involving data in all its states – at rest, in use, and in motion. They rely on our software to protect data integrity, ensure data accessibility, improve storage performance, transfer data rapidly and security, and extend flash memory lifetime.

More about us

**Chosen and backed by the industry's best**

**The Tuxera difference**

Our passion is protecting data integrity and longevity, while ensuring seamless data transfer all the way from the edge to the cloud. Tuxera’s software is renowned for improving user experience by boosting throughput, cutting file seek time, reducing boot time, and preventing data corruption. But what we’re really known for around the industry is our dedication to developing quality-assured software, our responsive technical support, and unparalleled development expertise in storage and data management.

**How we've been recognized**

**What we are talking about**

Welcome! We use cookies to improve the quality of our content, analyze site performance, and provide the best possible experience for you. By clicking “Accept all”, you consent to the use of ALL the cookies we use. For more details, check out our Privacy Policy and Terms of Use.

CVE-2021-35267: Reliable file systems & data storage management software - Tuxera

A crafted NTFS image can trigger a heap-based buffer overflow, caused by an unsanitized attribute in ntfs_get_attribute_value, in NTFS-3G < 2021.8.22.

Security vulnerabilities were identified in the open source NTFS-3G and NTFSPROGS software. These vulnerabilities were confirmed and resolved. To our knowledge, these vulnerabilities have not been exploited.

These vulnerabilities may allow an attacker using a maliciously crafted NTFS-formatted image file or external storage to potentially execute arbitrary privileged code, if the attacker has either local access and the ntfs-3g binary is setuid root, or if the attacker has physical access to an external port to a computer which is configured to run the ntfs-3g binary or one of the ntfsprogs tools when the external storage is plugged into the computer. These vulnerabilities result from incorrect validation of some of the NTFS metadata that could potentially cause buffer overflows, which could be exploited by an attacker. Common ways for attackers to gain physical access to a machine is through social engineering or an evil maid attack on an unattended computer.

We recommend installing and applying the update with the security fixes, and advise to follow security guidance and frameworks such as NIST for assessing and improving an organization’s abilities to prevent, detect, and respond to security threats and cyber attacks.

AFFECTED PRODUCTS: All previous versions of open source NTFS-3G and NTFSPROGS.

WORKAROUND: None

SOLUTION: Upgrade to 2021.8.22

PROJECT URL: https://github.com/tuxera/ntfs-3g

ADVISORY ID: NTFS3G-SA-2021-0001

ISSUE DATE: 2021-08-30

SEVERITY: Moderate

CVEs: CVE-2021-33285, CVE-2021-35269, CVE-2021-35268, CVE-2021-33289, CVE-2021-33286, CVE-2021-35266, CVE-2021-33287, CVE-2021-35267, CVE-2021-39251, CVE-2021-39252, CVE-2021-39253, CVE-2021-39254, CVE-2021-39255, CVE-2021-39256, CVE-2021-39257, CVE-2021-39258, CVE-2021-39259, CVE-2021-39260, CVE-2021-39261, CVE-2021-39262, CVE-2021-39263

CVSS SCORE: 3.9-6.7

ACKNOWLEDGMENT: Jeremy Galindo, Akshay Ajayan, Kyle Zeng and Fish Wang for reporting these vulnerabilities.

CVE-2021-39263: OPEN SOURCE NTFS-3G SECURITY ADVISORY NTFS3G-SA-2021-0001

vim is vulnerable to Heap-based Buffer Overflow

@@ -2449,9 +2449,9 @@ didset\_options2(void) #endif #ifdef FEAT\_VARTABS vim\_free(curbuf->b\_p\_vsts\_array); tabstop\_set(curbuf->b\_p\_vsts, &curbuf->b\_p\_vsts\_array); (void)tabstop\_set(curbuf->b\_p\_vsts, &curbuf->b\_p\_vsts\_array); vim\_free(curbuf->b\_p\_vts\_array); tabstop\_set(curbuf->b\_p\_vts, &curbuf->b\_p\_vts\_array); (void)tabstop\_set(curbuf->b\_p\_vts, &curbuf->b\_p\_vts\_array); #endif }  
@@ -5947,7 +5947,7 @@ buf\_copy\_options(buf\_T \*buf, int flags) buf->b\_p\_vsts = vim\_strsave(p\_vsts); COPY\_OPT\_SCTX(buf, BV\_VSTS); if (p\_vsts && p\_vsts != empty\_option) tabstop\_set(p\_vsts, &buf->b\_p\_vsts\_array); (void)tabstop\_set(p\_vsts, &buf->b\_p\_vsts\_array); else buf->b\_p\_vsts\_array = 0; buf->b\_p\_vsts\_nopaste = p\_vsts\_nopaste @@ -6107,7 +6107,7 @@ buf\_copy\_options(buf\_T \*buf, int flags) buf->b\_p\_isk = save\_p\_isk; #ifdef FEAT\_VARTABS if (p\_vts && p\_vts != empty\_option && !buf->b\_p\_vts\_array) tabstop\_set(p\_vts, &buf->b\_p\_vts\_array); (void)tabstop\_set(p\_vts, &buf->b\_p\_vts\_array); else buf->b\_p\_vts\_array = NULL; #endif @@ -6122,7 +6122,7 @@ buf\_copy\_options(buf\_T \*buf, int flags) buf->b\_p\_vts = vim\_strsave(p\_vts); COPY\_OPT\_SCTX(buf, BV\_VTS); if (p\_vts && p\_vts != empty\_option && !buf->b\_p\_vts\_array) tabstop\_set(p\_vts, &buf->b\_p\_vts\_array); (void)tabstop\_set(p\_vts, &buf->b\_p\_vts\_array); else buf->b\_p\_vts\_array = NULL; #endif @@ -6818,7 +6818,7 @@ paste\_option\_changed(void) if (buf->b\_p\_vsts\_array) vim\_free(buf->b\_p\_vsts\_array); if (buf->b\_p\_vsts && buf->b\_p\_vsts != empty\_option) tabstop\_set(buf->b\_p\_vsts, &buf->b\_p\_vsts\_array); (void)tabstop\_set(buf->b\_p\_vsts, &buf->b\_p\_vsts\_array); else buf->b\_p\_vsts\_array = 0; #endif

CVE-2021-3770: patch 8.2.3402: invalid memory access when using :retab with large value · vim/vim@b7081e1

Acrobat Reader DC versions versions 2021.001.20150 (and earlier), 2020.001.30020 (and earlier) and 2017.011.30194 (and earlier) are affected by a memory corruption vulnerability. An unauthenticated attacker could leverage this vulnerability to achieve arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Security update available for Adobe Acrobat and Reader | APSB21-29

**Bulletin ID**

**Date Published**

**Priority**

APSB21-29

May 11, 2021

1

**Summary**

Adobe has released security updates for Adobe Acrobat and Reader for Windows and macOS. These updates address multiple critical and  important vulnerabilities. Successful exploitation could lead to arbitrary code execution in the context of the current user.       

Adobe has received a report that CVE-2021-28550 has been exploited in the wild in limited attacks targeting Adobe Reader users on Windows.

**Affected Versions**

**Product**

**Track**

**Affected Versions**

**Platform**

Acrobat DC 

Continuous 

2021.001.20150 and earlier versions            

Windows

Acrobat Reader DC

Continuous 

2021.001.20150 and earlier versions            

Windows 

Acrobat DC 

Continuous 

2021.001.20149 and earlier 

versions      

macOS

Acrobat Reader DC

Continuous 

2021.001.20149 and earlier 

versions            

macOS

Acrobat 2020  

Classic 2020             

2020.001.30020 and earlier versions  

Windows & macOS  

Acrobat Reader 2020  

Classic 2020             

2020.001.30020 and earlier versions  

Windows & macOS  

Acrobat 2017

Classic 2017

2017.011.30194  and earlier versions            

Windows & macOS  

Acrobat Reader 2017

Classic 2017

2017.011.30194  and earlier versions            

Windows & macOS  

**Solution**

Adobe recommends users update their software installations to the latest versions by following the instructions below.    

The latest product versions are available to end users via one of the following methods:    

*   Users can update their product installations manually by choosing Help > Check for Updates.     
    
*   The products will update automatically, without requiring user intervention, when updates are detected.      
    
*   The full Acrobat Reader installer can be downloaded from the Acrobat Reader Download Center.     
    

For IT administrators (managed environments):     

*   Refer to the specific release note version for links to installers.     
    
*   Install updates via your preferred methodology, such as AIP-GPO, bootstrapper, SCUP/SCCM (Windows), or on macOS, Apple Remote Desktop and SSH.     
    

Adobe categorizes these updates with the following priority ratings and recommends users update their installation to the newest version:    

**Product**

Track

**Updated Versions**

**Platform**

**Priority Rating**

**Availability**

Acrobat DC

Continuous

2021.001.20155       

Windows and macOS

1

Release Notes     

Acrobat Reader DC

Continuous

2021.001.20155    

Windows and macOS

1

Release Notes     

Acrobat 2020  

Classic 2020             

2020.001.30025   

Windows and macOS       

1

Release Notes     

Acrobat Reader 2020  

Classic 2020             

2020.001.30025   

Windows and macOS       

1

Release Notes     

Acrobat 2017

Classic 2017

2017.011.30196    

Windows and macOS

1

Release Notes     

Acrobat Reader 2017

Classic 2017

2017.011.30196    

Windows and macOS

1

Release Notes     

**Vulnerability Details**

**Vulnerability Category**

**Vulnerability Impact**

**Severity**

**CVE Number**

Out-of-bounds Write  

Arbitrary code execution  

Important  

CVE-2021-28561  

Heap-based Buffer Overflow  

Arbitrary code execution  

Critical  

CVE-2021-28560  

Heap-based Buffer Overflow  

Arbitrary code execution  

Important   

CVE-2021-28558  

Out-of-bounds Read  

Memory leak  

Critical  

CVE-2021-28557  

Out-of-bounds Read  

Arbitrary file system read  

Important   

CVE-2021-28555  

Out-of-bounds Read  

Arbitrary code execution  

Critical   

CVE-2021-28565

Out-of-bounds Write  

Arbitrary code execution  

Critical   

CVE-2021-28564  

Out-of-bounds Write  

Arbitrary code execution  

Critical  

CVE-2021-21044

CVE-2021-21038

Exposure of Private Information  

Privilege escalation  

Important   

CVE-2021-28559  

Use After Free  

Arbitrary code execution  

Critical   

CVE-2021-28562

CVE-2021-28550

CVE-2021-28553  

**Acknowledgements**

Adobe would like to thank the following for reporting the relevant issues and for working with Adobe to help protect our customers. 

*   Anonymously reported (CVE-2021-28550)
*   Aleksandar Nikolic of Cisco Talos. (CVE-2021-28562)
*   Xu peng (xupeng\_1231) (CVE-2021-28561)
*   chutchut (CVE-2021-28559)
*   fr0zenrain of Baidu Security (CVE-2021-28560)
*   Haboob Labs (CVE-2021-28557, CVE-2021-28564, CVE-2021-28565, CVE-2021-28553, , CVE-2021-28558, CVE-2021-28555)

CVE-2021-28561: Adobe Security Bulletin

Adobe Bridge version 11.1 (and earlier) is affected by a memory corruption vulnerability due to insecure handling of a malicious Bridge file, potentially resulting in arbitrary code execution in the context of the current user. User interaction is required to exploit this vulnerability.

Security Updates Available for Adobe Bridge | APSB21-69

Bulletin ID

Date Published

Priority

APSB21-69

August 17, 2021   

3

**Summary**

Adobe has released a security update for Adobe Bridge. This update addresses one moderate, one important and multiple  critical vulnerabilities that could lead to arbitrary code execution in the context of the current user.       

**Affected Versions**

**Product**

**Version**

**Platform**

Adobe Bridge    

11.1 and earlier versions   

Windows  

**Solution**

Adobe categorizes these updates with the following priority ratings and recommends users update their installation to the newest version via the Creative Cloud desktop app's update mechanism.  For more information, please reference this help page.   

Product

Version

Platform

Priority     

Availability      

Adobe Bridge    

11.1.1  

Windows and macOS    

3

Download Page    

Adobe Bridge    

10.1.3  

Windows and macOS    

3

Download Page    

**Vulnerability details**

Vulnerability Category

Vulnerability Impact

Severity

**CVSS base score**  

**CVSS vector**

CVE Numbers

Out-of-bounds Write

(CWE-787)  

Arbitrary code execution

Critical   

7.8

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

CVE-2021-36072

Access of Memory Location After End of Buffer

(CWE-788)

Arbitrary code execution 

Critical  

8.8

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

CVE-2021-36078  

Heap-based Buffer Overflow (CWE-122)

Arbitrary code execution     

Critical    

7.8

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

CVE-2021-36073  

Out-of-bounds Read

(CWE-125)

Arbitrary code execution

Critical

7.8

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

CVE-2021-36079  

Out-of-bounds Read

(CWE-125)

Memory leak

Critical   

7.8

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

CVE-2021-36074  

Buffer Overflow (CWE-120)

Arbitrary code execution

Critical   

7.8

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

CVE-2021-36075  

Access of Memory Location After End of Buffer

(CWE-788)

Application denial-of-service

Important

5.5

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

CVE-2021-36077  

Out-of-bounds Read

(CWE-125)

Arbitrary file system read

Moderate  

3.3

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N

CVE-2021-36071  

Access of Memory Location After End of Buffer

(CWE-788)

Arbitrary code execution

Critical   

7.8

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

CVE-2021-36067

CVE-2021-36068

CVE-2021-36069

CVE-2021-36049

CVE-2021-36076

CVE-2021-36059

CVE-2021-39816

CVE-2021-39817

**Acknowledgments**

Adobe would like to thank the following researchers for reporting these issues and for working with Adobe to help protect our customers:  

*   CFF of Topsec Alpha Team (cff\_123) (CVE-2021-36067, CVE-2021-36068, CVE-2021-36069, CVE-2021-36075, CVE-2021-36076, CVE-2021-36059, CVE-2021-39816, CVE-2021-39817)  
*   CQY of Topsec Alpha Team (yjdfy) (CVE-2021-36049, CVE-2021-36077) 
*   Kdot working with Trend Micro Zero Day Initiative (CVE-2021-36072, CVE-2021-36073)
*   Qiao Li Of Baidu Security Lab working with Trend Micro Zero Day Initiative (CVE-2021-36078)
*   Mat Powell of Trend Micro Zero Day Initiative (CVE-2021-36079, CVE-2021-36074, CVE-2021-36071)

For more information, visit https://helpx.adobe.com/security.html , or email PSIRT@adobe.com

CVE-2021-36049: Adobe Security Bulletin

XMP Toolkit version 2020.1 (and earlier) is affected by a memory corruption vulnerability, potentially resulting in arbitrary code execution in the context of the current user. User interaction is required to exploit this vulnerability.

Security Updates Available for Adobe XMP Toolkit SDK | APSB21-65

**Bulletin ID**

**Date Published**

**Priority**

APSB21-65

August 17, 2021

3

**Summary**

Adobe has released updates for XMP-Toolkit-SDK. These updates resolve multiple  critical and important vulnerabilities. Successful exploitation could lead to arbitrary code execution in the context of the current user.                              

**Affected versions**

2020.1 and earlier versions      

**Solution**

Adobe categorizes these updates with the following priority ratings and recommends users update their installation to the newest. 

**Product**

**Updated version**

**Platform**

**Priority rating**

**Availability**

Adobe XMP-Toolkit-SDK   

2021.07    

All 

3

Release Note    

**Vulnerability Details**

**Vulnerability Category**

**Vulnerability Impact**

**Severity**

**CVSS base score**    

**CVSS vector**   

**CVE Number**

Out-of-bounds Read

(CWE-125)

Arbitrary file system read

Critical 

7.1  

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

CVE-2021-36045

Access of Memory Location After End of Buffer

(CWE-788)

Arbitrary code execution

Critical 

7.8  

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

CVE-2021-36046

CVE-2021-36052

Improper Input Validation

(CWE-20)

Arbitrary code execution

Critical 

7.8  

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

CVE-2021-36047

CVE-2021-36048  

Heap-based Buffer Overflow

(CWE-122)

Arbitrary code execution

Critical 

7.8  

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

CVE-2021-36050

CVE-2021-36051  

Stack-based Buffer Overflow

(CWE-121)

Arbitrary code execution

Critical 

7.8

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

CVE-2021-39847

Out-of-bounds Read

(CWE-125)

Application denial-of-service

Important  

5

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L

CVE-2021-36053

Heap-based Buffer Overflow

(CWE-122)

Application denial-of-service

Important  

6.1

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L

CVE-2021-36054

Heap-based Buffer Overflow

(CWE-122)

Application denial-of-service

Important  

6.1

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

CVE-2021-36055

CVE-2021-36056  

Write-what-where Condition

(CWE-123)

Arbitrary code execution

Important  

4.7

CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

CVE-2021-36057

Buffer Underwrite ('Buffer Underflow') (CWE-124)

Arbitrary code execution

Critical 

7.8

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

CVE-2021-36064

Integer Overflow or Wraparound

(CWE-190)

Application denial-of-service

Important  

6.6

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L

CVE-2021-36058  

**Acknowledgments**

Adobe would like to thank the following for reporting the relevant issues and for working with Adobe to help protect our customers: 

*   CFF of Topsec Alpha Team (cff\_123) (CVE-2021-36052, CVE-2021-36064)
*   CQY of Topsec Alpha Team (yjdfy) (CVE-2021-36045, CVE-2021-36046, CVE-2021-36047, CVE-2021-36048, CVE-2021-36050, CVE-2021-36051, CVE-2021-36053, CVE-2021-36054, CVE-2021-36055, CVE-2021-36056, CVE-2021-36057, CVE-2021-36058, CVE-2021-39847)

**Revision**

September 1, 2021:  Updated the CVSS base score and the CVSS vector for CVE-2021-36064, CVE-2021-36052.

                                  Included details about CVE-2021-39847. 

                                  Updated acknowledgement details for yjdfy.    

September 27, 2021: Updated CVSS base score for CVE-2021-36058 & CVE-2021-36054. Updated Vulnerability category for CVE-2021-36056. Updated credit for CVE-2021-36058.

For more information, visit https://helpx.adobe.com/security.html, or email PSIRT@adobe.com.

Tag

#buffer_overflow