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

CVE-2018-4868: LargeMmapAllocator error in sanitizer_posix.cc #202

Closed
xcainiao opened this Issue Jan 1, 2018 · 12 comments

Comments

Projects
None yet
4 participants
@xcainiao

xcainiao commented Jan 1, 2018

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
found : topsecLab

@carnil

This comment has been minimized.

Show comment
Hide comment
@carnil

carnil Jan 5, 2018

This issue has been assigned CVE-2018-4868

carnil commented Jan 5, 2018

This issue has been assigned CVE-2018-4868

@D4N

This comment has been minimized.

Show comment
Hide comment
@D4N

D4N Jan 6, 2018

Contributor
Contributor

D4N commented Jan 6, 2018

@xcainiao

This comment has been minimized.

Show comment
Hide comment
@xcainiao

xcainiao Jan 6, 2018

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

xcainiao commented Jan 6, 2018

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

@D4N

This comment has been minimized.

Show comment
Hide comment
@D4N

D4N Jan 6, 2018

Contributor
Contributor

D4N commented Jan 6, 2018

@xcainiao

This comment has been minimized.

Show comment
Hide comment
@xcainiao

xcainiao Jan 6, 2018

I reproduce it again.
I ran this command twice ./exiv2 ./poc at the same time. the latter reproduce it.

I don't know if this a bug or not, I found this by fuzz.

xcainiao commented Jan 6, 2018

I reproduce it again.
I ran this command twice ./exiv2 ./poc at the same time. the latter reproduce it.

I don't know if this a bug or not, I found this by fuzz.

@D4N

This comment has been minimized.

Show comment
Hide comment
@D4N

D4N Jan 6, 2018

Contributor

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 exiv2 exiv2-memorymmap-error, I get a thrown exception and not the output from the left side your screenshot.

Contributor

D4N commented Jan 6, 2018

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 exiv2 exiv2-memorymmap-error, I get a thrown exception and not the output from the left side your screenshot.

@xcainiao

This comment has been minimized.

Show comment
Hide comment
@xcainiao

xcainiao Jan 6, 2018

compiler:

CC=gcc CXX=g++ CFLAGS="-fsanitize=address" CXXFLAGS="-fsanitize=address" LDFLAGS="-fsanitize=address" cmake .
make

git log

commit 00f32316b2aa9664194fbc4fae11ee54808ebcf6
Author: Luis Díaz Más <piponazo@gmail.com>
Date:   Mon Dec 18 19:27:42 2017 +0100

    Add missing header

I use the uploaded file , I can reproduce it again.

xcainiao commented Jan 6, 2018

compiler:

CC=gcc CXX=g++ CFLAGS="-fsanitize=address" CXXFLAGS="-fsanitize=address" LDFLAGS="-fsanitize=address" cmake .
make

git log

commit 00f32316b2aa9664194fbc4fae11ee54808ebcf6
Author: Luis Díaz Más <piponazo@gmail.com>
Date:   Mon Dec 18 19:27:42 2017 +0100

    Add missing header

I use the uploaded file , I can reproduce it again.

@D4N

This comment has been minimized.

Show comment
Hide comment
@D4N

D4N Jan 6, 2018

Contributor

After trying to reproduce this with the specified flags, I wanted to look up what LargeMmapAllocator is. Turns out, it is not from the exiv2 code base (I am not too familiar with it, I just joined recently) but it's from ASAN. And it basically just tells you: you are out of memory.

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 free or top how much RAM you actually have usable (and if you have a swap)?

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.

Contributor

D4N commented Jan 6, 2018

After trying to reproduce this with the specified flags, I wanted to look up what LargeMmapAllocator is. Turns out, it is not from the exiv2 code base (I am not too familiar with it, I just joined recently) but it's from ASAN. And it basically just tells you: you are out of memory.

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 free or top how much RAM you actually have usable (and if you have a swap)?

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.

@D4N

This comment has been minimized.

Show comment
Hide comment
@D4N

D4N Jan 8, 2018

Contributor

@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 -march=native -mtune=native which will make gcc optimize more aggressively and/or try afl-clang-fast. And you might want to run the fuzzer in a VM on your ordinary machine (which seems to run Windows), as it could give you more performance than a tiny Linux box.

@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.

Contributor

D4N commented Jan 8, 2018

@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 -march=native -mtune=native which will make gcc optimize more aggressively and/or try afl-clang-fast. And you might want to run the fuzzer in a VM on your ordinary machine (which seems to run Windows), as it could give you more performance than a tiny Linux box.

@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.

@D4N

This comment has been minimized.

Show comment
Hide comment
@D4N

D4N Jan 9, 2018

Contributor

@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.

Contributor

D4N commented Jan 9, 2018

@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.

@D4N

This comment has been minimized.

Show comment
Hide comment
@D4N

D4N Jan 9, 2018

Contributor

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 malloc.

I have created a fix for that and will submit a PR soon.

Contributor

D4N commented Jan 9, 2018

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 malloc.

I have created a fix for that and will submit a PR soon.

D4N added a commit to D4N/exiv2 that referenced this issue Jan 9, 2018

Add check for DataBuf.size_ in Jp2Image::readMetadata()
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 D4N referenced this issue Jan 9, 2018

Merged

Fix CVE-2018-4868 #207

@fgeek

This comment has been minimized.

Show comment
Hide comment
@fgeek

fgeek Jan 10, 2018

Collaborator

@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/

Collaborator

fgeek commented Jan 10, 2018

@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/

D4N added a commit to D4N/exiv2 that referenced this issue Jan 13, 2018

Add check for DataBuf.size_ in Jp2Image::readMetadata()
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 added a commit to D4N/exiv2 that referenced this issue Jan 27, 2018

Add check for DataBuf.size_ in Jp2Image::readMetadata()
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 added a commit to D4N/exiv2 that referenced this issue Feb 1, 2018

Add check for DataBuf.size_ in Jp2Image::readMetadata()
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 D4N closed this in #207 Feb 1, 2018

@D4N D4N changed the title from LargeMmapAllocator error in sanitizer_posix.cc to CVE-2018-4868: LargeMmapAllocator error in sanitizer_posix.cc Mar 21, 2018

a17r added a commit to a17r/exiv2 that referenced this issue Apr 25, 2018

Add check for DataBuf.size_ in Jp2Image::readMetadata()
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

a17r added a commit to a17r/exiv2 that referenced this issue May 9, 2018

Add check for DataBuf.size_ in Jp2Image::readMetadata()
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment