MPEG4 AAC crash "exploitable" - ZN5alloc3oom3oom17h7d76e900cfacf1cfE

RESOLVED FIXED

Status

()

Core
Audio/Video: Playback
RESOLVED FIXED
a year ago
11 months ago

People

(Reporter: Juan Pablo Lopez Yacubian, Unassigned)

Tracking

({csectype-oom, regression})

49 Branch
csectype-oom, regression
Points:
---

Firefox Tracking Flags

(firefox49 wontfix, firefox-esr45 unaffected, firefox50 wontfix, firefox51 verified, firefox52 verified)

Details

(Whiteboard: [sg:dos], crash signature)

Attachments

(5 attachments)

(Reporter)

Description

a year ago
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
(Reporter)

Updated

a year ago
Crash Signature: _ZN5alloc3oom3oom17h7d76e900cfacf1cfE
(Reporter)

Comment 1

a year ago
Created attachment 8803178 [details]
CRASH.mp4

CRASH POC
(Reporter)

Updated

a year ago
Group: firefox-core-security
(Reporter)

Comment 2

a year ago
Created attachment 8803179 [details]
windbg.msec
(Reporter)

Comment 3

a year ago
(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:
(Reporter)

Comment 4

a year ago
Created attachment 8803189 [details]
IllegalInstruction 40f.885 @ plugin-container.exe!xul.dll+0x5E940.html

Comment 5

a year ago
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
Group: firefox-core-security → media-core-security
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
(Reporter)

Comment 6

a year ago
tell me if is oka the stack in the attach
(Reporter)

Comment 7

a year ago
Created attachment 8803418 [details]
firefox-debug_aa48_2016-10-21_13-30-21-556.log
(Reporter)

Comment 8

a year ago
Created attachment 8803419 [details]
firefox-debug_ac2c_2016-10-21_12-13-17-147.log
Attachment #8803418 - Attachment mime type: text/x-log → text/plain
Attachment #8803419 - Attachment mime type: text/x-log → text/plain
Anthony, do you know who might look at this? Thanks.
Flags: needinfo?(ajones)
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.
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.
Flags: needinfo?(kinetik)
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.
Crash Signature: _ZN5alloc3oom3oom17h7d76e900cfacf1cfE → [@ _ZN5alloc3oom3oom17h7d76e900cfacf1cfE ]
Flags: needinfo?(jplopezy)
See Also: → bug 1313333, bug 1305250
(Reporter)

Comment 13

a year ago
Hi Daniel,


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

Comment 14

a year ago
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 ]
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?).
status-firefox49: --- → wontfix
status-firefox50: --- → affected
status-firefox51: --- → unaffected
status-firefox52: --- → unaffected
status-firefox-esr45: --- → unaffected
Flags: needinfo?(jplopezy)
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Flags: needinfo?(ajones)
(Reporter)

Comment 17

a year ago
(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)
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.
Group: media-core-security
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox50: affected → wontfix
status-firefox51: unaffected → verified
status-firefox52: unaffected → verified
Flags: needinfo?(kinetik)
Keywords: csectype-oom
Resolution: --- → FIXED
Whiteboard: [sg:dos]
Duplicate of this bug: 1313333
For some reason, the volume of this crash increased in 50.0b99.

Comment 21

a year ago
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?

Updated

a year ago
Keywords: regression
(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.
You need to log in before you can comment on or make changes to this bug.