crash (segfault) @ oc_dec_dc_coeff_unpack when playing corrupted ogg theora file

RESOLVED DUPLICATE of bug 504843

Status

()

Core
Audio/Video
RESOLVED DUPLICATE of bug 504843
9 years ago
6 years ago

People

(Reporter: keeler, Unassigned)

Tracking

({crash, testcase})

Trunk
x86
Linux
crash, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:DoS] null deref)

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009060308 Ubuntu/9.04 (jaunty) Firefox/3.0.11
Build Identifier: mozilla-central revision e1ae3719e72a

Segmentation fault when playing corrupted ogg theora file (attached).

Reproducible: Always

Steps to Reproduce:
1. Load attached file.
Actual Results:  
firefox crashes

Expected Results:  
some sort of "this file is corrupted" message
(Reporter)

Comment 1

9 years ago
Created attachment 390014 [details]
test file that causes crash
(Reporter)

Comment 2

9 years ago
Created attachment 390015 [details]
stack trace of relevant thread
This appears to be the kind of "small enough to pass malloc, big enough to fail when the kernel actually goes to map pages" test case I warned about in https://bugzilla.mozilla.org/show_bug.cgi?id=504843, or at least fairly close.

It decodes fine for me on x86-64 (producing 3.1 GB of output, or 7 frames).

Comment 4

9 years ago
Those show up as signal 11 (segfault)? :(  How can we distinguish them from actual segfaults?
The solution proposed in that bug, adding a "reasonable resolution" check to liboggplay or restructuring the API so that Firefox can add such a check before a decoder is actually created, should still apply here.

With this file, libtheora succeeds at allocating a decoder, and fails while trying to fill in the decoded token buffer, which is not touched during initialization. A slightly larger resolution might have even failed trying to write to pages during initialization.
(Reporter)

Comment 6

9 years ago
(In reply to comment #3)
> It decodes fine for me on x86-64 (producing 3.1 GB of output, or 7 frames).

Any idea where it's getting the data to decode 3.1 GB of output?
The number of blocks in a frame is defined in the file header. The decoder will always generate data for that many blocks, regardless of the size of an input packet. Even a zero-byte packet is legal (it indicates a dropped frame, e.g., all the contents are the same as the previous frame).
(Reporter)

Updated

9 years ago
Whiteboard: [sg:DoS] null deref
Status: UNCONFIRMED → NEW
Ever confirmed: true
If this is a DoS can we unhide the bug?
(Reporter)

Comment 9

9 years ago
Actually, I probably mislabeled this.  Going from https://bugzilla.mozilla.org/show_bug.cgi?id=504843#c11, this might be exploitable if the file is modified slightly and is opened under low memory situations.
Marking as sg:low and keeping closed, unless someone thinks I'm being too paranoid or unreasonable.
Whiteboard: [sg:DoS] null deref → [sg:low] null deref (malloc failure)

Comment 10

9 years ago
I don't understand that concern.  When the OS says "that page I gave you is not actually available", it's still a safe segfault.
(Reporter)

Comment 11

9 years ago
Ah - I see.  tterribe was saying that it would still crash even if malloc's return value was checked, not that it wasn't safe.
Back to sg:DoS.
Whiteboard: [sg:low] null deref (malloc failure) → [sg:DoS] null deref

Comment 12

6 years ago
Opening this, seems like people are in agreement that this is a safe crash.
Group: core-security
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 504843
You need to log in before you can comment on or make changes to this bug.