1154683 - (CVE-2015-2717) Integer overflow in libstagefright (data tag in mp4) might lead to heap overflow

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[laf.intel]

Attachment: integer overflow PoC

A specially crafted mp4 file can cause a integer overflow in the MPEG4Extractor::parseMetaData() function. When 'size' is 0xffffffff a integer overflow will occur which leads to an allocation of a (almost) 0 bytes big buffer (https://dxr.mozilla.org/mozilla-central/source/media/libstagefright/frameworks/av/media/libstagefright/MPEG4Extractor.cpp#2196).
Later the 0xffffffff bytes should be copied into the small buffer 'buffer' which would lead to a heap overflow.

Attached is a PoC which causes the integer overflow. On the tested firefox (build from mozilla-central) using a Nexus 5 (contrary to the expected behavior) no heap overflow occurred. This behavior might be caused by the implementation of read(). read() is called (with the anticipated 0xffffffff as size) but no write into the buffer occurs.

Comment 1

[Jean-Yves Avenard [:jya]]

Attachment: Fix potential size overflow

prevent size_t overflow.

Comment 2

[Jean-Yves Avenard [:jya]]

Comment on attachment 8593114 [details] [diff] [review]
Fix potential size overflow

there's a few like those, going for a different approach.

Comment 3

[Jean-Yves Avenard [:jya]]

Attachment: Fix potential size overflow

Ensure no size will ever overflow.

Comment 5

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Comment on attachment 8593128 [details] [diff] [review]
Fix potential size overflow

Review of attachment 8593128 [details] [diff] [review]:
-----------------------------------------------------------------

::: media/libstagefright/frameworks/av/media/libstagefright/MPEG4Extractor.cpp
@@ +1844,5 @@
>              }
>  
> +            if (size > (size_t)-1 - chunk_size) {
> +                return ERROR_MALFORMED;
> +            }

This statement is really hard to read. IIUC it is preventing an overflow. It would make sense to add a comment to that effect.

Comment 6

[Kevin Brosnan [Ex-Mozilla]]

[Tracking Requested - why for this release]: We probably want this on beta before 38 goes out the door.

Comment 7

[Jean-Yves Avenard [:jya]]

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/41787c8d077d

Comment 8

[Jean-Yves Avenard [:jya]]

Comment on attachment 8593128 [details] [diff] [review]
Fix potential size overflow

Approval Request Comment
[Feature/regressing bug #]:1154683
[User impact if declined]: Potential overflow and out of bound read.
[Describe test coverage new/current, TreeHerder]: Tested locally.
[Risks and why]: Low. Just extra checks that no size calculation will ever overflow
[String/UUID change made/needed]: None

Comment 9

[Sylvestre Ledru [:Sylvestre]]

sec-high, tracking.

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/41787c8d077d

Comment 11

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8593128 [details] [diff] [review]
Fix potential size overflow


(In reply to Jean-Yves Avenard [:jya] from comment #8)
> Approval Request Comment
> [Feature/regressing bug #]:1154683

Bug 1154683 is this bug. In which bug was this issue introduced? More to the point, how far back does this go? Is ESR31 affected?

This is now on m-c. Let's get it on Beta and Aurora as well.

Comment 12

[Jean-Yves Avenard [:jya]]

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #11)
> Comment on attachment 8593128 [details] [diff] [review]
> Fix potential size overflow
> 
> 
> (In reply to Jean-Yves Avenard [:jya] from comment #8)
> > Approval Request Comment
> > [Feature/regressing bug #]:1154683
> 
> Bug 1154683 is this bug. In which bug was this issue introduced? More to the
> point, how far back does this go? Is ESR31 affected?
> 
> This is now on m-c. Let's get it on Beta and Aurora as well.

I'd say since stagefright was added to our tree.
However, looking at ESR31 source code, it doesn't use libstagefright.

Comment 13

[Jean-Yves Avenard [:jya]]

Bug stagefright was introduced is bug 908503

Comment 14

[Jean-Yves Avenard [:jya]]

Lawrence, I read that 38 was merged today, should I uplift this to m-r ?

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8593128 [details] [diff] [review]
Fix potential size overflow

[Triage Comment]
Yes, that should be in m-r

Comment 16

[Jean-Yves Avenard [:jya]]

when does this need to be done by? pretty late here, was hoping to do it first thing tomorrow morning

Comment 17

[Sylvestre Ledru [:Sylvestre]]

tomorrow is fine, no worries!

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/4131212a78ce

This shouldn't have landed without sec-approval since it's a sec-high affecting multiple releases. Please request it retroactively.
https://wiki.mozilla.org/Security/Bug_Approval_Process

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/22f8fa3a9273

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/131b4e7d15d9

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/22f8fa3a9273
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/6a68a038146a
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/6a68a038146a

Comment 22

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #18)
> This shouldn't have landed without sec-approval since it's a sec-high
> affecting multiple releases. Please request it retroactively.
> https://wiki.mozilla.org/Security/Bug_Approval_Process

Ack! I missed that this bug didn't have sec approval when I saw that it had landed on m-c. We could really use an Hg hook to prevent sec-high and sec-crit bugs from landing without sec approval.

Comment 23

[Jean-Yves Avenard [:jya]]

Comment on attachment 8593128 [details] [diff] [review]
Fix potential size overflow

[Security approval request comment]
How easily could an exploit be constructed based on the patch? You'll need to craft an MP4 file with bogus atom's size offset. If you set the offset to be INT32_MAX - [1-8] ; you could end up allocating only [1-8] bytes and write in this allocated buffer INT32_MAX bytes.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? no. Only mentions that we prevent an overflow from happening (and reject the entire mp4 as being invalid)

Which older supported branches are affected by this flaw? anything including libstagefright. The flow was in this 3rd party library/

If not all supported branches, which bug introduced the flaw? bug 908503

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? The patch should apply on all branches with stagefright

How likely is this patch to cause regressions; how much testing does it need? Little, we just ensure that no integer overflow can occur.

As a note, all android devices ship with stagefright of which we have no control. They will have that flaw too. Firefox on Android makes use of the system's stagefright. Hopefully google will fix it.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/ff96615f8cfc
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0m/rev/ff96615f8cfc

Comment 25

[Al Billings [:abillings - ex-MoCo]]

Comment on attachment 8593128 [details] [diff] [review]
Fix potential size overflow

I might as well give sec-approval+ at this point. It's in.

Comment 26

[Yvan Boily [:ygjb][:yvan]]

adding sec-bounty since the reporter pinged me on irc asking about it.