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-2017-18005: NULL Pointer Dereference while extracting metadata of a malformed tiff #168

Closed
kirit1193 opened this Issue Nov 18, 2017 · 10 comments

Comments

Projects
None yet
3 participants
@kirit1193

kirit1193 commented Nov 18, 2017

There's a NULL Pointer Dereference occurring during the metadata extraction from a malformed tiff file.
This can be triggered by running ./exiv2 -v pr -P EIXxgklnycsvth %file% on the test-case, exiv2-nullpointerderef.zip.

The hexdump of the test-case is:

0000000 4949 002a 0050 0000 3030 3030 3030 3030
0000010 3030 3030 3030 3030 3030 3030 3030 3030
*
0000050 000f 0117 0006 0030 0000 3030 3030 3030
0000060 0003 0030 0000 3030 3030 3030 0002 0030
0000070 0000 3030 3030 3030 000b 0030 0000 3030
0000080 3030 3030 000b 0030 0000 3030 3030 3030
0000090 000b 0030 0000 3030 3030 3030 000b 0030
00000a0 0000 3030 3030 3030 0003 0030 0000 3030
00000b0 3030 3030 000b 0030 0000 3030 3030 3030
00000c0 000b 0030 0000 3030 3030 3030 000a 0000
00000d0 0000 3030 3030 3030 000b 0030 0000 3030
00000e0 3030 3030 000b 0030 0000 3030 3030 3030
00000f0 0003 0030 0000 3030 3030 3030 000c 0000
0000100 0000 3030 3030 0000 0000
0000109

The relevant ASAN output is:

==4728==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x557dc0c47468 bp 0x7fff7558bbb0 sp 0x7fff7558bbb0 T0)
==4728==The signal is caused by a READ memory access.
==4728==Hint: address points to the zero page.
    #0 0x557dc0c47467 in Exiv2::DataValue::toLong(long) const /home/ksg/exiv2/src/value.cpp:250
    #1 0x557dc0688058 in Action::Print::printMetadatum(Exiv2::Metadatum const&, Exiv2::Image const*) /home/ksg/exiv2/src/actions.cpp:731
    #2 0x557dc068bad2 in Action::Print::printMetadata(Exiv2::Image const*) /home/ksg/exiv2/src/actions.cpp:552
    #3 0x557dc068d61a in Action::Print::printList() /home/ksg/exiv2/src/actions.cpp:541
    #4 0x557dc06b8fff in Action::Print::run(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/ksg/exiv2/src/actions.cpp:245
    #5 0x557dc05983a6 in main /home/ksg/exiv2/src/exiv2.cpp:170
    #6 0x7f2987d301c0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x211c0)
    #7 0x557dc0621b59 in _start (/home/ksg/testbench/exiv2_asan+0x22bb59)

It looks like the NULL-Pointer Dereference is being triggered by a 0 value which is being used in the toLong function in the value of n, which is being dereferenced in

return value_[n];

This is indicated by the GDB backtrace:

Program received signal SIGSEGV, Segmentation fault.
Exiv2::DataValue::toLong (this=0x55555609d860, n=0) at value.cpp:250
250             return value_[n];
(gdb) bt
#0  Exiv2::DataValue::toLong (this=0x55555609d860, n=0) at value.cpp:250
#1  0x000055555561d5f1 in Action::Print::printMetadatum (this=this@entry=0x555556092e70, md=..., pImage=pImage@entry=0x555556093530) at actions.cpp:731
#2  0x000055555561ecf0 in Action::Print::printMetadata (this=this@entry=0x555556092e70, image=image@entry=0x555556093530) at actions.cpp:552
#3  0x000055555561f2fb in Action::Print::printList (this=this@entry=0x555556092e70) at actions.cpp:541
#4  0x00005555556313c8 in Action::Print::run (this=0x555556092e70, path="/home/ksg/exif-crashes/npd") at actions.cpp:245
#5  0x00005555555bc339 in main (argc=<optimized out>, argv=<optimized out>) at exiv2.cpp:170

Debug info:

Exiv2 version 0.26 001a00 (64 bit build)
Compiler: gcc 7.2, clang 4.0.1-6
OS: Ubuntu 17.10

@D4N

This comment has been minimized.

Show comment
Hide comment
@D4N

D4N Nov 19, 2017

Contributor

Thanks for the report. However I can neither reproduce this with the master branch or with the 0.26 branch (that is version 0.26 + backported security fixes). Could you try your reproducer against those two branches and report back if the issue is resolved?

Contributor

D4N commented Nov 19, 2017

Thanks for the report. However I can neither reproduce this with the master branch or with the 0.26 branch (that is version 0.26 + backported security fixes). Could you try your reproducer against those two branches and report back if the issue is resolved?

@kirit1193

This comment has been minimized.

Show comment
Hide comment
@kirit1193

kirit1193 Nov 20, 2017

I found this issue on the master branch, git-cloned from this repository.
Are you not getting any error while running exiv2 against this reproducer? I just confirmed by running it again on the attached file after unzipping it.

kirit1193 commented Nov 20, 2017

I found this issue on the master branch, git-cloned from this repository.
Are you not getting any error while running exiv2 against this reproducer? I just confirmed by running it again on the attached file after unzipping it.

@D4N

This comment has been minimized.

Show comment
Hide comment
@D4N

D4N Nov 20, 2017

Contributor
Contributor

D4N commented Nov 20, 2017

@D4N D4N self-assigned this Nov 20, 2017

@kirit1193

This comment has been minimized.

Show comment
Hide comment
@kirit1193

kirit1193 Nov 20, 2017

Very interesting, let me check out the crash with exiv2json.
Do let me know if I can help you further with any triage.

kirit1193 commented Nov 20, 2017

Very interesting, let me check out the crash with exiv2json.
Do let me know if I can help you further with any triage.

@D4N

This comment has been minimized.

Show comment
Hide comment
@D4N

D4N Nov 20, 2017

Contributor

At least with exiv2json the culprit is probably the function which reads in the image metadata or one of the following functions, as the crash occurs due to a std::vector with zero capacity being dereferenced unsafely. This will probably be trickier than I was hoping.

Contributor

D4N commented Nov 20, 2017

At least with exiv2json the culprit is probably the function which reads in the image metadata or one of the following functions, as the crash occurs due to a std::vector with zero capacity being dereferenced unsafely. This will probably be trickier than I was hoping.

@kirit1193

This comment has been minimized.

Show comment
Hide comment
@kirit1193

kirit1193 Dec 16, 2017

Hey was this fixed?

kirit1193 commented Dec 16, 2017

Hey was this fixed?

@D4N

This comment has been minimized.

Show comment
Hide comment
@D4N

D4N Dec 16, 2017

Contributor

No, sorry not yet. I didn't have the time to debug this further, as I am currently working on some improvements under the hood. I hope to take a look at this issue soon, but I can't promise a certain date.

If you think that this is more important (e.g. because you can actively exploit this), please tell me (in the case of an active exploit, please do so via email).

Contributor

D4N commented Dec 16, 2017

No, sorry not yet. I didn't have the time to debug this further, as I am currently working on some improvements under the hood. I hope to take a look at this issue soon, but I can't promise a certain date.

If you think that this is more important (e.g. because you can actively exploit this), please tell me (in the case of an active exploit, please do so via email).

@carnil

This comment has been minimized.

Show comment
Hide comment
@carnil

carnil Jan 1, 2018

This issue has been assigned CVE-2017-18005

carnil commented Jan 1, 2018

This issue has been assigned CVE-2017-18005

@D4N

This comment has been minimized.

Show comment
Hide comment
@D4N

D4N Jan 1, 2018

Contributor

FYI this will be fixed by #199

Contributor

D4N commented Jan 1, 2018

FYI this will be fixed by #199

@7c6f434c 7c6f434c referenced this issue Jan 19, 2018

Closed

Vulnerability Roundup 33 (master) #34054

0 of 2 tasks complete

@D4N D4N changed the title from NULL Pointer Dereference while extracting metadata of a malformed tiff to CVE-2017-18005: NULL Pointer Dereference while extracting metadata of a malformed tiff Feb 13, 2018

@D4N

This comment has been minimized.

Show comment
Hide comment
@D4N

D4N Mar 21, 2018

Contributor

#199 has been merged

Contributor

D4N commented Mar 21, 2018

#199 has been merged

@D4N D4N closed this Mar 21, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment