You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of our fuzzing efforts at Google, we have identified an issue affecting
OpenEXR (tested with revision * develop 165dcea).
To reproduce, we are attaching a Dockerfile which compiles the project with
LLVM, taking advantage of the sanitizers that it offers. More information about
how to use the attached Dockerfile can be found here: https://docs.docker.com/engine/reference/builder/
And, back inside the container: /fuzzing/repro.sh /fuzzing/reproducer
Alternatively, and depending on the bug, you could use gcc, valgrind or other
instrumentation tools to aid in the investigation. The sanitizer error that we
encountered is here:
INFO: Seed: 3792189451
/fuzzing/openexr_fuzz_tiles: Running 1 inputs 1 time(s) each.
Running: /tmp/poc
=================================================================
==11==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000edd1 at pc 0x0000006e0de8 bp 0x7ffff6c61890 sp 0x7ffff6c61888
READ of size 1 at 0x60200000edd1 thread T0
#0 0x6e0de7 in inflate /fuzzing/zlib/inflate.c:662:13
#1 0x6caed8 in uncompress2 /fuzzing/zlib/uncompr.c:70:15
#2 0x6cb1fd in uncompress /fuzzing/zlib/uncompr.c:92:12
#3 0x624433 in Imf_2_2::Zip::uncompress(char const*, int, char*) /fuzzing/openexr/OpenEXR/IlmImf/ImfZip.cpp:148:17
#4 0x562f50 in Imf_2_2::ZipCompressor::uncompress(char const*, int, int, char const*&) /fuzzing/openexr/OpenEXR/IlmImf/ImfZipCompressor.cpp:119:24
#5 0x673a8f in Imf_2_2::(anonymous namespace)::TileBufferTask::execute() /fuzzing/openexr/OpenEXR/IlmImf/ImfTiledInputFile.cpp:534:62
#6 0x6c0b64 in IlmThread_2_2::ThreadPool::addTask(IlmThread_2_2::Task*) /fuzzing/openexr/IlmBase/IlmThread/IlmThreadPool.cpp:433:15
#7 0x66f979 in Imf_2_2::TiledInputFile::readTiles(int, int, int, int, int, int) /fuzzing/openexr/OpenEXR/IlmImf/ImfTiledInputFile.cpp:1204:21
#8 0x5d3711 in Imf_2_2::TiledRgbaInputFile::readTiles(int, int, int, int, int, int) /fuzzing/openexr/OpenEXR/IlmImf/ImfTiledRgbaFile.cpp:1136:21
#9 0x52530b in (anonymous namespace)::readImageRIP(Imf_2_2::TiledRgbaInputFile*, int, int) /fuzzing/security-research-pocs/autofuzz/openexr_fuzz_tiles.cc:119:13
#10 0x524db7 in fuzzImage(char const*) /fuzzing/security-research-pocs/autofuzz/openexr_fuzz_tiles.cc:145:3
#11 0x524c55 in LLVMFuzzerTestOneInput /fuzzing/security-research-pocs/autofuzz/openexr_fuzz_tiles.cc:178:3
#12 0x5171ec in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/openexr_fuzz_tiles+0x5171ec)
#13 0x5169ae in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long) (/fuzzing/openexr_fuzz_tiles+0x5169ae)
#14 0x51080d in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*) (/fuzzing/openexr_fuzz_tiles+0x51080d)
#15 0x511cdf in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/fuzzing/openexr_fuzz_tiles+0x511cdf)
#16 0x5106bc in main (/fuzzing/openexr_fuzz_tiles+0x5106bc)
#17 0x7f41ffb322b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#18 0x425dc9 in _start (/fuzzing/openexr_fuzz_tiles+0x425dc9)
0x60200000edd1 is located 0 bytes to the right of 1-byte region [0x60200000edd0,0x60200000edd1)
allocated by thread T0 here:
#0 0x50d4e0 in operator new[](unsigned long) (/fuzzing/openexr_fuzz_tiles+0x50d4e0)
#1 0x66c69e in Imf_2_2::TiledInputFile::initialize() /fuzzing/openexr/OpenEXR/IlmImf/ImfTiledInputFile.cpp:959:45
#2 0x66b5f7 in Imf_2_2::TiledInputFile::TiledInputFile(char const*, int) /fuzzing/openexr/OpenEXR/IlmImf/ImfTiledInputFile.cpp:721:2
#3 0x5d19da in Imf_2_2::TiledRgbaInputFile::TiledRgbaInputFile(char const*, int) /fuzzing/openexr/OpenEXR/IlmImf/ImfTiledRgbaFile.cpp:773:21
#4 0x524d6a in fuzzImage(char const*) /fuzzing/security-research-pocs/autofuzz/openexr_fuzz_tiles.cc:135:14
#5 0x524c55 in LLVMFuzzerTestOneInput /fuzzing/security-research-pocs/autofuzz/openexr_fuzz_tiles.cc:178:3
#6 0x5171ec in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/openexr_fuzz_tiles+0x5171ec)
#7 0x5106bc in main (/fuzzing/openexr_fuzz_tiles+0x5106bc)
SUMMARY: AddressSanitizer: heap-buffer-overflow /fuzzing/zlib/inflate.c:662:13 in inflate
Shadow bytes around the buggy address:
0x0c047fff9d60: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fd
0x0c047fff9d70: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x0c047fff9d80: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fa
0x0c047fff9d90: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x0c047fff9da0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
=>0x0c047fff9db0: fa fa fd fd fa fa fd fd fa fa[01]fa fa fa 01 fa
0x0c047fff9dc0: fa fa 00 00 fa fa 01 fa fa fa 02 fa fa fa 00 00
0x0c047fff9dd0: fa fa 00 00 fa fa 00 00 fa fa 02 fa fa fa 00 03
0x0c047fff9de0: fa fa 03 fa fa fa 00 fa fa fa 00 00 fa fa 00 00
0x0c047fff9df0: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
0x0c047fff9e00: 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
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
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
==11==ABORTING
We will gladly work with you so you can successfully confirm and reproduce this
issue. Do let us know if you have any feedback surrounding the documentation.
A possible patch for this issue has been attached for your consideration.
Once you have reproduced the issue, we'd appreciate to learn your expected
timeline for an update to be released. With any fix, please attribute the report
to "Google Autofuzz project".
We are also pleased to inform you that your project is eligible for inclusion to
the OSS-Fuzz project, which can provide additional continuous fuzzing, and
encourage you to investigate integration options.
Don't hesitate to let us know if you have any questions!
The POC example OpenEXR has no channels, since the channel list attribute is missing (or rather, the fuzzing has caused the old list to be renamed)
I'm not sure if this is permitted in OpenEXR images. If not, this could be fixed with the header sanitycheck counting the number of channels
Hello OpenEXR team,
As part of our fuzzing efforts at Google, we have identified an issue affecting
OpenEXR (tested with revision * develop 165dcea).
To reproduce, we are attaching a Dockerfile which compiles the project with
LLVM, taking advantage of the sanitizers that it offers. More information about
how to use the attached Dockerfile can be found here:
https://docs.docker.com/engine/reference/builder/
TL;DR instructions:
mkdir project
cp Dockerfile.OpenEXR /path/to/project/Dockerfile
docker build --no-cache /path/to/project
docker run -it image_id_from_docker_build
From another terminal, outside the container:
docker cp /path/to/attached/reproducer running_container_hostname:/fuzzing/reproducer
(reference: https://docs.docker.com/engine/reference/commandline/cp/)
And, back inside the container:
/fuzzing/repro.sh /fuzzing/reproducer
Alternatively, and depending on the bug, you could use gcc, valgrind or other
instrumentation tools to aid in the investigation. The sanitizer error that we
encountered is here:
We will gladly work with you so you can successfully confirm and reproduce this
issue. Do let us know if you have any feedback surrounding the documentation.
A possible patch for this issue has been attached for your consideration.
Once you have reproduced the issue, we'd appreciate to learn your expected
timeline for an update to be released. With any fix, please attribute the report
to "Google Autofuzz project".
We are also pleased to inform you that your project is eligible for inclusion to
the OSS-Fuzz project, which can provide additional continuous fuzzing, and
encourage you to investigate integration options.
Don't hesitate to let us know if you have any questions!
Google AutoFuzz Team
artifacts_72228841.zip
72228841.txt
The text was updated successfully, but these errors were encountered: