google / pik

A new lossy/lossless image format for photos and the internet
MIT License
834 stars 51 forks source link

heap-buffer-overflow in pik::ReplicateValue #15

Closed gy741 closed 7 years ago

gy741 commented 7 years ago

Hi.

I found a heap-buffer-overflow bug in pik.

Please confirm.

Thanks.

Summary: heap-buffer-overflow Browser/OS: Ubuntu 17.04 64bit Steps to reproduce: 1.Download the .POC files. 2.Execute the following command : ./dpik $PoC /dev/null PoC download : PoC or PoC2

=================================================================
==18642==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x625000002100 at pc 0x0000005cff46 bp 0x7fff7fe17d30 sp 0x7fff7fe17d28
WRITE of size 4 at 0x625000002100 thread T0
#0 0x5cff45 in pik::ReplicateValue(pik::HuffmanCode*, int, int, pik::HuffmanCode) /root/gwanyeong/pik/huffman_decode.cc:45:16
#1 0x5cff45 in pik::BuildHuffmanTable(pik::HuffmanCode*, int, unsigned char const*, int, unsigned short*) /root/gwanyeong/pik/huffman_decod e.cc:166
#2 0x5d3409 in pik::HuffmanDecodingData::ReadFromBitStream(pik::BitReader*) /root/gwanyeong/pik/huffman_decode.cc:345:18
#3 0x660cce in pik::DecodePlane(unsigned char const*, unsigned long, int, int, pik::Image<int>*) /root/gwanyeong/pik/opsin_codec.cc:992:8
#4 0x5811c6 in pik::CompressedImage::Decode(int, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const &, pik::PikInfo*) /root/gwanyeong/pik/compressed_image.cc:392:10
#5 0x5afa67 in pik::PikToPixels(pik::DecompressParams const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, pik::Image 3<unsigned char>*, pik::PikInfo*) /root/gwanyeong/pik/pik.cc:543:29
#6 0x50f124 in pik::(anonymous namespace)::Decompress(char const*, char const*) /root/gwanyeong/pik/dpik.cc:58:7
#7 0x50f124 in main /root/gwanyeong/pik/dpik.cc:80
#8 0x7f20fde843f0 in __libc_start_main /build/glibc-mXZSwJ/glibc-2.24/csu/../csu/libc-start.c:291
#9 0x41b759 in _start (/root/gwanyeong/pik/bin/dpik+0x41b759)

0x625000002100 is located 0 bytes to the right of 8192-byte region [0x625000000100,0x625000002100)
allocated by thread T0 here:
#0 0x50a1b0 in operator new(unsigned long) (/root/gwanyeong/pik/bin/dpik+0x50a1b0)
#1 0x660c45 in __gnu_cxx::new_allocator<pik::HuffmanCode>::allocate(unsigned long, void const*) /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/ ../../../../include/c++/6.3.0/ext/new_allocator.h:104:27
#2 0x660c45 in std::allocator_traits<std::allocator<pik::HuffmanCode> >::allocate(std::allocator<pik::HuffmanCode>&, unsigned long) /usr/bi n/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/alloc_traits.h:436
#3 0x660c45 in std::_Vector_base<pik::HuffmanCode, std::allocator<pik::HuffmanCode> >::_M_allocate(unsigned long) /usr/bin/../lib/gcc/x86_6 4-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/stl_vector.h:170
#4 0x660c45 in std::_Vector_base<pik::HuffmanCode, std::allocator<pik::HuffmanCode> >::_M_create_storage(unsigned long) /usr/bin/../lib/gcc /x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/stl_vector.h:185
#5 0x660c45 in std::_Vector_base<pik::HuffmanCode, std::allocator<pik::HuffmanCode> >::_Vector_base(unsigned long, std::allocator<pik::Huff manCode> const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/stl_vector.h:136
#6 0x660c45 in std::vector<pik::HuffmanCode, std::allocator<pik::HuffmanCode> >::vector(unsigned long, std::allocator<pik::HuffmanCode> con st&) /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/stl_vector.h:280
#7 0x660c45 in pik::HuffmanDecodingData::HuffmanDecodingData() /root/gwanyeong/pik/./huffman_decode.h:38
#8 0x660c45 in pik::DecodePlane(unsigned char const*, unsigned long, int, int, pik::Image<int>*) /root/gwanyeong/pik/opsin_codec.cc:991
#9 0x5811c6 in pik::CompressedImage::Decode(int, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const &, pik::PikInfo*) /root/gwanyeong/pik/compressed_image.cc:392:10
#10 0x5afa67 in pik::PikToPixels(pik::DecompressParams const&, std::vector<unsigned char, std::allocator<unsigned char> > const&, pik::Imag e3<unsigned char>*, pik::PikInfo*) /root/gwanyeong/pik/pik.cc:543:29
#11 0x50f124 in pik::(anonymous namespace)::Decompress(char const*, char const*) /root/gwanyeong/pik/dpik.cc:58:7
#12 0x50f124 in main /root/gwanyeong/pik/dpik.cc:80
#13 0x7f20fde843f0 in __libc_start_main /build/glibc-mXZSwJ/glibc-2.24/csu/../csu/libc-start.c:291

SUMMARY: AddressSanitizer: heap-buffer-overflow /root/gwanyeong/pik/huffman_decode.cc:45:16 in pik::ReplicateValue(pik::HuffmanCode*, int, int, pik::HuffmanCode)
Shadow bytes around the buggy address:
0x0c4a7fff83d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c4a7fff83e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c4a7fff83f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c4a7fff8400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c4a7fff8410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c4a7fff8420:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4a7fff8430: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4a7fff8440: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4a7fff8450: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4a7fff8460: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4a7fff8470: 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
==18642==ABORTING
jan-wassenberg commented 7 years ago

Thank you for this one as well! Confirmed, 4-byte write. Out of curiosity, are you running a fuzzer or other tool?

gy741 commented 7 years ago

@jan-wassenberg

Yes.

I am working to make a open source secure.

I know this project is in the initial stages of research.

Is it okay to look for bug?

Thanks.

jyrkialakuijala commented 7 years ago

We will read all bug reports, and we will try to react to bugs like the ones you have reported. Reports like this are helpful.

szabadka commented 7 years ago

This is fixed in the latest version.

attritionorg commented 7 years ago

@szabadka What version was impacted, and what is the latest version? No releases under this project so far.

szabadka commented 7 years ago

I meant the latest commit. We are not planning any releases yet, since the project is still in an initial research stage.