-
Notifications
You must be signed in to change notification settings - Fork 286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
It is a heap-buffer-overflow in Exiv2::Jp2Image::readMetadata (jp2image.cpp:277) #71
Milestone
Comments
D4N
added a commit
to D4N/exiv2
that referenced
this issue
Oct 5, 2017
A heap buffer overflow could occur in memcpy when icc.size_ is larger than data.size_ - pad, as then memcpy would read out of bounds of data. This commit adds a sanity check to iccLength (= icc.size): if it is larger than data.size_ - pad (i.e. an overflow would be caused) an exception is thrown. This fixes Exiv2#71.
Merged
D4N
added a commit
to D4N/exiv2
that referenced
this issue
Oct 6, 2017
A heap buffer overflow could occur in memcpy when icc.size_ is larger than data.size_ - pad, as then memcpy would read out of bounds of data. This commit adds a sanity check to iccLength (= icc.size_): if it is larger than data.size_ - pad (i.e. an overflow would be caused) an exception is thrown. This fixes Exiv2#71.
D4N
added a commit
to D4N/exiv2
that referenced
this issue
Oct 10, 2017
A heap buffer overflow could occur in memcpy when icc.size_ is larger than data.size_ - pad, as then memcpy would read out of bounds of data. This commit adds a sanity check to iccLength (= icc.size_): if it is larger than data.size_ - pad (i.e. an overflow would be caused) an exception is thrown. This fixes Exiv2#71.
D4N
added a commit
to D4N/exiv2
that referenced
this issue
Oct 15, 2017
A heap buffer overflow could occur in memcpy when icc.size_ is larger than data.size_ - pad, as then memcpy would read out of bounds of data. This commit adds a sanity check to iccLength (= icc.size_): if it is larger than data.size_ - pad (i.e. an overflow would be caused) an exception is thrown. This fixes Exiv2#71.
FTR this is known as CVE-2017-14860 (as mentioned in commit messages). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm forwarding a security vulnerability reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1494776
The file used to reproduce the issue is here:
https://bugzilla.redhat.com/attachment.cgi?id=1329790
Here's a copy of the report:
Liu Zhu 2017-09-22 21:39:03 EDT
Created attachment 1329790 [details]
PoC File
./exiv2 003-heap-buffer-over
==34506==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61200000be69 at pc 0x7fa4854c3935 bp 0x7ffdf8967ef0 sp 0x7ffdf8967698
READ of size 808464432 at 0x61200000be69 thread T0
#0 0x7fa4854c3934 in __asan_memcpy (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x8c934)
#1 0x7fa484d5f07c in Exiv2::Jp2Image::readMetadata() /root/fuzzing/exiv2-trunk/src/jp2image.cpp:277
#2 0x43ab02 in Action::Print::printSummary() /root/fuzzing/exiv2-trunk/src/actions.cpp:289
#3 0x43a1af in Action::Print::run(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&) /root/fuzzing/exiv2-trunk/src/actions.cpp:244
#4 0x422129 in main /root/fuzzing/exiv2-trunk/src/exiv2.cpp:170
#5 0x7fa4840a382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#6 0x421af8 in _start (/usr/local/exiv2_ASAN/bin/exiv2+0x421af8)
0x61200000be69 is located 0 bytes to the right of 297-byte region [0x61200000bd40,0x61200000be69)
allocated by thread T0 here:
#0 0x7fa4854d06b2 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x996b2)
#1 0x454805 in Exiv2::DataBuf::DataBuf(long) /root/fuzzing/exiv2-trunk/include/exiv2/types.hpp:204
#2 0x7fa484d5ef9a in Exiv2::Jp2Image::readMetadata() /root/fuzzing/exiv2-trunk/src/jp2image.cpp:273
#3 0x43ab02 in Action::Print::printSummary() /root/fuzzing/exiv2-trunk/src/actions.cpp:289
#4 0x43a1af in Action::Print::run(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&) /root/fuzzing/exiv2-trunk/src/actions.cpp:244
#5 0x422129 in main /root/fuzzing/exiv2-trunk/src/exiv2.cpp:170
#6 0x7fa4840a382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 __asan_memcpy
Shadow bytes around the buggy address:
0x0c247fff9770: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c247fff9780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c247fff9790: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c247fff97a0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c247fff97b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c247fff97c0: 00 00 00 00 00 00 00 00 00 00 00 00 00[01]fa fa
0x0c247fff97d0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c247fff97e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c247fff97f0: 00 00 00 00 00 00 00 00 00 00 00 01 fa fa fa fa
0x0c247fff9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c247fff9810: 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
==34506==ABORTING
[reply] [−] Comment 2 Liu Zhu 2017-09-23 01:15:31 EDT
./exiv2 -V
exiv2 0.26 001a00 (64 bit build)
Copyright (C) 2004-2017 Andreas Huggel.
The text was updated successfully, but these errors were encountered: