Closed
Bug 1311868
Opened 8 years ago
Closed 8 years ago
MPEG4 AAC crash "exploitable" - ZN5alloc3oom3oom17h7d76e900cfacf1cfE
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox49 | --- | wontfix |
firefox-esr45 | --- | unaffected |
firefox50 | --- | wontfix |
firefox51 | --- | verified |
firefox52 | --- | verified |
People
(Reporter: jplopezy, Unassigned)
References
Details
(Keywords: csectype-oom, regression, Whiteboard: [sg:dos])
Crash Data
Attachments
(5 files)
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•8 years ago
|
Crash Signature: _ZN5alloc3oom3oom17h7d76e900cfacf1cfE
Reporter | ||
Comment 1•8 years ago
|
||
CRASH POC
Reporter | ||
Updated•8 years ago
|
Group: firefox-core-security
Reporter | ||
Comment 2•8 years ago
|
||
Reporter | ||
Comment 3•8 years 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•8 years ago
|
||
Comment 5•8 years 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•8 years ago
|
||
tell me if is oka the stack in the attach
Reporter | ||
Comment 7•8 years ago
|
||
Reporter | ||
Comment 8•8 years ago
|
||
Updated•8 years ago
|
Attachment #8803418 -
Attachment mime type: text/x-log → text/plain
Updated•8 years ago
|
Attachment #8803419 -
Attachment mime type: text/x-log → text/plain
Comment 9•8 years ago
|
||
Anthony, do you know who might look at this? Thanks.
Flags: needinfo?(ajones)
Comment 10•8 years ago
|
||
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•8 years ago
|
||
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)
Comment 12•8 years ago
|
||
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)
Updated•8 years ago
|
Reporter | ||
Comment 13•8 years ago
|
||
Hi Daniel, I get this signature open crash.mp4 in windows 7 x64 a firefox last relase
Reporter | ||
Comment 14•8 years 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 ]
Comment 15•8 years ago
|
||
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)
Updated•8 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 16•8 years ago
|
||
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.
Updated•8 years ago
|
Flags: needinfo?(ajones)
Reporter | ||
Comment 17•8 years 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)
Comment 18•8 years ago
|
||
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
Closed: 8 years ago
Flags: needinfo?(kinetik)
Keywords: csectype-oom
Resolution: --- → FIXED
Whiteboard: [sg:dos]
Comment 20•8 years ago
|
||
For some reason, the volume of this crash increased in 50.0b99.
Comment 21•8 years 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•8 years ago
|
Keywords: regression
Comment 22•8 years ago
|
||
(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.
Description
•