Skip to content
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

heap overflow in mp4v2::impl::MP4Integer32Property::Read #20

Closed
jinyu00 opened this issue Jul 18, 2018 · 4 comments
Closed

heap overflow in mp4v2::impl::MP4Integer32Property::Read #20

jinyu00 opened this issue Jul 18, 2018 · 4 comments

Comments

@jinyu00
Copy link

jinyu00 commented Jul 18, 2018

When open a crafted mp4 file, The program could tigger heap overflow, this could overwrite vtable ptr. and then enter mp4v2::impl::MP4TableProperty::ReadEntry ,and use the vtable , then program crash.

The gdb output is blow:

Program received signal SIGSEGV, Segmentation fault.

[----------------------------------registers-----------------------------------]
RAX: 0x714f38 --> 0x714eb0 --> 0xdeadbeef 
RBX: 0x2 
RCX: 0xdeadbeef 
RDX: 0x9 ('\t')
RSI: 0x707130 --> 0x706c70 --> 0x49bf10 --> 0x453a80 (<mp4v2::platform::io::File::~File()>:	push   rbp)
RDI: 0x714eb0 --> 0xdeadbeef 
RBP: 0x714e10 --> 0x497010 --> 0x4354a0 (<mp4v2::impl::MP4TableProperty::~MP4TableProperty()>:	push   r12)
RSP: 0x7fffffffd3e0 --> 0xa ('\n')
RIP: 0x435569 (<mp4v2::impl::MP4TableProperty::ReadEntry(mp4v2::impl::MP4File&, unsigned int)+57>:	call   QWORD PTR [rcx+0x30])
R8 : 0x0 
R9 : 0x0 
R10: 0x22 ('"')
R11: 0xf736c301 
R12: 0x714e38 --> 0x400000004 
R13: 0x9 ('\t')
R14: 0x707130 --> 0x706c70 --> 0x49bf10 --> 0x453a80 (<mp4v2::platform::io::File::~File()>:	push   rbp)
R15: 0x714e38 --> 0x400000004
EFLAGS: 0x10206 (carry PARITY adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x435560 <mp4v2::impl::MP4TableProperty::ReadEntry(mp4v2::impl::MP4File&, unsigned int)+48>:	mov    edx,r13d
   0x435563 <mp4v2::impl::MP4TableProperty::ReadEntry(mp4v2::impl::MP4File&, unsigned int)+51>:	mov    rsi,r14
   0x435566 <mp4v2::impl::MP4TableProperty::ReadEntry(mp4v2::impl::MP4File&, unsigned int)+54>:	mov    rcx,QWORD PTR [rdi]
=> 0x435569 <mp4v2::impl::MP4TableProperty::ReadEntry(mp4v2::impl::MP4File&, unsigned int)+57>:	call   QWORD PTR [rcx+0x30]
   0x43556c <mp4v2::impl::MP4TableProperty::ReadEntry(mp4v2::impl::MP4File&, unsigned int)+60>:	cmp    DWORD PTR [rbp+0x28],ebx
   0x43556f <mp4v2::impl::MP4TableProperty::ReadEntry(mp4v2::impl::MP4File&, unsigned int)+63>:	ja     0x435550 <mp4v2::impl::MP4TableProperty::ReadEntry(mp4v2::impl::MP4File&, unsigned int)+32>
   0x435571 <mp4v2::impl::MP4TableProperty::ReadEntry(mp4v2::impl::MP4File&, unsigned int)+65>:	pop    rbx
   0x435572 <mp4v2::impl::MP4TableProperty::ReadEntry(mp4v2::impl::MP4File&, unsigned int)+66>:	pop    rbp

As you can see , program crash in

call   QWORD PTR [rcx+0x30]

now $rcx = 0xdeadbeef , which is our control.

fuzz log

{"type":"crash","sub_type":"heapoverflow","pc":"0x000000000043c38f","func_of_pc":"_ZN5mp4v24impl20MP4Integer32Property4ReadERNS0_7MP4FileEj","module_of_pc":"mp4file","module_base_of_pc":"0x0000000000400000","exception_code":"0xB","access_memory":"0x00007f1066e24000","backtrace":"0.mp4file.0x3c38f _ZN5mp4v24impl20MP4Integer32Property4ReadERNS0_7MP4FileEj
","extra_info":"[returnaddr=mp4file.0x3BD0C, addr=0x00007f1066e23ffc,0x4]"}
@jinyu00
Copy link
Author

jinyu00 commented Jul 18, 2018

poc:

https://gitee.com/hac425/fuzz_data/blob/master/mp4v2_vtable_poc.mp4

@nluedtke
Copy link

This was assigned CVE-2018-14446.

@StilgarISCA
Copy link
Contributor

Thank you for reporting this! We are looking into it.

@StilgarISCA
Copy link
Contributor

StilgarISCA commented Mar 19, 2019

It has come to our attention that there are a number of CVE's assigned to mp4v2. All of these reference a CPE of a:techsmith:mp4v2. I believe this was an educated guess by NIST as to the owner of the mp4v2 code. After all, if you search for mp4v2 this repository shows up in the results first.

@jinyu00 was the only one to have logged an issue against our fork specifically.

I want to make it clear to the community that this is repository is a fork of https://code.google.com/archive/p/mp4v2/. We have made some changes on top of it for our own purposes and they remain open source.

Our fork here is certainly vulnerable to these issues which we intend to resolve, but I'm sure most binary distributions of this library are not built off of this fork and will need to implement their own fixes and version appropriately. We will be editing the readme to clarify the nature of this fork going forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants