CVE-2018-4868: LargeMmapAllocator error in sanitizer_posix.cc #202
Comments
|
This issue has been assigned CVE-2018-4868 |
|
Thanks for your report. I am unfortunately unable to reproduce the
issue. I have tried building exiv2 on master, 0.26 (with security fixes
and without) and all I get with your reproducer is:
build/bin/exiv2 exiv2-memorymmap-error
Exiv2 exception in print action for file exiv2-memorymmap-error:
exiv2-memorymmap-error: The file contains data of an unknown image type
Could it be that you accidentally uploaded a wrong file?
If not, which commit of exiv2 did you build and on which platform &
compiler? Did you use ulimit or cgoups to limit the memory usage?
Thanks,
Dan
xcainiao <notifications@github.com> writes:
… version: exiv2 0.26 001a00 (64 bit build)
./exiv2 ./poc
### when memory not enough output this error
found by afl
```
==103308==ERROR: AddressSanitizer failed to allocate 0xff803000 (4286590976) bytes of LargeMmapAllocator (errno: 12)
==103308==Process memory map follows:
0x000000400000-0x000000e49000 /home/fuzz/fuzz/exiv2/bin/exiv2
0x000001049000-0x00000104a000 /home/fuzz/fuzz/exiv2/bin/exiv2
0x00000104a000-0x00000113a000 /home/fuzz/fuzz/exiv2/bin/exiv2
0x00000113a000-0x000001159000
0x00007fff7000-0x00008fff7000
0x00008fff7000-0x02008fff7000
0x02008fff7000-0x10007fff8000
0x600000000000-0x602000000000
0x602000000000-0x602000010000
0x602000010000-0x603000000000
0x603000000000-0x603000010000
0x603000010000-0x604000000000
0x604000000000-0x604000010000
0x604000010000-0x606000000000
0x606000000000-0x606000010000
0x606000010000-0x607000000000
0x607000000000-0x607000010000
0x607000010000-0x608000000000
0x608000000000-0x608000010000
0x608000010000-0x60b000000000
0x60b000000000-0x60b000010000
0x60b000010000-0x60c000000000
0x60c000000000-0x60c000010000
0x60c000010000-0x60f000000000
0x60f000000000-0x60f000010000
0x60f000010000-0x610000000000
0x610000000000-0x610000010000
0x610000010000-0x611000000000
0x611000000000-0x611000010000
0x611000010000-0x612000000000
0x612000000000-0x612000010000
0x612000010000-0x614000000000
0x614000000000-0x614000020000
0x614000020000-0x616000000000
0x616000000000-0x616000020000
0x616000020000-0x618000000000
0x618000000000-0x618000020000
0x618000020000-0x619000000000
0x619000000000-0x619000020000
0x619000020000-0x621000000000
0x621000000000-0x621000020000
0x621000020000-0x624000000000
0x624000000000-0x624000020000
0x624000020000-0x631000000000
0x631000000000-0x631000030000
0x631000030000-0x640000000000
0x640000000000-0x640000003000
0x7f08fb328000-0x7f08fb600000 /usr/lib/locale/locale-archive
0x7f08fb600000-0x7f08fb700000
0x7f08fb800000-0x7f08fb900000
0x7f08fb9aa000-0x7f08fdcfc000
0x7f08fdcfc000-0x7f08fdcff000 /lib/x86_64-linux-gnu/libdl-2.23.so
0x7f08fdcff000-0x7f08fdefe000 /lib/x86_64-linux-gnu/libdl-2.23.so
0x7f08fdefe000-0x7f08fdeff000 /lib/x86_64-linux-gnu/libdl-2.23.so
0x7f08fdeff000-0x7f08fdf00000 /lib/x86_64-linux-gnu/libdl-2.23.so
0x7f08fdf00000-0x7f08fe0c0000 /lib/x86_64-linux-gnu/libc-2.23.so
0x7f08fe0c0000-0x7f08fe2c0000 /lib/x86_64-linux-gnu/libc-2.23.so
0x7f08fe2c0000-0x7f08fe2c4000 /lib/x86_64-linux-gnu/libc-2.23.so
0x7f08fe2c4000-0x7f08fe2c6000 /lib/x86_64-linux-gnu/libc-2.23.so
0x7f08fe2c6000-0x7f08fe2ca000
0x7f08fe2ca000-0x7f08fe2e0000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x7f08fe2e0000-0x7f08fe4df000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x7f08fe4df000-0x7f08fe4e0000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x7f08fe4e0000-0x7f08fe5e8000 /lib/x86_64-linux-gnu/libm-2.23.so
0x7f08fe5e8000-0x7f08fe7e7000 /lib/x86_64-linux-gnu/libm-2.23.so
0x7f08fe7e7000-0x7f08fe7e8000 /lib/x86_64-linux-gnu/libm-2.23.so
0x7f08fe7e8000-0x7f08fe7e9000 /lib/x86_64-linux-gnu/libm-2.23.so
0x7f08fe7e9000-0x7f08fe95b000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
0x7f08fe95b000-0x7f08feb5b000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
0x7f08feb5b000-0x7f08feb65000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
0x7f08feb65000-0x7f08feb67000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
0x7f08feb67000-0x7f08feb6b000
0x7f08feb6b000-0x7f08feb83000 /lib/x86_64-linux-gnu/libpthread-2.23.so
0x7f08feb83000-0x7f08fed82000 /lib/x86_64-linux-gnu/libpthread-2.23.so
0x7f08fed82000-0x7f08fed83000 /lib/x86_64-linux-gnu/libpthread-2.23.so
0x7f08fed83000-0x7f08fed84000 /lib/x86_64-linux-gnu/libpthread-2.23.so
0x7f08fed84000-0x7f08fed88000
0x7f08fed88000-0x7f08fedae000 /lib/x86_64-linux-gnu/libexpat.so.1.6.0
0x7f08fedae000-0x7f08fefae000 /lib/x86_64-linux-gnu/libexpat.so.1.6.0
0x7f08fefae000-0x7f08fefb0000 /lib/x86_64-linux-gnu/libexpat.so.1.6.0
0x7f08fefb0000-0x7f08fefb1000 /lib/x86_64-linux-gnu/libexpat.so.1.6.0
0x7f08fefb1000-0x7f08fefca000 /lib/x86_64-linux-gnu/libz.so.1.2.8
0x7f08fefca000-0x7f08ff1c9000 /lib/x86_64-linux-gnu/libz.so.1.2.8
0x7f08ff1c9000-0x7f08ff1ca000 /lib/x86_64-linux-gnu/libz.so.1.2.8
0x7f08ff1ca000-0x7f08ff1cb000 /lib/x86_64-linux-gnu/libz.so.1.2.8
0x7f08ff1cb000-0x7f08ff2bf000 /usr/lib/x86_64-linux-gnu/libasan.so.2.0.0
0x7f08ff2bf000-0x7f08ff4bf000 /usr/lib/x86_64-linux-gnu/libasan.so.2.0.0
0x7f08ff4bf000-0x7f08ff4c2000 /usr/lib/x86_64-linux-gnu/libasan.so.2.0.0
0x7f08ff4c2000-0x7f08ff4c3000 /usr/lib/x86_64-linux-gnu/libasan.so.2.0.0
0x7f08ff4c3000-0x7f0900138000
0x7f0900138000-0x7f090015e000 /lib/x86_64-linux-gnu/ld-2.23.so
0x7f09002c3000-0x7f0900352000
0x7f0900352000-0x7f090035d000
0x7f090035d000-0x7f090035e000 /lib/x86_64-linux-gnu/ld-2.23.so
0x7f090035e000-0x7f090035f000 /lib/x86_64-linux-gnu/ld-2.23.so
0x7f090035f000-0x7f0900360000
0x7ffd1d376000-0x7ffd1d397000 [stack]
0x7ffd1d3a9000-0x7ffd1d3ab000 [vvar]
0x7ffd1d3ab000-0x7ffd1d3ad000 [vdso]
0xffffffffff600000-0xffffffffff601000 [vsyscall]
==103308==End of process memory map.
==103308==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/sanitizer_common/sanitizer_posix.cc:121 "(("unable to mmap" && 0)) != (0)" (0x0, 0x0)
#0 0x7f08ff26b631 (/usr/lib/x86_64-linux-gnu/libasan.so.2+0xa0631)
#1 0x7f08ff270613 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0xa5613)
#2 0x7f08ff278641 (/usr/lib/x86_64-linux-gnu/libasan.so.2+0xad641)
#3 0x7f08ff1edc0c (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x22c0c)
#4 0x7f08ff26467e in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9967e)
#5 0x67831a in Exiv2::DataBuf::DataBuf(long) ../include/exiv2/types.hpp:206
#6 0x67831a in Exiv2::Jp2Image::readMetadata() /home/fuzz/fuzz/exiv2/src/jp2image.cpp:271
#7 0x4f572c in Action::Print::printSummary() /home/fuzz/fuzz/exiv2/src/actions.cpp:296
#8 0x4f9dc7 in Action::Print::run(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/fuzz/fuzz/exiv2/src/actions.cpp:242
#9 0x40a18c in main /home/fuzz/fuzz/exiv2/src/exiv2.cpp:166
#10 0x7f08fdf2082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#11 0x490c38 in _start (/home/fuzz/fuzz/exiv2/bin/exiv2+0x490c38)
```
testcase: https://github.com/xcainiao/poc/blob/master/exiv2-memorymmap-error
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#202
|
|
Thanks for your reply. |
|
I have build exiv2 master in a docker container running ubuntu 16.04
with ASAN and ran it against your reproducer. However, I got the same
result as previously.
Also, your reproducer does not result in a huge memory allocation. I
tried to limit the amount of RAM it gets with cgroups on my devel
machine (running Fedora 26) and the process gets killed when you set the
memory limit below 30 MB (which is alot, but not enough to exhaust 1 GB).
Could you provide me with a way how to reproduce your issue? E.g. a
vagrant recipe for a VM where it is reproduced with exact build
instructions? I can't fix an issue, that I cannot reproduce.
@carnil Were you able to reproduce the issue? If yes, how?
xcainiao <notifications@github.com> writes:
… Thanks for your reply.
I use gcc 5.40 building exiv2 on master. Platform is ubuntu 16.06 x86_64
My computer only 1 cpu 1G memory. Maybe that's the problem
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#202 (comment)
|
|
I reproduce it again. I don't know if this a bug or not, I found this by fuzz.
|
|
Could you please give more details how you build exiv2? Did you use any special c++ flags? Which commit did you build? It is not that I don't believe you, I just cannot reproduce the issue (running it twice doesn't help). Could you please verify that you uploaded the correct file? When I run |
|
compiler: git log I use the uploaded file , I can reproduce it again. |
|
After trying to reproduce this with the specified flags, I wanted to look up what Also, please keep in mind that ASAN increases the memory usage of your application by a substantial amount and coupled with the tiny amount of RAM your machine has this is not too surprising. Could you check with Unless you have any further reasons why you consider this a bug in exiv2, I am going to close this as "Not a bug". If you think that exiv2's memory usage is too high, then please feel free to open a new issue with a title that will not get us a new CVE right away before we were able to check this. |
|
@xcainiao Anything from new your side? If you want to continue fuzzing exiv2, then I would recommend using a more beefy machine and to also optimize the build, as cmake will afaik by default not add -O2/-O3. Also, you could try to run with @carnil Could you try reproducing the issue? If not, how can I get the CVE revoked? I have seen that it is marked as disputed. |
|
@xcainiao I have to apologize, I just rechecked your reproducer and I accidentally just used wget on the link you provided not realizing that that downloaded the github webpage and not the reproducer... I am terribly sorry for that stupidity on my side. With your file I can reproduce the issue, exiv2 goes totally insane and allocates memory like crazy. @carnil Forget what I said, the CVE is a thing. |
|
Ok, I have found the issue. The problem is that the jpeg parser extracts the length of a data segment that it wants to read from the input file and performs no check whether that value is sane. Well, AFL created an input file where that value has nearly the maximum size of a 32 bit int which is more or less directly fed to I have created a fix for that and will submit a PR soon. |
When parsing a subBox that is a ColorHeader, a length is extracted from the input file and fed directly into DataBuf() (which calls malloc). A crafted input file can provide arbitrarily (up to max(uint32_t)-8) large values and result in excessive memory allocation. This commit adds a check for the new size of DataBuf so that it is not larger than the remaining size of the file. This fixes Exiv2#202 aka CVE-2018-4868
|
@D4N In the future if you need to request changes to CVEs or need new ones you can contact MITRE via: https://cveform.mitre.org/ |
When parsing a subBox that is a ColorHeader, a length is extracted from the input file and fed directly into DataBuf() (which calls malloc). A crafted input file can provide arbitrarily (up to max(uint32_t)-8) large values and result in excessive memory allocation. This commit adds a check for the new size of DataBuf so that it is not larger than the remaining size of the file. This fixes Exiv2#202 aka CVE-2018-4868
When parsing a subBox that is a ColorHeader, a length is extracted from the input file and fed directly into DataBuf() (which calls malloc). A crafted input file can provide arbitrarily (up to max(uint32_t)-8) large values and result in excessive memory allocation. This commit adds a check for the new size of DataBuf so that it is not larger than the remaining size of the file. This fixes Exiv2#202 aka CVE-2018-4868
When parsing a subBox that is a ColorHeader, a length is extracted from the input file and fed directly into DataBuf() (which calls malloc). A crafted input file can provide arbitrarily (up to max(uint32_t)-8) large values and result in excessive memory allocation. This commit adds a check for the new size of DataBuf so that it is not larger than the remaining size of the file. This fixes Exiv2#202 aka CVE-2018-4868
D4N
changed the title
When parsing a subBox that is a ColorHeader, a length is extracted from the input file and fed directly into DataBuf() (which calls malloc). A crafted input file can provide arbitrarily (up to max(uint32_t)-8) large values and result in excessive memory allocation. This commit adds a check for the new size of DataBuf so that it is not larger than the remaining size of the file. This fixes Exiv2#202 aka CVE-2018-4868
When parsing a subBox that is a ColorHeader, a length is extracted from the input file and fed directly into DataBuf() (which calls malloc). A crafted input file can provide arbitrarily (up to max(uint32_t)-8) large values and result in excessive memory allocation. This commit adds a check for the new size of DataBuf so that it is not larger than the remaining size of the file. This fixes Exiv2#202 aka CVE-2018-4868
version: exiv2 0.26 001a00 (64 bit build)
./exiv2 ./poc
when memory not enough output this error
found by afl
testcase: https://github.com/xcainiao/poc/blob/master/exiv2-memorymmap-error
found : topsecLab
The text was updated successfully, but these errors were encountered: