heap-buffer-overflow in file src/gif.imageio/gifinput.cpp, line 368

[xiaoxiaoafeifei]

Describe the bug:
Hi, I found heap-buffer-overflow in file src/gif.imageio/gifinput.cpp, line 368.

To Reproduce:
Steps to reproduce the behavior:

1. CC=afl-clang-fast CXX=afl-clang-fast++ CFLAGS="-gdwarf-2 -g3 -O0 -fsanitize=address -fno-omit-frame-pointer" CXXFLAGS="-gdwarf-2 -g3 -O0 -fsanitize=address -fno-omit-frame-pointer" LDFLAGS="-fsanitize=address" cmake .. -DCMAKE_CXX_STANDARD=17
2. make && make install
3. iconvert poc /tmp/res

poc file:
poc.zip

Evidence:
==1483==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000a3f9 at pc 0x7f8fd7a5f640 bp 0x7ffd22f8daf0 sp 0x7ffd22f8dae8
READ of size 1 at 0x60200000a3f9 thread T0
#0 0x7f8fd7a5f63f in OpenImageIO_v2_4::GIFInput::read_subimage_data() /root/github/oiio-2.4.11.0_1/src/gif.imageio/gifinput.cpp:368:65
#1 0x7f8fd7a57713 in OpenImageIO_v2_4::GIFInput::seek_subimage(int, int) /root/github/oiio-2.4.11.0_1/src/gif.imageio/gifinput.cpp:449:10
#2 0x7f8fd7a559af in OpenImageIO_v2_4::GIFInput::open(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, OpenImageIO_v2_4::ImageSpec&) /root/github/oiio-2.4.11.0_1/src/gif.imageio/gifinput.cpp:165:9
#3 0x7f8fd75febcf in OpenImageIO_v2_4::ImageInput::create(OpenImageIO_v2_4::basic_string_view<char, std::char_traits >, bool, OpenImageIO_v2_4::ImageSpec const*, OpenImageIO_v2_4::Filesystem::IOProxy*, OpenImageIO_v2_4::basic_string_view<char, std::char_traits >) /root/github/oiio-2.4.11.0_1/src/libOpenImageIO/imageioplugin.cpp:786:27
#4 0x7f8fd7552674 in OpenImageIO_v2_4::ImageInput::open(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, OpenImageIO_v2_4::ImageSpec const*, OpenImageIO_v2_4::Filesystem::IOProxy*) /root/github/oiio-2.4.11.0_1/src/libOpenImageIO/imageinput.cpp:112:16
#5 0x564781f3b48f in convert_file(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&) /root/github/oiio-2.4.11.0_1/src/iconvert/iconvert.cpp:330:15
#6 0x564781f4006f in main /root/github/oiio-2.4.11.0_1/src/iconvert/iconvert.cpp:523:14
#7 0x7f8fd493fd8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
#8 0x7f8fd493fe3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
#9 0x564781e7ac74 in _start (/root/github/oiio-2.4.11.0_1/dist/bin/iconvert+0x40c74) (BuildId: ac1803a32a6497261464974329db9ccd18ce83ad)

0x60200000a3f9 is located 3 bytes to the right of 6-byte region [0x60200000a3f0,0x60200000a3f6)
allocated by thread T0 here:
#0 0x564781efdca8 in __interceptor_calloc (/root/github/oiio-2.4.11.0_1/dist/bin/iconvert+0xc3ca8) (BuildId: ac1803a32a6497261464974329db9ccd18ce83ad)
#1 0x7f8fd22f6b98 in GifMakeMapObject (/lib/x86_64-linux-gnu/libgif.so.7+0x3b98) (BuildId: 1fff7899d615250f1b273a11e966d1347b233009)

SUMMARY: AddressSanitizer: heap-buffer-overflow /root/github/oiio-2.4.11.0_1/src/gif.imageio/gifinput.cpp:371:65 in OpenImageIO_v2_4::GIFInput::read_subimage_data()
Shadow bytes around the buggy address:
0x0c047fff9420: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
0x0c047fff9430: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
0x0c047fff9440: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
0x0c047fff9450: fa fa 00 fa fa fa 00 fa fa fa fd fa fa fa fd fd
0x0c047fff9460: fa fa fd fa fa fa fd fd fa fa fd fd fa fa fd fd
=>0x0c047fff9470: fa fa fd fd fa fa fd fd fa fa fd fd fa fa 06[fa]
0x0c047fff9480: fa fa 04 fa fa fa 01 fa fa fa fa fa fa fa fa fa
0x0c047fff9490: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff94a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff94b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff94c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==1483==ABORTING

Platform information:
OIIO branch/version: 2.4.11
OS: Linux
C++ compiler: clang-14.0.6

[xiaoxiaoafeifei]

Hi, can I request a CVE number for this? @lgritz

[lgritz]

Can you do the work to allocate the CVE number and document which version it was fixed in (2.4.12.0 for this one, and the upcoming 2.4.13.0 for the other ICO related one), or must it be the project administrator who submits the request?

[xiaoxiaoafeifei]

Thanks for your reply!
I'm trying to request a CVE id from redhat. It need upstream's consent before redhat proceed with the CVE assignment.

[lgritz]

Can you clarify who/what you mean by "upstream"?

[xiaoxiaoafeifei]

This refers to the maintainer of the project

[lgritz]

WHICH project? OpenImageIO? You mean me? In what form or to whom must I give consent? What should I do next?

Or by "upstream" did you mean RedHat? Or someone else?

[xiaoxiaoafeifei]

Yeah, redhat needs your consent (in the form of comment on issue link itself)

Here's what redhat sent me back:

_Hello,

Could you please get an upstream's acknowledgement for CVE assignment (in the form of comment on issue link itself) and provide us the reference? We need upstream's consent before we proceed with the CVE assignment.

Thank you!_

[lgritz]

This issue right here where we're talking right now?

Yes, as the project administrator, I hereby consent to a CVE being assigned.

[xiaoxiaoafeifei]

This issue right here where we're talking right now?

Yes, as the project administrator, I hereby consent to a CVE being assigned.

Ok, thank you!

[lgritz]

Sorry for the confusion, it took me a while to understand precisely what you needed from me to move the process along. I will do the same on the other issue.

[xiaoxiaoafeifei]

That’s all right. The process of applying for CVE can be complicated at times, and
I was confused at first, too

[Crispy-fried-chicken]

Hi, I want to know whether Release-2.3.3.0-dev~v2.4.10.0 has the same issue, please let me know, thank you!

[lgritz]

Probably the safest thing is to assume that the problem exists in all versions prior to 2.4.12.0 when it was definitively fixed.

But it's very possible that there was an earlier point where the problem was first introduced into the code, and that prior versions do not have the problem. But since we're now talking about multiple major versions older than we currently maintain or test, it would be a lot of work to figure out if that was the case. I'm not even sure if those old versions would build on today's toolchain without some some effort and maybe re-installing old compilers, etc.