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

Status: RESOLVED DUPLICATE of bug 504843

(Core :: Audio/Video, defect)

Description

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

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

Comment 1

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Attachment: test file that causes crash

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Attachment: stack trace of relevant thread

Comment 3

[Timothy B. Terriberry (:derf)]

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

[Jesse Ruderman]

Those show up as signal 11 (segfault)? :(  How can we distinguish them from actual segfaults?

Comment 5

[Timothy B. Terriberry (:derf)]

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.

Comment 6

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

(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?

Comment 7

[Timothy B. Terriberry (:derf)]

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).

Comment 8

[Daniel Veditz [:dveditz]]

If this is a DoS can we unhide the bug?

Comment 9

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

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.

Comment 10

[Jesse Ruderman]

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.

Comment 11

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

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.

Comment 12

[Josh Aas]

Opening this, seems like people are in agreement that this is a safe crash.