1311868 - MPEG4 AAC crash "exploitable" - ZN5alloc3oom3oom17h7d76e900cfacf1cfE

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect)

Description

[Juan Pablo Lopez Yacubian]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20161019084923

Steps to reproduce:


I have found it fuzzing with the last version of bff. simple sample of mp4 container and mpeg4 video codec with aac codec cause a exploitable sample

The fuzzer says that, i'm cheking if true

MPEG4 AAC crash "exploitable"

Check it

https://crash-stats.mozilla.com/report/index/01a02c9c-d0b9-47cb-95eb-190d62161014#tab-details

Comment 1

[Juan Pablo Lopez Yacubian]

Attachment: CRASH.mp4

CRASH POC

Comment 2

[Juan Pablo Lopez Yacubian]

Attachment: windbg.msec

Comment 3

[Juan Pablo Lopez Yacubian]

(5b4.1a00): Illegal instruction - code c000001d (first chance)
(5b4.1a00): Illegal instruction - code c000001d (!!! second chance !!!)
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files (x86)\Mozilla Firefox\xul.dll - 
xul+0x5ef40:
5360ef40 0f0b            ud2
0:069:x86> $$Found_with_CERT_BFF_2.8;r;!exploitable -v;q
eax=5360ef40 ebx=1b75f560 ecx=777f6434 edx=00000016 esi=7c000027 edi=1b75eb3c
eip=5360ef40 esp=1b75e188 ebp=1b75e1f8 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
xul+0x5ef40:
5360ef40 0f0b            ud2

!exploitable 1.6.0.0
HostMachine\HostUser
Executing Processor Architecture is x86
Debuggee is in User Mode
Debuggee is a live user mode debugging session on the local machine
Event Type: Exception
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\syswow64\kernel32.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll32.dll - 
Exception Faulting Address: 0x5360ef40
Second Chance Exception Type: STATUS_ILLEGAL_INSTRUCTION (0xC000001D)

Exception Hash (Major/Minor): 0x9d804df4.0xe800f6c7

 Hash Usage : Stack Trace:
Major+Minor : xul+0x5ef40
Major+Minor : xul+0x48d59
Major+Minor : xul+0x43240
Major+Minor : xul+0x3e740
Major+Minor : xul+0x56ba2
Minor       : xul+0x56b0f
Minor       : xul+0x40c7e
Minor       : xul+0x59acf
Minor       : kernel32!BaseThreadInitThunk+0x12
Excluded    : ntdll32!RtlInitializeExceptionChain+0x63
Excluded    : ntdll32!RtlInitializeExceptionChain+0x36
Instruction Address: 0x000000005360ef40

Description: Illegal Instruction Violation
Short Description: IllegalInstruction
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - Illegal Instruction Violation starting at xul+0x000000000005ef40 (Hash=0x9d804df4.0xe800f6c7)

An illegal instruction exception indicates that the attacker controls execution flow.
quit:

Comment 4

[Juan Pablo Lopez Yacubian]

Attachment: IllegalInstruction 40f.885 @ plugin-container.exe!xul.dll+0x5E940.html

Comment 5

[Benjamin Smedberg]

Moving this so the media team sees it. Juan, if you could use the Mozilla symbol server to get a better stack, that would be very helpful! https://developer.mozilla.org/en-US/docs/Mozilla/Using_the_Mozilla_symbol_server

Comment 6

[Juan Pablo Lopez Yacubian]

tell me if is oka the stack in the attach

Comment 7

[Juan Pablo Lopez Yacubian]

Attachment: firefox-debug_aa48_2016-10-21_13-30-21-556.log

Comment 8

[Juan Pablo Lopez Yacubian]

Attachment: firefox-debug_ac2c_2016-10-21_12-13-17-147.log

Comment 9

[Andrew McCreight [:mccr8]]

Anthony, do you know who might look at this? Thanks.

Comment 10

[Daniel Veditz [:dveditz]]

The attached stacks aren't useful. Did you make your own Firefox build, or are these standard downloads? Did the crash reporter come up? If so please submit the crash, then open about:crashes to find the crash ID. Paste the bp-xxxxxxxxx Id into a comment.

I tried Firefox 49 and 50 on a Mac and couldn't reproduce the crash, just got a message saying there were errors in the video and it couldn't be played. Having a little trouble with my windows box but I'll try there next.

Comment 11

[Daniel Veditz [:dveditz]]

on windows 49.0.2 I get bp-906afac8-5b59-4566-af63-5a4a62161027 
This is crashing in Rust code, the stagefright replacement stuff. Is that windows only? The function name _ZN5alloc3oom3oom17h7d76e900cfacf1cfE makes it sound like an OOM handler (and in C++ code we've made that intentionally fatal in many cases) but it does crash on an EXCEPTION_ILLEGAL_INSTRUCTION. Is that the way Rust abort()s? Not very graceful if so. crashes here:
https://hg.mozilla.org/releases/mozilla-release/annotate/7356baae8e73/media/libstagefright/binding/mp4parse/lib.rs#l1100

Don't know if the TODO(kinetik) is related to this crash.

Comment 12

[Daniel Veditz [:dveditz]]

Jaun Pablo: where did you get the (correct) signature  _ZN5alloc3oom3oom17h7d76e900cfacf1cfE to put in the bug summary? It looks like you must have had stack information, but I don't see that in any of your attachments.

Comment 13

[Juan Pablo Lopez Yacubian]

Hi Daniel,


I get this signature open crash.mp4 in windows 7 x64 a firefox last relase

Comment 14

[Juan Pablo Lopez Yacubian]

Daniel, with this browser now generate bp-f5ffcd19-2adc-4e73-b61c-c53b92161027

some crash

https://crash-stats.mozilla.com/report/index/f5ffcd19-2adc-4e73-b61c-c53b92161027

 Firefox 49.0.2 Crash Report [@ _ZN5alloc3oom3oom17h7d76e900cfacf1cfE ]

Comment 15

[Daniel Veditz [:dveditz]]

Thanks, we can reproduce that. Those links would have been more useful than the logs without the annotated stack information that you originally attached.

This no longer crashes in Dev Edition (51) or Nightly (52). In those builds I get the error "Video format or MIME type not supported". The main task now would be to determine whether this is exploitable or if it's just an OOM-suicide, and if it's exploitable figure out what fixed it so we can take it in Firefox 50 (of which we only have one more beta build?).

Comment 16

[Ralph Giles (:rillian)]

If the stack if correct, this is not exploitable, it's just a failed infallible application causing a rust panic. We're working on making those more graceful. :)

More recent versions of the code check if the declared size is over 1 MB and return an error instead, which is consistent with the crash not occurring in Firefox 51 and 52. If we're concerned about denial of service, backporting the bounds check would be low risk, but since it's not exploitable, I think it's fine to let the fix continue to ride the trains.

Comment 17

[Juan Pablo Lopez Yacubian]

(In reply to Daniel Veditz [:dveditz] from comment #11)
> on windows 49.0.2 I get bp-906afac8-5b59-4566-af63-5a4a62161027 
> This is crashing in Rust code, the stagefright replacement stuff. Is that
> windows only? The function name _ZN5alloc3oom3oom17h7d76e900cfacf1cfE makes
> it sound like an OOM handler (and in C++ code we've made that intentionally
> fatal in many cases) but it does crash on an EXCEPTION_ILLEGAL_INSTRUCTION.
> Is that the way Rust abort()s? Not very graceful if so. crashes here:
> https://hg.mozilla.org/releases/mozilla-release/annotate/7356baae8e73/media/
> libstagefright/binding/mp4parse/lib.rs#l1100
> 
> Don't know if the TODO(kinetik) is related to this crash.

Yes , this is correct

The bug is when the size box of AVCC box is big ¿?, for example in the "clear sample" the size box is 0000002F (in decimal 47) but in the crash poc 7C00002F ( in decimal 2080374831)

maybe the result of this operation

let avcc = try!(read_buf(src, (h.size - h.offset) as usize));


end bad here 

VideoCodecSpecific::AVCConfig(avcc)

Comment 18

[Daniel Veditz [:dveditz]]

We don't need to try to backport a DoS fix into a late beta. We're down to "stop-ship" type bugs for Fx50, and it's fixed in the next version. We should be good.

Comment 20

[Marco Castelluccio [:marco]]

For some reason, the volume of this crash increased in 50.0b99.

Comment 21

[[:philipp]]

on 50.0rc2 this signature is at quite a considerable volume with ~0.6% of browser crashes and #14 on the list of top crashes (#9 if you discount hangs on shutdown).
could we try to land the fix into 50.1 which is scheduled for mid-december?

Comment 22

[(not currently active) Ted Mielczarek]

(In reply to Daniel Veditz [:dveditz] from comment #11)
> fatal in many cases) but it does crash on an EXCEPTION_ILLEGAL_INSTRUCTION.
> Is that the way Rust abort()s? Not very graceful if so.

FYI, Rust intentionally emits a `ud2` instruction for intentional aborts, which is a quite safe way to reliably crash.