libheif v1.17.5 was discovered to contain a segmentation violation via the component /libheif/exif.cc.

**Description**

SEGV libheif/libheif/exif.cc:55 in read16

**Version**

     heif-convert  libheif version: 1.17.5
    -------------------------------------------
    Usage: heif-convert [options]  <input-image> [output-image]
    
    The program determines the output file format from the output filename suffix.
    These suffixes are recognized: jpg, jpeg, png, y4m. If no output filename is specified, 'jpg' is used.
    
    Options:
      -h, --help                     show help
      -v, --version                  show version
      -q, --quality                  quality (for JPEG output)
      -o, --output FILENAME          write output to FILENAME (optional)
      -d, --decoder ID               use a specific decoder (see --list-decoders)
          --with-aux                 also write auxiliary images (e.g. depth images)
          --with-xmp                 write XMP metadata to file (output filename with .xmp suffix)
          --with-exif                write EXIF metadata to file (output filename with .exif suffix)
          --skip-exif-offset         skip EXIF metadata offset bytes
          --no-colons                replace ':' characters in auxiliary image filenames with '_'
          --list-decoders            list all available decoders (built-in and plugins)
          --quiet                    do not output status messages to console
      -C, --chroma-upsampling ALGO   Force chroma upsampling algorithm (nn = nearest-neighbor / bilinear)
          --png-compression-level #  Set to integer between 0 (fastest) and 9 (best). Use -1 for default.
    

**Replay**

    cd libheif
    mkdir build && cd build
    CC="gcc -fsanitize=address" CXX="g++ -fsanitize=address" cmake --preset=release ..
    make -j
    ./examples/heif-convert ./poc test.png
    

**ASAN**

    ==1926429==ERROR: AddressSanitizer: SEGV on unknown address 0x60b080000729 (pc 0x55abe2b1012c bp 0x000000000000 sp 0x7ffe0b2df5a0 T0)
    ==1926429==The signal is caused by a READ memory access.
        #0 0x55abe2b1012c in read16 /eva/put/libheif/libheif/exif.cc:55
        #1 0x55abe2b1012c in find_exif_tag /eva/put/libheif/libheif/exif.cc:103
        #2 0x55abe2b1136b in modify_exif_tag_if_it_exists(unsigned char*, int, unsigned short, unsigned short) /eva/put/libheif/libheif/exif.cc:124
        #3 0x55abe2b1136b in modify_exif_orientation_tag_if_it_exists(unsigned char*, int, unsigned short) /eva/put/libheif/libheif/exif.cc:140
        #4 0x55abe2b16c75 in PngEncoder::Encode(heif_image_handle const*, heif_image const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /eva/put/libheif/examples/encoder_png.cc:126
        #5 0x55abe2b00c99 in main /eva/put/libheif/examples/heif_convert.cc:509
        #6 0x7fb15dc29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #7 0x7fb15dc29e3f in __libc_start_main_impl ../csu/libc-start.c:392
        #8 0x55abe2b09254 in _start (/eva/asan-bin/NestFuzz/libheif/heif-convert+0x15254)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /eva/put/libheif/libheif/exif.cc:55 in read16
    ==1926429==ABORTING
    

**POC**

poc

**Environment**

    Description:	Ubuntu 22.04.2 LTS
    gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
    

**Credit**

Yuchuan Meng (Fudan University)

CVE-2023-49462: SEGV libheif/libheif/exif.cc:55 in read16 · Issue #1043 · strukturag/libheif

libheif v1.17.5 was discovered to contain a segmentation violation via the function UncompressedImageCodec::get_luma_bits_per_pixel_from_configuration_unci.

**Description**

heap-use-after-free/SEGV/heap-buffer-overflow libheif/libheif/uncompressed_image.cc:537 in UncompressedImageCodec::get_luma_bits_per_pixel_from_configuration_unci

**Version**

    commit: 64ece913266609789f5dc70fe7de9eb759badd7f
    
    heif-convert  libheif version: 1.17.5
    -------------------------------------------
    Usage: heif-convert [options]  <input-image> [output-image]
    
    The program determines the output file format from the output filename suffix.
    These suffixes are recognized: jpg, jpeg, png, y4m. If no output filename is specified, 'jpg' is used.
    
    Options:
      -h, --help                     show help
      -v, --version                  show version
      -q, --quality                  quality (for JPEG output)
      -o, --output FILENAME          write output to FILENAME (optional)
      -d, --decoder ID               use a specific decoder (see --list-decoders)
          --with-aux                 also write auxiliary images (e.g. depth images)
          --with-xmp                 write XMP metadata to file (output filename with .xmp suffix)
          --with-exif                write EXIF metadata to file (output filename with .exif suffix)
          --skip-exif-offset         skip EXIF metadata offset bytes
          --no-colons                replace ':' characters in auxiliary image filenames with '_'
          --list-decoders            list all available decoders (built-in and plugins)
          --quiet                    do not output status messages to console
      -C, --chroma-upsampling ALGO   Force chroma upsampling algorithm (nn = nearest-neighbor / bilinear)
          --png-compression-level #  Set to integer between 0 (fastest) and 9 (best). Use -1 for default.
    

**Replay**

    cd libheif
    mkdir build && cd build
    CC="gcc -fsanitize=address" CXX="g++ -fsanitize=address" cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_UNCOMPRESSED_CODEC=ON ..
    make -j
    ./examples/heif-convert ./poc test.png
    

**ASAN**

> I just show the uaf case, you can use my poc to reproduce the others.

    ==88148==ERROR: AddressSanitizer: heap-use-after-free on address 0x60e000000910 at pc 0x7f7a88d9ab47 bp 0x7ffef17996e0 sp 0x7ffef17996d0
    READ of size 2 at 0x60e000000910 thread T0
        #0 0x7f7a88d9ab46 in UncompressedImageCodec::get_luma_bits_per_pixel_from_configuration_unci(HeifFile const&, unsigned int) libheif/libheif/uncompressed_image.cc:537
        #1 0x7f7a88c96f95 in HeifFile::get_luma_bits_per_pixel_from_configuration(unsigned int) const libheif/libheif/file.cc:609
        #2 0x7f7a88c58d54 in HeifContext::Image::get_luma_bits_per_pixel() const libheif/libheif/context.cc:1225
        #3 0x7f7a88c1abf7 in heif_image_handle_get_luma_bits_per_pixel libheif/libheif/heif.cc:846
        #4 0x55fa40c34835 in main libheif/examples/heif_convert.cc:475
        #5 0x7f7a88694082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082)
        #6 0x55fa40c2fadd in _start (libheif/build/examples/heif-convert+0xbadd)
    
    0x60e000000910 is located 16 bytes inside of 160-byte region [0x60e000000900,0x60e0000009a0)
    freed by thread T0 here:
        #0 0x7f7a88f6c0d0 in operator delete(void*) (/lib/x86_64-linux-gnu/libasan.so.4+0xe20d0)
        #1 0x7f7a88c038d9 in __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> >::deallocate(std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2>*, unsigned long) /usr/include/c++/7/ext/new_allocator.h:125
        #2 0x7f7a88bfef61 in std::allocator_traits<std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> > >::deallocate(std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> >&, std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2>*, unsigned long) /usr/include/c++/7/bits/alloc_traits.h:462
        #3 0x7f7a88bf4553 in std::__allocated_ptr<std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> > >::~__allocated_ptr() /usr/include/c++/7/bits/allocated_ptr.h:73
        #4 0x7f7a88c1019d in std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2>::_M_destroy() /usr/include/c++/7/bits/shared_ptr_base.h:543
        #5 0x7f7a88b94163 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() /usr/include/c++/7/bits/shared_ptr_base.h:170
        #6 0x7f7a88b938c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() /usr/include/c++/7/bits/shared_ptr_base.h:684
        #7 0x7f7a88bc23e3 in std::__shared_ptr<Box, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() /usr/include/c++/7/bits/shared_ptr_base.h:1123
        #8 0x7f7a88bc24a3 in std::shared_ptr<Box>::~shared_ptr() /usr/include/c++/7/bits/shared_ptr.h:93
        #9 0x7f7a88be9854 in void std::_Destroy<std::shared_ptr<Box> >(std::shared_ptr<Box>*) /usr/include/c++/7/bits/stl_construct.h:98
        #10 0x7f7a88be4eb8 in void std::_Destroy_aux<false>::__destroy<std::shared_ptr<Box>*>(std::shared_ptr<Box>*, std::shared_ptr<Box>*) /usr/include/c++/7/bits/stl_construct.h:108
        #11 0x7f7a88bdafef in void std::_Destroy<std::shared_ptr<Box>*>(std::shared_ptr<Box>*, std::shared_ptr<Box>*) /usr/include/c++/7/bits/stl_construct.h:137
        #12 0x7f7a88bce3b8 in void std::_Destroy<std::shared_ptr<Box>*, std::shared_ptr<Box> >(std::shared_ptr<Box>*, std::shared_ptr<Box>*, std::allocator<std::shared_ptr<Box> >&) /usr/include/c++/7/bits/stl_construct.h:206
        #13 0x7f7a88bc3acf in std::vector<std::shared_ptr<Box>, std::allocator<std::shared_ptr<Box> > >::~vector() /usr/include/c++/7/bits/stl_vector.h:434
        #14 0x7f7a88bc02f8 in Box::~Box() (libheif/build/libheif/libheif.so.1+0xa22f8)
        #15 0x7f7a88bc053e in FullBox::~FullBox() (libheif/build/libheif/libheif.so.1+0xa253e)
        #16 0x7f7a88c09a8c in Box_meta::~Box_meta() (libheif/build/libheif/libheif.so.1+0xeba8c)
        #17 0x7f7a88c12579 in void __gnu_cxx::new_allocator<Box_meta>::destroy<Box_meta>(Box_meta*) /usr/include/c++/7/ext/new_allocator.h:140
        #18 0x7f7a88c111de in void std::allocator_traits<std::allocator<Box_meta> >::destroy<Box_meta>(std::allocator<Box_meta>&, Box_meta*) /usr/include/c++/7/bits/alloc_traits.h:487
        #19 0x7f7a88c10310 in std::_Sp_counted_ptr_inplace<Box_meta, std::allocator<Box_meta>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() /usr/include/c++/7/bits/shared_ptr_base.h:535
        #20 0x7f7a88b940ec in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() /usr/include/c++/7/bits/shared_ptr_base.h:154
        #21 0x7f7a88b938c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() /usr/include/c++/7/bits/shared_ptr_base.h:684
        #22 0x7f7a88bc23e3 in std::__shared_ptr<Box, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() /usr/include/c++/7/bits/shared_ptr_base.h:1123
        #23 0x7f7a88bc24a3 in std::shared_ptr<Box>::~shared_ptr() /usr/include/c++/7/bits/shared_ptr.h:93
        #24 0x7f7a88b9d8b5 in Box::read(BitstreamRange&, std::shared_ptr<Box>*) libheif/libheif/box.cc:436
        #25 0x7f7a88b9edac in Box::read_children(BitstreamRange&, int) libheif/libheif/box.cc:749
        #26 0x7f7a88bab707 in Box_iprp::parse(BitstreamRange&) libheif/libheif/box.cc:1731
        #27 0x7f7a88b9d7eb in Box::read(BitstreamRange&, std::shared_ptr<Box>*) libheif/libheif/box.cc:672
        #28 0x7f7a88b9edac in Box::read_children(BitstreamRange&, int) libheif/libheif/box.cc:749
        #29 0x7f7a88ba14a0 in Box_meta::parse(BitstreamRange&) libheif/libheif/box.cc:920
    
    previously allocated by thread T0 here:
        #0 0x7f7a88f6b258 in operator new(unsigned long) (/lib/x86_64-linux-gnu/libasan.so.4+0xe1258)
        #1 0x7f7a88c038a8 in __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> >::allocate(unsigned long, void const*) /usr/include/c++/7/ext/new_allocator.h:111
        #2 0x7f7a88bfeeb4 in std::allocator_traits<std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> > >::allocate(std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> >&, unsigned long) /usr/include/c++/7/bits/alloc_traits.h:436
        #3 0x7f7a88bf44b9 in std::__allocated_ptr<std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> > > std::__allocate_guarded<std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> > >(std::allocator<std::_Sp_counted_ptr_inplace<Box_hdlr, std::allocator<Box_hdlr>, (__gnu_cxx::_Lock_policy)2> >&) /usr/include/c++/7/bits/allocated_ptr.h:104
        #4 0x7f7a88bea393 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<Box_hdlr, std::allocator<Box_hdlr>>(std::_Sp_make_shared_tag, Box_hdlr*, std::allocator<Box_hdlr> const&) /usr/include/c++/7/bits/shared_ptr_base.h:635
        #5 0x7f7a88be5955 in std::__shared_ptr<Box_hdlr, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<Box_hdlr>>(std::_Sp_make_shared_tag, std::allocator<Box_hdlr> const&) /usr/include/c++/7/bits/shared_ptr_base.h:1295
        #6 0x7f7a88bdc441 in std::shared_ptr<Box_hdlr>::shared_ptr<std::allocator<Box_hdlr>>(std::_Sp_make_shared_tag, std::allocator<Box_hdlr> const&) /usr/include/c++/7/bits/shared_ptr.h:344
        #7 0x7f7a88bcf8a2 in std::shared_ptr<Box_hdlr> std::allocate_shared<Box_hdlr, std::allocator<Box_hdlr>>(std::allocator<Box_hdlr> const&) /usr/include/c++/7/bits/shared_ptr.h:691
        #8 0x7f7a88bc4768 in std::shared_ptr<Box_hdlr> std::make_shared<Box_hdlr>() /usr/include/c++/7/bits/shared_ptr.h:707
        #9 0x7f7a88b9bcf3 in Box::read(BitstreamRange&, std::shared_ptr<Box>*) libheif/libheif/box.cc:448
        #10 0x7f7a88b9edac in Box::read_children(BitstreamRange&, int) libheif/libheif/box.cc:749
        #11 0x7f7a88ba14a0 in Box_meta::parse(BitstreamRange&) libheif/libheif/box.cc:920
        #12 0x7f7a88b9d7eb in Box::read(BitstreamRange&, std::shared_ptr<Box>*) libheif/libheif/box.cc:672
        #13 0x7f7a88b9edac in Box::read_children(BitstreamRange&, int) libheif/libheif/box.cc:749
        #14 0x7f7a88bab707 in Box_iprp::parse(BitstreamRange&) libheif/libheif/box.cc:1731
        #15 0x7f7a88b9d7eb in Box::read(BitstreamRange&, std::shared_ptr<Box>*) libheif/libheif/box.cc:672
        #16 0x7f7a88b9edac in Box::read_children(BitstreamRange&, int) libheif/libheif/box.cc:749
        #17 0x7f7a88ba14a0 in Box_meta::parse(BitstreamRange&) libheif/libheif/box.cc:920
        #18 0x7f7a88b9d7eb in Box::read(BitstreamRange&, std::shared_ptr<Box>*) libheif/libheif/box.cc:672
        #19 0x7f7a88b9edac in Box::read_children(BitstreamRange&, int) libheif/libheif/box.cc:749
        #20 0x7f7a88ba14a0 in Box_meta::parse(BitstreamRange&) libheif/libheif/box.cc:920
        #21 0x7f7a88b9d7eb in Box::read(BitstreamRange&, std::shared_ptr<Box>*) libheif/libheif/box.cc:672
        #22 0x7f7a88c9217e in HeifFile::parse_heif_file(BitstreamRange&) libheif/libheif/file.cc:254
        #23 0x7f7a88c8ffc6 in HeifFile::read(std::shared_ptr<StreamReader> const&) libheif/libheif/file.cc:107
        #24 0x7f7a88c8f8c6 in HeifFile::read_from_file(char const*) libheif/libheif/file.cc:88
        #25 0x7f7a88c4b3d7 in HeifContext::read_from_file(char const*) libheif/libheif/context.cc:429
        #26 0x7f7a88c163ff in heif_context_read_from_file libheif/libheif/heif.cc:451
        #27 0x55fa40c33e68 in main libheif/examples/heif_convert.cc:410
        #28 0x7f7a88694082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082)
    
    SUMMARY: AddressSanitizer: heap-use-after-free libheif/libheif/uncompressed_image.cc:537 in UncompressedImageCodec::get_luma_bits_per_pixel_from_configuration_unci(HeifFile const&, unsigned int)
    Shadow bytes around the buggy address:
      0x0c1c7fff80d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
      0x0c1c7fff80e0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
      0x0c1c7fff80f0: fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa
      0x0c1c7fff8100: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
      0x0c1c7fff8110: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa
    =>0x0c1c7fff8120: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd
      0x0c1c7fff8130: fd fd fd fd fa fa fa fa fa fa fa fa fd fd fd fd
      0x0c1c7fff8140: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
      0x0c1c7fff8150: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
      0x0c1c7fff8160: fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa
      0x0c1c7fff8170: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
    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
    ==88148==ABORTING
    

**POC**

*   poc-heap-overflow
*   poc-heap-uaf
*   poc-segv

**Environment**

    Description:	Ubuntu 22.04.2 LTS
    gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
    

**Credit**

Yuchuan Meng (Fudan University)

CVE-2023-49464: heap-use-after-free/SEGV/heap-buffer-overflow in UncompressedImageCodec::get_luma_bits_per_pixel_from_configuration_unci · Issue #1044 · strukturag/libheif

libheif v1.17.5 was discovered to contain a segmentation violation via the function find_exif_tag at /libheif/exif.cc.

**Description**

SEGV libheif/libheif/exif.cc:88 in find_exif_tag

**Version**

     heif-convert  libheif version: 1.17.5
    -------------------------------------------
    Usage: heif-convert [options]  <input-image> [output-image]
    
    The program determines the output file format from the output filename suffix.
    These suffixes are recognized: jpg, jpeg, png, y4m. If no output filename is specified, 'jpg' is used.
    
    Options:
      -h, --help                     show help
      -v, --version                  show version
      -q, --quality                  quality (for JPEG output)
      -o, --output FILENAME          write output to FILENAME (optional)
      -d, --decoder ID               use a specific decoder (see --list-decoders)
          --with-aux                 also write auxiliary images (e.g. depth images)
          --with-xmp                 write XMP metadata to file (output filename with .xmp suffix)
          --with-exif                write EXIF metadata to file (output filename with .exif suffix)
          --skip-exif-offset         skip EXIF metadata offset bytes
          --no-colons                replace ':' characters in auxiliary image filenames with '_'
          --list-decoders            list all available decoders (built-in and plugins)
          --quiet                    do not output status messages to console
      -C, --chroma-upsampling ALGO   Force chroma upsampling algorithm (nn = nearest-neighbor / bilinear)
          --png-compression-level #  Set to integer between 0 (fastest) and 9 (best). Use -1 for default.
    

**Replay**

    cd libheif
    mkdir build && cd build
    CC="gcc -fsanitize=address" CXX="g++ -fsanitize=address" cmake --preset=release ..
    make -j
    ./examples/heif-convert ./poc test.png
    

**ASAN**

    =================================================================
    ==216883==ERROR: AddressSanitizer: SEGV on unknown address 0x60b0b184d2bc (pc 0x55f4628c3ca8 bp 0x00004e7b34c8 sp 0x7ffe414d49b0 T0)
    ==216883==The signal is caused by a READ memory access.
        #0 0x55f4628c3ca8 in find_exif_tag eva/put/libheif/libheif/exif.cc:88
        #1 0x55f4628c536b in modify_exif_tag_if_it_exists(unsigned char*, int, unsigned short, unsigned short) eva/put/libheif/libheif/exif.cc:124
        #2 0x55f4628c536b in modify_exif_orientation_tag_if_it_exists(unsigned char*, int, unsigned short) eva/put/libheif/libheif/exif.cc:140
        #3 0x55f4628cac75 in PngEncoder::Encode(heif_image_handle const*, heif_image const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) eva/put/libheif/examples/encoder_png.cc:126
        #4 0x55f4628b4c99 in main eva/put/libheif/examples/heif_convert.cc:509
        #5 0x7fb342a29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #6 0x7fb342a29e3f in __libc_start_main_impl ../csu/libc-start.c:392
        #7 0x55f4628bd254 in _start (eva/put/libheif/build/examples/heif-convert+0x15254)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV eva/put/libheif/libheif/exif.cc:88 in find_exif_tag
    ==216883==ABORTING
    

**POC**

poc

**Environment**

    Description:	Ubuntu 22.04.2 LTS
    gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
    

**Credit**

Yuchuan Meng (Fudan University)

CVE-2023-49463: SEGV libheif/libheif/exif.cc:88 in find_exif_tag · Issue #1042 · strukturag/libheif

libheif v1.17.5 was discovered to contain a segmentation violation via the function UncompressedImageCodec::decode_uncompressed_image.

**Description**

AddressSanitizer: SEGV in decode_uncompressed_image

**Version**

    commit: 64ece913266609789f5dc70fe7de9eb759badd7f
    
    heif-convert  libheif version: 1.17.5
    -------------------------------------------
    Usage: heif-convert [options]  <input-image> [output-image]
    
    The program determines the output file format from the output filename suffix.
    These suffixes are recognized: jpg, jpeg, png, y4m. If no output filename is specified, 'jpg' is used.
    
    Options:
      -h, --help                     show help
      -v, --version                  show version
      -q, --quality                  quality (for JPEG output)
      -o, --output FILENAME          write output to FILENAME (optional)
      -d, --decoder ID               use a specific decoder (see --list-decoders)
          --with-aux                 also write auxiliary images (e.g. depth images)
          --with-xmp                 write XMP metadata to file (output filename with .xmp suffix)
          --with-exif                write EXIF metadata to file (output filename with .exif suffix)
          --skip-exif-offset         skip EXIF metadata offset bytes
          --no-colons                replace ':' characters in auxiliary image filenames with '_'
          --list-decoders            list all available decoders (built-in and plugins)
          --quiet                    do not output status messages to console
      -C, --chroma-upsampling ALGO   Force chroma upsampling algorithm (nn = nearest-neighbor / bilinear)
          --png-compression-level #  Set to integer between 0 (fastest) and 9 (best). Use -1 for default.
    

**Replay**

    cd libheif
    mkdir build && cd build
    CC="gcc -fsanitize=address" CXX="g++ -fsanitize=address" cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_UNCOMPRESSED_CODEC=ON ..
    make -j
    ./examples/heif-convert ./poc test.png
    

**ASAN**

    ==89344==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f955d086aeb bp 0x7ffdd923ebb0 sp 0x7ffdd923e318 T0)
    ==89344==The signal is caused by a READ memory access.
    ==89344==Hint: address points to the zero page.
        #0 0x7f955d086aea in memcpy (/lib/x86_64-linux-gnu/libc.so.6+0xbbaea)
        #1 0x7f955d85f4de  (/lib/x86_64-linux-gnu/libasan.so.4+0x7a4de)
        #2 0x7f955d6f8495 in UncompressedImageCodec::decode_uncompressed_image(std::shared_ptr<HeifFile const> const&, unsigned int, std::shared_ptr<HeifPixelImage>&, unsigned int, unsigned int, std::vector<unsigned char, std::allocator<unsigned char> > const&) libheif/libheif/uncompressed_image.cc:758
        #3 0x7f955d5b7304 in HeifContext::decode_image_planar(unsigned int, std::shared_ptr<HeifPixelImage>&, heif_colorspace, heif_decoding_options const&, bool) const libheif/libheif/context.cc:1452
        #4 0x7f955d5b42a8 in HeifContext::decode_image_user(unsigned int, std::shared_ptr<HeifPixelImage>&, heif_colorspace, heif_chroma, heif_decoding_options const&) const libheif/libheif/context.cc:1248
        #5 0x7f955d5771f4 in heif_decode_image libheif/libheif/heif.cc:1044
        #6 0x55e9351aca11 in main libheif/examples/heif_convert.cc:484
        #7 0x7f955cfef082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082)
        #8 0x55e9351a7add in _start (libheif/build/examples/heif-convert+0xbadd)
    

**POC**

*   poc

**Environment**

    Description:	Ubuntu 22.04.2 LTS
    gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
    

**Credit**

Yuchuan Meng (Fudan University)

CVE-2023-49460: AddressSanitizer: SEGV in `decode_uncompressed_image` · Issue #1046 · strukturag/libheif

Libde265 v1.0.14 was discovered to contain a heap-buffer-overflow vulnerability in the derive_spatial_luma_vector_prediction function at motion.cc.

**Description**

heap-buffer-overflow libde265/libde265/motion.cc:1860 in derive_spatial_luma_vector_prediction(base_context*, de265_image*, slice_segment_header const*, int, int, int, int, int, int, int, int, int, int, unsigned char*, MotionVector*)

**Version**

     dec265  v1.0.14
    -----------------
    usage: dec265 [options] videofile.bin
    The video file must be a raw bitstream, or a stream with NAL units (option -n).
    
    options:
      -q, --quiet       do not show decoded image
      -t, --threads N   set number of worker threads (0 - no threading)
      -c, --check-hash  perform hash check
      -n, --nal         input is a stream with 4-byte length prefixed NAL units
      -f, --frames N    set number of frames to process
      -o, --output      write YUV reconstruction
      -d, --dump        dump headers
      -0, --noaccel     do not use any accelerated code (SSE)
      -v, --verbose     increase verbosity level (up to 3 times)
      -L, --no-logging  disable logging
      -B, --write-bytestream FILENAME  write raw bytestream (from NAL input)
      -m, --measure YUV compute PSNRs relative to reference YUV
      -T, --highest-TID select highest temporal sublayer to decode
          --disable-deblocking   disable deblocking filter
          --disable-sao          disable sample-adaptive offset filter
      -h, --help        show help
    

**Replay**

    cd libde265
    CC="gcc -fsanitize=address" CXX="g++ -fsanitize=address" ./configure
    make -j
    
    # You need to try running poc several times to see the asan result.
    ./dec265/dec265 ./poc
    

**ASAN**

    ==1982966==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b000001b10 at pc 0x56501e786954 bp 0x7ffc66164680 sp 0x7ffc66164670
    READ of size 4 at 0x61b000001b10 thread T0
        #0 0x56501e786953 in derive_spatial_luma_vector_prediction(base_context*, de265_image*, slice_segment_header const*, int, int, int, int, int, int, int, int, int, int, unsigned char*, MotionVector*) libde265/libde265/motion.cc:1860
        #1 0x56501e787950 in fill_luma_motion_vector_predictors(base_context*, slice_segment_header const*, de265_image*, int, int, int, int, int, int, int, int, int, int, MotionVector*) libde265/libde265/motion.cc:1990
        #2 0x56501e79c58a in luma_motion_vector_prediction(base_context*, slice_segment_header const*, de265_image*, PBMotionCoding const&, int, int, int, int, int, int, int, int, int, int) libde265/libde265/motion.cc:2063
        #3 0x56501e79c58a in motion_vectors_and_ref_indices(base_context*, slice_segment_header const*, de265_image*, PBMotionCoding const&, int, int, int, int, int, int, int, int, PBMotion*) libde265/libde265/motion.cc:2155
        #4 0x56501e79c58a in decode_prediction_unit(base_context*, slice_segment_header const*, de265_image*, PBMotionCoding const&, int, int, int, int, int, int, int, int) libde265/libde265/motion.cc:2195
        #5 0x56501e662806 in read_prediction_unit(thread_context*, int, int, int, int, int, int, int, int, int) libde265/libde265/slice.cc:4145
        #6 0x56501e66c4cb in read_coding_unit(thread_context*, int, int, int, int) libde265/libde265/slice.cc:4506
        #7 0x56501e670f59 in read_coding_quadtree(thread_context*, int, int, int, int) libde265/libde265/slice.cc:4650
        #8 0x56501e670df6 in read_coding_quadtree(thread_context*, int, int, int, int) libde265/libde265/slice.cc:4644
        #9 0x56501e670f59 in read_coding_quadtree(thread_context*, int, int, int, int) libde265/libde265/slice.cc:4650
        #10 0x56501e673696 in decode_substream(thread_context*, bool, bool) libde265/libde265/slice.cc:4750
        #11 0x56501e679fc9 in read_slice_segment_data(thread_context*) libde265/libde265/slice.cc:5063
        #12 0x56501e53c8b4 in decoder_context::decode_slice_unit_sequential(image_unit*, slice_unit*) libde265/libde265/decctx.cc:854
        #13 0x56501e543e55 in decoder_context::decode_slice_unit_parallel(image_unit*, slice_unit*) libde265/libde265/decctx.cc:956
        #14 0x56501e5477eb in decoder_context::decode_some(bool*) libde265/libde265/decctx.cc:741
        #15 0x56501e55957a in decoder_context::read_slice_NAL(bitreader&, NAL_unit*, nal_header&) libde265/libde265/decctx.cc:699
        #16 0x56501e55b645 in decoder_context::decode_NAL(NAL_unit*) libde265/libde265/decctx.cc:1241
        #17 0x56501e55c508 in decoder_context::decode(int*) libde265/libde265/decctx.cc:1329
        #18 0x56501e51646c in main libde265/dec265/dec265.cc:784
        #19 0x7fd4aa229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #20 0x7fd4aa229e3f in __libc_start_main_impl ../csu/libc-start.c:392
        #21 0x56501e518ce4 in _start (eva/asan-bin/NestFuzz/libde265/dec265+0x1ece4)
    
    0x61b000001b10 is located 8 bytes to the right of 1416-byte region [0x61b000001580,0x61b000001b08)
    allocated by thread T0 here:
        #0 0x7fd4aaab61e7 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
        #1 0x56501e557f17 in decoder_context::read_slice_NAL(bitreader&, NAL_unit*, nal_header&) libde265/libde265/decctx.cc:635
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow libde265/libde265/motion.cc:1860 in derive_spatial_luma_vector_prediction(base_context*, de265_image*, slice_segment_header const*, int, int, int, int, int, int, int, int, int, int, unsigned char*, MotionVector*)
    

**POC**

poc

**Environment**

    Description:	Ubuntu 22.04.2 LTS
    gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
    

**Credit**

Yuchuan Meng (Fudan University)

CVE-2023-49465: heap-buffer-overflow `libde265/libde265/motion.cc:1860` in `derive_spatial_luma_vector_prediction` · Issue #435 · strukturag/libde265

Libde265 v1.0.14 was discovered to contain a heap-buffer-overflow vulnerability in the derive_combined_bipredictive_merging_candidates function at motion.cc.

**Description**

heap-buffer-overflow eva/put/libde265/libde265/motion.cc:1443 in derive_combined_bipredictive_merging_candidates(base_context const*, slice_segment_header const*, PBMotion*, int*, int)

**Version**

     dec265  v1.0.14
    -----------------
    usage: dec265 [options] videofile.bin
    The video file must be a raw bitstream, or a stream with NAL units (option -n).
    
    options:
      -q, --quiet       do not show decoded image
      -t, --threads N   set number of worker threads (0 - no threading)
      -c, --check-hash  perform hash check
      -n, --nal         input is a stream with 4-byte length prefixed NAL units
      -f, --frames N    set number of frames to process
      -o, --output      write YUV reconstruction
      -d, --dump        dump headers
      -0, --noaccel     do not use any accelerated code (SSE)
      -v, --verbose     increase verbosity level (up to 3 times)
      -L, --no-logging  disable logging
      -B, --write-bytestream FILENAME  write raw bytestream (from NAL input)
      -m, --measure YUV compute PSNRs relative to reference YUV
      -T, --highest-TID select highest temporal sublayer to decode
          --disable-deblocking   disable deblocking filter
          --disable-sao          disable sample-adaptive offset filter
      -h, --help        show help
    

**Replay**

    cd libde265
    CC="gcc -fsanitize=address" CXX="g++ -fsanitize=address" ./configure
    make -j
    
    # You need to try running poc several times to see the asan result.
    ./dec265/dec265 ./poc
    

**ASAN**

    =================================================================
    ==3684026==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b000000658 at pc 0x5621bef6c512 bp 0x7ffe781d0d70 sp 0x7ffe781d0d60
    READ of size 4 at 0x61b000000658 thread T0
        #0 0x5621bef6c511 in derive_combined_bipredictive_merging_candidates(base_context const*, slice_segment_header const*, PBMotion*, int*, int) eva/put/libde265/libde265/motion.cc:1443
        #1 0x5621bef6d403 in get_merge_candidate_list_without_step_9(base_context*, slice_segment_header const*, MotionVectorAccess const&, de265_image*, int, int, int, int, int, int, int, int, int, PBMotion*) eva/put/libde265/libde265/motion.cc:1564
        #2 0x5621bef8da6a in derive_luma_motion_merge_mode(base_context*, slice_segment_header const*, de265_image*, int, int, int, int, int, int, int, int, int, PBMotion*) eva/put/libde265/libde265/motion.cc:1622
        #3 0x5621bef8da6a in motion_vectors_and_ref_indices(base_context*, slice_segment_header const*, de265_image*, PBMotionCoding const&, int, int, int, int, int, int, int, int, PBMotion*) eva/put/libde265/libde265/motion.cc:2112
        #4 0x5621bef8da6a in decode_prediction_unit(base_context*, slice_segment_header const*, de265_image*, PBMotionCoding const&, int, int, int, int, int, int, int, int) eva/put/libde265/libde265/motion.cc:2195
        #5 0x5621bee53806 in read_prediction_unit(thread_context*, int, int, int, int, int, int, int, int, int) eva/put/libde265/libde265/slice.cc:4145
        #6 0x5621bee5d5ff in read_coding_unit(thread_context*, int, int, int, int) eva/put/libde265/libde265/slice.cc:4513
        #7 0x5621bee61e7f in read_coding_quadtree(thread_context*, int, int, int, int) eva/put/libde265/libde265/slice.cc:4647
        #8 0x5621bee61df6 in read_coding_quadtree(thread_context*, int, int, int, int) eva/put/libde265/libde265/slice.cc:4644
        #9 0x5621bee64696 in decode_substream(thread_context*, bool, bool) eva/put/libde265/libde265/slice.cc:4750
        #10 0x5621bee6afc9 in read_slice_segment_data(thread_context*) eva/put/libde265/libde265/slice.cc:5063
        #11 0x5621bed2d8b4 in decoder_context::decode_slice_unit_sequential(image_unit*, slice_unit*) eva/put/libde265/libde265/decctx.cc:854
        #12 0x5621bed34e55 in decoder_context::decode_slice_unit_parallel(image_unit*, slice_unit*) eva/put/libde265/libde265/decctx.cc:956
        #13 0x5621bed387eb in decoder_context::decode_some(bool*) eva/put/libde265/libde265/decctx.cc:741
        #14 0x5621bed4a57a in decoder_context::read_slice_NAL(bitreader&, NAL_unit*, nal_header&) eva/put/libde265/libde265/decctx.cc:699
        #15 0x5621bed4c645 in decoder_context::decode_NAL(NAL_unit*) eva/put/libde265/libde265/decctx.cc:1241
        #16 0x5621bed4d508 in decoder_context::decode(int*) eva/put/libde265/libde265/decctx.cc:1329
        #17 0x5621bed0746c in main eva/put/libde265/dec265/dec265.cc:784
        #18 0x7f2636829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #19 0x7f2636829e3f in __libc_start_main_impl ../csu/libc-start.c:392
        #20 0x5621bed09ce4 in _start (eva/asan-bin/NestFuzz/libde265/dec265+0x1ece4)
    
    0x61b000000658 is located 80 bytes to the right of 1416-byte region [0x61b000000080,0x61b000000608)
    allocated by thread T0 here:
        #0 0x7f26370b61e7 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
        #1 0x5621bed48f17 in decoder_context::read_slice_NAL(bitreader&, NAL_unit*, nal_header&) eva/put/libde265/libde265/decctx.cc:635
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow eva/put/libde265/libde265/motion.cc:1443 in derive_combined_bipredictive_merging_candidates(base_context const*, slice_segment_header const*, PBMotion*, int*, int)
    

**POC**

poc

**Environment**

    Description:	Ubuntu 22.04.2 LTS
    gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
    

**Credit**

Yuchuan Meng (Fudan University)

CVE-2023-49467: heap-buffer-overflow `libde265/libde265/motion.cc:1443` in `derive_combined_bipredictive_merging_candidates` · Issue #434 · strukturag/libde265

Libde265 v1.0.14 was discovered to contain a global buffer overflow vulnerability in the read_coding_unit function at slice.cc.

**Description**

global-buffer-overflow libde265/libde265/slice.cc:4493 in read_coding_unit(thread_context*, int, int, int, int)

**Version**

     dec265  v1.0.14
    -----------------
    usage: dec265 [options] videofile.bin
    The video file must be a raw bitstream, or a stream with NAL units (option -n).
    
    options:
      -q, --quiet       do not show decoded image
      -t, --threads N   set number of worker threads (0 - no threading)
      -c, --check-hash  perform hash check
      -n, --nal         input is a stream with 4-byte length prefixed NAL units
      -f, --frames N    set number of frames to process
      -o, --output      write YUV reconstruction
      -d, --dump        dump headers
      -0, --noaccel     do not use any accelerated code (SSE)
      -v, --verbose     increase verbosity level (up to 3 times)
      -L, --no-logging  disable logging
      -B, --write-bytestream FILENAME  write raw bytestream (from NAL input)
      -m, --measure YUV compute PSNRs relative to reference YUV
      -T, --highest-TID select highest temporal sublayer to decode
          --disable-deblocking   disable deblocking filter
          --disable-sao          disable sample-adaptive offset filter
      -h, --help        show help
    

**Replay**

    cd libde265
    CC="gcc -fsanitize=address" CXX="g++ -fsanitize=address" ./configure
    make -j
    ./dec265/dec265 ./poc
    

**ASAN**

    ==1753516==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f6e8318665e at pc 0x7f6e83139f09 bp 0x7fffda7f3620 sp 0x7fffda7f3610
    READ of size 1 at 0x7f6e8318665e thread T0
        #0 0x7f6e83139f08 in read_coding_unit(thread_context*, int, int, int, int) libde265/libde265/slice.cc:4493
        #1 0x7f6e8313abda in read_coding_quadtree(thread_context*, int, int, int, int) libde265/libde265/slice.cc:4650
        #2 0x7f6e8313b941 in decode_substream(thread_context*, bool, bool) libde265/libde265/slice.cc:4750
        #3 0x7f6e8313d29d in read_slice_segment_data(thread_context*) libde265/libde265/slice.cc:5063
        #4 0x7f6e830ca881 in decoder_context::decode_slice_unit_sequential(image_unit*, slice_unit*) libde265/libde265/decctx.cc:854
        #5 0x7f6e830cca4d in decoder_context::decode_slice_unit_parallel(image_unit*, slice_unit*) libde265/libde265/decctx.cc:956
        #6 0x7f6e830ccfe5 in decoder_context::decode_some(bool*) libde265/libde265/decctx.cc:741
        #7 0x7f6e830d4ec2 in decoder_context::read_slice_NAL(bitreader&, NAL_unit*, nal_header&) libde265/libde265/decctx.cc:699
        #8 0x7f6e830d5a4d in decoder_context::decode_NAL(NAL_unit*) libde265/libde265/decctx.cc:1241
        #9 0x7f6e830d6308 in decoder_context::decode(int*) libde265/libde265/decctx.cc:1329
        #10 0x55b9a8c5fd26 in main libde265/dec265/dec265.cc:784
        #11 0x7f6e81e29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #12 0x7f6e81e29e3f in __libc_start_main_impl ../csu/libc-start.c:392
        #13 0x55b9a8c60ca4 in _start (libde265/dec265/.libs/dec265+0x5ca4)
    
    0x7f6e8318665e is located 14 bytes to the right of global variable 'ctxIdxMap' defined in 'slice.cc:1964:22' (0x7f6e83186640) of size 16
    SUMMARY: AddressSanitizer: global-buffer-overflow libde265/libde265/slice.cc:4493 in read_coding_unit(thread_context*, int, int, int, int)
    Shadow bytes around the buggy address:
      0x0fee50628c70: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 01 f9 f9
      0x0fee50628c80: f9 f9 f9 f9 00 00 00 f9 f9 f9 f9 f9 00 00 00 01
      0x0fee50628c90: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 00 00 00 00
      0x0fee50628ca0: 00 00 00 03 f9 f9 f9 f9 00 00 00 00 00 00 00 02
      0x0fee50628cb0: f9 f9 f9 f9 00 00 00 00 03 f9 f9 f9 f9 f9 f9 f9
    =>0x0fee50628cc0: 00 00 f9 f9 f9 f9 f9 f9 00 00 f9[f9]f9 f9 f9 f9
      0x0fee50628cd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0fee50628ce0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0fee50628cf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0fee50628d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0fee50628d10: 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
    ==1753516==ABORTING
    

**POC**

poc

**Environment**

    Description:	Ubuntu 22.04.2 LTS
    gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
    

**Credit**

Yuchuan Meng (Fudan University)

CVE-2023-49468: global-buffer-overflow in read_coding_unit · Issue #432 · strukturag/libde265

strongSwan before 5.9.12 has a buffer overflow and possible unauthenticated remote code execution via a DH public value that exceeds the internal buffer in charon-tkm's DH proxy. The earliest affected version is 5.3.0. An attack can occur via a crafted IKE_SA_INIT message.

CVE-2023-41913: Releases · strongswan/strongswan

An issue was discovered in the function gdev_prn_open_printer_seekable() in Artifex Ghostscript through 10.02.0 allows remote attackers to crash the application via a dangling pointer.

Ghostscript is an interpreter for the PostScript®  language and PDF files. It is available under either the GNU GPL Affero license or  licensed for commercial use from Artifex Software, Inc. It has been under active development for over 30 years and has been ported to several different systems during this time. Ghostscript consists of a PostScript interpreter layer and a graphics library.

There are a family of other products, including GhostPCL, GhostPDF, and GhostXPS that are built upon the same graphics library. Between them, this family of products offers native rendering of all major page description languages. Our latest product, GhostPDL, pulls all these languages into a single executable.

Full descriptions of these products can be found on our documentation introduction.

In addition to rendering to raster formats, Ghostscript offers high-level conversion through our vector output devices.

Written entirely in C, Ghostscript runs on various embedded operating systems and platforms including Windows, macOS, the wide variety of Unix and Unix-like platforms, and VMS systems.

**Current Release**

The current Ghostscript release 10.02.1 can be downloaded here.

**NEW in this Release**

*   Old PDF Interpreter has now been removed - see https://ghostscript.com/blog/pdfi.html for more details
*   And more! Review the full release notes.

**The Ghostscript Blog**

Find news, articles and developer notes from the Ghostscript engineering team on the blog.

**Security Advisory**

*   *   November 1, 2023: Ghostscript/GhostPDL 10.02.1 release fixes CVE-2023-46751.
        
    *   CVE-2023-46751 affects _all_ Ghostscript/GhostPDL versions prior to 10.02.1.
        
    *   CVE-2023-46751 is a shell command injection/remote code execution risk, so we recommend upgrading to version 10.02.1 as a matter of urgency
        
    
    *   September 18, 2023: Ghostscript/GhostPDL 10.02.0 release fixes CVE-2023-43115.
        
    *   CVE-2023-43115 affects _all_ Ghostscript/GhostPDL versions prior to 10.02.0.
        
    *   CVE-2023-43115 is a remote code execution risk, so we recommend upgrading to version 10.02.0 as a matter of urgency
        
    
    *   June 27, 2023: Ghostscript/GhostPDL 10.01.2 release fixes CVE-2023-36664.
        
    *   CVE-2023-36664 affects _all_ Ghostscript/GhostPDL versions prior to 10.01.2.
        
*   April 3, 2023: Ghostscript/GhostPDL 10.01.1 release fixes CVE-2023-28879.
    
*   April 4, 2022: Ghostscript/GhostPDL 9.56.1 bundles zlib 1.2.12 which addresses CVE-2018-25032.
    
*   December 16, 2021: Apache Log4J vulnerability – GHOSTSCRIPT NOT AFFECTED – For more info: CVE-2021-44228
    

**Related projects**

*   Memento: A memory debugging library for C (or C++) programs.
*   jbig2dec: A JBIG2 image decoder.

CVE-2023-46751: Ghostscript

A data integrity vulnerability exists in the BR_NO_CHECK_HASH_FOR functionality of Buildroot 2023.08.1 and dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.

**SUMMARY**

A data integrity vulnerability exists in the BR\_NO\_CHECK\_HASH\_FOR functionality of Buildroot 2023.08.1 and dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.

**CONFIRMED VULNERABLE VERSIONS**

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

Buildroot 2023.08.1  
Buildroot dev commit 622698d7847

**PRODUCT URLS**

Buildroot - https://www.buildroot.org/

**CVSSv3 SCORE**

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

**CWE**

CWE-494 - Download of Code Without Integrity Check

**DETAILS**

Buildroot is a tool that automates builds of Linux environments for embedded systems. It supports cross-compiling for multiple target platforms and allows for building a cross-compilation toolchain, Linux kernel image, boot loader, root file system and various utilities.

When building a package, Buildroot executes the corresponding Makefile. Source code is typically downloaded from the internet for most packages, while some are included within Buildroot. Upon downloading the source, Buildroot verifies the integrity of the package using a hash file, extracts the sources, applies any necessary patches and then proceeds with the actual building process.

To describe the logic in detail, let’s use the strace package as a simple example:

In package/strace/strace.mk:

    STRACE_VERSION = 6.5
    STRACE_SOURCE = strace-$(STRACE_VERSION).tar.xz
    STRACE_SITE = https://github.com/strace/strace/releases/download/v$(STRACE_VERSION)
    ...
    $(eval $(autotools-package))
    

In package/strace/strace.hash:

    # Locally calculated after checking signature with RSA key 0xA8041FA839E16E36
    # https://strace.io/files/6.5/strace-6.5.tar.xz.asc
    sha256  dfb051702389e1979a151892b5901afc9e93bbc1c70d84c906ade3224ca91980  strace-6.5.tar.xz
    sha256  d92f973d08c8466993efff1e500453add0c038c20b4d2cbce3297938a296aea9  COPYING
    sha256  7c379436436a562834aa7d2f5dcae1f80a25230fa74201046ca1fba4367d39aa  LGPL-2.1-or-later
    

STRACE_SITE defines the external site to fetch the sources from and STRACE_SOURCE defines the actual package name to retrieve. The autotools-package is then evaluated to interpret the various <PACKAGE_NAME>_<VARIABLE> definitions defined in the package .mk and generate all the Makefiles rules needed to build the package.

In the .hash file, we can see sha256 hashes for any file that is being downloaded externally so their integrity can be verified after download.

When the strace package is selected in the config, calling make strace-source will download the package sources. The download function is defined in package/pkg-download.mk, which relays the request to the support/download/dl-wrapper shell script.  
In the case of strace, dl-wrapper is called like this:

    support/download/dl-wrapper
        -c 6.4
        -d /opt/buildroot/dl/strace
        -D /opt/buildroot/dl
        -f strace-6.4.tar.xz
        -H package/strace//strace.hash
        -n strace-6.4
        -N strace
        -o /opt/buildroot/dl/strace/strace-6.4.tar.xz
        -u https+https://github.com/strace/strace/releases/download/v6.4
        -u http|urlencode+http://sources.buildroot.net/strace
        -u http|urlencode+http://sources.buildroot.net
    

Interesting parameters to note:

*   -H defines the .hash file for integrity checks
*   -u can be specified multiple times, to provide a fallback in case the primary URL is not available

The http://sources.buildroot.net URLs have been passed as fallback because they correspond to the default value of BR2_BACKUP_SITE. This behavior is enabled by default. However, it is possible to set BR2_PRIMARY_SITE_ONLY to disable it and only allow downloads from the primary resource.

Inside dl-wrapper:

        ...
        download_and_check=0
        rc=1
    [1] for uri in "${uris[@]}"; do
            backend_urlencode="${uri%%+*}"
            backend="${backend_urlencode%|*}"
            case "${backend}" in
                git|svn|cvs|bzr|file|scp|hg|sftp) ;;
                *) backend="wget" ;;
            esac
            uri=${uri#*+}
    
            ...
    [2]     if ! "${OLDPWD}/support/download/${backend}" \
                    $([ -n "${urlencode}" ] && printf %s '-e') \
                    -c "${cset}" \
                    -d "${dl_dir}" \
                    -n "${raw_base_name}" \
                    -N "${base_name}" \
                    -f "${filename}" \
                    -u "${uri}" \
                    -o "${tmpf}" \
                    ${quiet} ${large_file} ${recurse} -- "${@}"
            then
                ...
                continue
            fi
    
            ...
            # Check if the downloaded file is sane, and matches the stored hashes
            # for that file
    [3]     if support/download/check-hash ${quiet} "${hfile}" "${tmpf}" "${output##*/}"; then
                rc=0
            else
                if [ ${?} -ne 3 ]; then
                    rm -rf "${tmpd}"
                    continue
                fi
    
                # the hash file exists and there was no hash to check the file
                # against
                rc=1
            fi
    [4]     download_and_check=1
            break
        done
    
        # We tried every URI possible, none seems to work or to check against the
        # available hash. *ABORT MISSION*
    [5] if [ "${download_and_check}" -eq 0 ]; then
            rm -rf "${tmpd}"
            exit 1
        fi
    

For each URL (specified via -u) \[1\], the appropriate backend is used. In the case of strace the backend is simply wget, so wget is going to be called via the support/download/wget wrapper \[2\].

After the file is downloaded, the hash is checked (file is specified via -H) by calling check-hash \[3\]. If check-hash has a 0 exit status, rc is set to 0, download_and_check \[4, 5\] is set to 1 to indicate success and the loop ends.

Let’s see how check-hash is implemented.

        ...
        # Does the hash-file exist?
    [6] if [ ! -f "${h_file}" ]; then
            printf "WARNING: no hash file for %s\n" "${base}" >&2
            exit 0
        fi
    
        # Check one hash for a file
        # $1: algo hash
        # $2: known hash
        # $3: file (full path)
        check_one_hash() {
            ... # exits with error code if the hash doesn't match
        }
    
        # Do we know one or more hashes for that file?
        nb_checks=0
        while read t h f; do
            case "${t}" in
                ''|'#'*)
                    # Skip comments and empty lines
                    continue
                    ;;
                *)
                    if [ "${f}" = "${base}" ]; then
    [7]                 check_one_hash "${t}" "${h}" "${file}"
                        : $((nb_checks++))
                    fi
                    ;;
            esac
        done <"${h_file}"
    
    [8] if [ ${nb_checks} -eq 0 ]; then
    [9]     case " ${BR_NO_CHECK_HASH_FOR} " in
            *" ${base} "*)
                # File explicitly has no hash
                exit 0
                ;;
            esac
            printf "ERROR: No hash found for %s\n" "${base}" >&2
            exit 3
        fi
    

For each hash line in the .hash file, check_one_hash is called \[7\]. If the hash doesn’t match, check_one_hash will exit with an error code. Otherwise nb_checks is incremented to indicate one successful check. If there’s no entry in the .hash file for the specified input file to check, the check at \[8\] will return an error unless BR_NO_CHECK_HASH_FOR \[9\] contains this specific file, meaning that the file is excluded from hash checks.

In total, there are 3 ways for check-hash to return 0 (success):

1.  no .hash file exists for the package \[6\]
2.  the $file’s hash matches the definition in the .hash file \[7\]
3.  the $file is not present in the .hash file and BR_NO_CHECK_HASH_FOR contains the base name for the package (explicitly skipping checks) \[9\]

Option 2 is what we expect to reach most of the time.

In this advisory, we focus on Option 3. This seems to be commonly used to skip integrity checks for resources that can’t be easily hashed (for example, developement resources that change often). It is also used when building specific versions of a package, for which hashes may not be available in Buildroot’s sources.

For example, the Linux Kernel Buildroot Makefile (linux/linux.mk):

    ...
    ifeq ($(BR2_LINUX_KERNEL)$(BR2_LINUX_KERNEL_LATEST_VERSION),y)
        BR_NO_CHECK_HASH_FOR += $(LINUX_SOURCE)
    endif
    ...
    

If both BR2_LINUX_KERNEL and BR2_LINUX_KERNEL_LATEST_VERSION where enabled, the result of $(BR2_LINUX_KERNEL)$(BR2_LINUX_KERNEL_LATEST_VERSION) would be yy.  
So, the ifeq checks if BR2_LINUX_KERNEL_LATEST_VERSION is NOT selected, in which case it adds linux-<version>-br1.tar.gz to the BR_NO_CHECK_HASH_FOR variable.

This is, however, problematic in some setups. For example, consider this Buildroot minimal configuration:

    BR2_LINUX_KERNEL=y
    BR2_LINUX_KERNEL_CUSTOM_GIT=y
    BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://192.168.50.50"
    BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="123"
    

This defines a custom repository for fetching the Linux Kernel, so it may be important to only fetch the sources from that repository, for Linux specifically. This will work fine the majority of the time. However, if an attacker is able to drop connections towards 192.168.50.50, this will make the if condition at \[2\] fail, and the loop at \[1\] will perform the download using the next $uri. The next $uri is going to be http://sources.buildroot.net/linux/linux-123-br1.tar.gz, because of the default BR2_BACKUP_SITE variable. This will lead to downloading Linux Kernel sources via plain HTTP without performing any hash checks.

Since the Linux Kernel can ship patch files or Makefiles, by supplying a compromised source package, an attacker would be able to execute arbitrary commands in the builder. As a direct consequence, an attacker could then also tamper with any file generated for Buildroot’s targets and hosts.  
For example, it’s enough to provide a Makefile with the following command:

    _ := $(shell id >> /injected)
    

Or insert such a line in a .patch file, which would allow modification of any package within Buildroot during the build process.

**Exploit Proof of Concept**

This proof-of-concept assumes that an attacker is MITM-ing the network and dropping requests to 192.168.50.50, while at the same time serving any .tar.gz file requested via port 80 with a malicious version:

    $ make source
    /usr/bin/make -j1  O=/tmp/builddir HOSTCC="/usr/bin/gcc" HOSTCXX="/usr/bin/g++" syncconfig
    mkdir -p /tmp/builddir/build/buildroot-config/lxdialog
    PKG_CONFIG_PATH="" /usr/bin/make CC="/usr/bin/gcc" HOSTCC="/usr/bin/gcc" \
        obj=/tmp/builddir/build/buildroot-config -C support/kconfig -f Makefile.br conf
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"  -MM *.c > /tmp/builddir/build/buildroot-config/.depend 2>/dev/null || :
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"   -c conf.c -o /tmp/builddir/build/buildroot-config/conf.o
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"  -I. -c /tmp/builddir/build/buildroot-config/zconf.tab.c -o /tmp/builddir/build/buildroot-config/zconf.tab.o
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"   /tmp/builddir/build/buildroot-config/conf.o /tmp/builddir/build/buildroot-config/zconf.tab.o  -o /tmp/builddir/build/buildroot-config/conf
    rm /tmp/builddir/build/buildroot-config/zconf.tab.c
      GEN     /tmp/builddir/Makefile
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    glibc-2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701.tar.gz: OK (sha256: fd991e43997ff6e4994264c3cbc23fa87fa28b1b3c446eda8fc2d1d3834a2cfb)
    bison-3.8.2.tar.xz: OK (sha256: 9bba0214ccf7f1079c5d59210045227bcf619519840ebfa80cd3849cff5a5bf2)
    m4-1.4.19.tar.xz: OK (sha256: 63aede5c6d33b6d9b13511cd0be2cac046f2e70fd0a07aa9573a04a82783af96)
    gawk-5.2.2.tar.xz: OK (sha256: 3c1fce1446b4cbee1cd273bd7ec64bc87d89f61537471cd3e05e33a965a250e9)
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    binutils-2.40.tar.xz: OK (sha512: a37e042523bc46494d99d5637c3f3d8f9956d9477b748b3b1f6d7dfbb8d968ed52c932e88a4e946c6f77b8f48f1e1b360ca54c3d298f17193f3b4963472f6925)
    gmp-6.3.0.tar.xz: OK (sha256: a3c2b80201b89e68616f4ad30bc66aee4927c3ce50e33929ca819d5c43538898)
    mpc-1.2.1.tar.gz: OK (sha256: 17503d2c395dfcf106b622dc142683c1199431d095367c6aacba6eec30340459)
    mpfr-4.1.1.tar.xz: OK (sha256: ffd195bd567dbaffc3b98b23fd00aad0537680c9896171e44fe3ff79e28ac33d)
    >>> linux-headers 123 Downloading
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git init .
    hint: Using 'master' as the name for the initial branch. This default branch name
    hint: is subject to change. To configure the initial branch name to use in all
    hint: of your new repositories, which will suppress this warning, call:
    hint:
    hint:   git config --global init.defaultBranch <name>
    hint:
    hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
    hint: 'development'. The just-created branch can be renamed via this command:
    hint:
    hint:   git branch -m <name>
    Initialized empty Git repository in /opt/buildroot/dl/linux/git/.git/
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote add origin 'https://192.168.50.50'
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote set-url origin 'https://192.168.50.50'
    Fetching all references
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git fetch origin
    fatal: unable to access 'https://192.168.50.50/': Failed to connect to 192.168.50.50 port 443 after 0 ms: Connection refused
    Detected a corrupted git cache.
    Removing it and starting afresh.
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git init .
    hint: Using 'master' as the name for the initial branch. This default branch name
    hint: is subject to change. To configure the initial branch name to use in all
    hint: of your new repositories, which will suppress this warning, call:
    hint:
    hint:   git config --global init.defaultBranch <name>
    hint:
    hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
    hint: 'development'. The just-created branch can be renamed via this command:
    hint:
    hint:   git branch -m <name>
    Initialized empty Git repository in /opt/buildroot/dl/linux/git/.git/
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote add origin 'https://192.168.50.50'
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote set-url origin 'https://192.168.50.50'
    Fetching all references
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git fetch origin
    fatal: unable to access 'https://192.168.50.50/': Failed to connect to 192.168.50.50 port 443 after 0 ms: Connection refused
    Detected a corrupted git cache.
    This is the second time in a row; bailing out
    wget --passive-ftp -nd -t 3 -O '/tmp/builddir/build/.linux-123-br1.tar.gz.OBKF3J/output' 'http://sources.buildroot.net/linux/linux-123-br1.tar.gz'
    --2023-10-11 16:16:26--  http://sources.buildroot.net/linux/linux-123-br1.tar.gz
    Resolving sources.buildroot.net (sources.buildroot.net)... 104.26.0.37, 172.67.72.56, 104.26.1.37
    Connecting to sources.buildroot.net (sources.buildroot.net)|104.26.0.37|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: unspecified [application/x-xz]
    Saving to: '/tmp/builddir/build/.linux-123-br1.tar.gz.OBKF3J/output'
    
    /tmp/builddir/build/.linux-123-br1.tar.gz.OB     [ <=>                                                                                        ]     160  --.-KB/s    in 0s
    
    2023-10-11 16:16:26 (24.1 MB/s) - '/tmp/builddir/build/.linux-123-br1.tar.gz.OBKF3J/output' saved [160]
    
    busybox-1.36.1.tar.bz2: OK (sha256: b8cc24c9574d809e7279c3be349795c5d5ceb6fdf19ca709f80cde50e47de314)
    kmod-31.tar.xz: OK (sha256: f5a6949043cc72c001b728d8c218609c5a15f3c33d75614b78c79418fcf00d80)
    pkgconf-1.6.3.tar.xz: OK (sha256: 61f0b31b0d5ea0e862b454a80c170f57bad47879c0c42bd8de89200ff62ea210)
    patchelf-0.13.tar.bz2: OK (sha256: 4c7ed4bcfc1a114d6286e4a0d3c1a90db147a4c3adda1814ee0eee0f9ee917ed)
    flex-2.6.4.tar.gz: OK (sha256: e87aae032bf07c26f85ac0ed3250998c37621d95f8bd748b31f15b33c45ee995)
    autoconf-2.71.tar.xz: OK (sha256: f14c83cfebcc9427f2c3cea7258bd90df972d92eb26752da4ddad81c87a0faa4)
    libtool-2.4.6.tar.xz: OK (sha256: 7c87a8c2c8c0fc9cd5019e402bed4292462d00a718a7cd5f11218153bf28b26f)
    automake-1.16.5.tar.xz: OK (sha256: f01d58cd6d9d77fbdca9eb4bbd5ead1988228fdb73d6f7a201f5f8d6b118b469)
    gettext-tiny-0.3.2.tar.gz: OK (sha256: 29cc165e27e83d2bb3760118c2368eadab550830d962d758e51bd36eb860f383)
    gettext-0.22.2.tar.xz: OK (sha256: 4c82fbfe5e53d71a97c634aa98a898b9da807b08b27410f6a4641e8bb44dc4b2)
    

**TIMELINE**

2023-10-25 - Vendor Disclosure  
2023-12-04 - Vendor Patch Release  
2023-12-05 - Public Release

Discovered by Claudio Bozzato and Francesco Benvenuto of Cisco Talos.

Tag

#c++