1130225 - Malformed input will cause invalid memory access in h264dec / function Write2File

Status: RESOLVED FIXED

(Core :: Audio/Video: GMP, defect)

Description

[Hanno Boeck]

Attachment: crash1.264

Attached file will cause invalid memory reads when passed to h264dec. The valgrind trace indicated that this seems to happen in the h264dec tool itself, not in the codec, so it's likely of low severity. Still it should be fixed.

Found with american fuzzy lop.

Comment 1

[Hanno Boeck]

Attachment: crash1.264.valgrind.txt

Comment 2

[wayne]

Hi Hanno, I checked with master and v1.3-Firefox3.6, finding no such issues.
Could you please give more detail about this crash issue?

Comment 3

[wayne]

(In reply to wayne from comment #2)
> Hi Hanno, I checked with master and v1.3-Firefox3.6, finding no such issues.
> Could you please give more detail about this crash issue?

Sorry, I wrongly used the command parameter. If with output file, the error exists. I'll check and fix it.

Comment 4

[wayne]

Hi Hanno, the crash has been fixed by pull request #1812 on master.
Could you please check it? Thanks!

Comment 5

[Hanno Boeck]

I can confirm latest git head is fixed.

And just for completion: Looking at the patch it seems to me my initial assumption that this is a bug in the commandlinetool h264dec was wrong. Instead it's a missing error handling in the library code that later crashes in the command line tool. Correct?

Comment 6

[wayne]

Thanks.
Originally some kinds of bitstream error are considered as WARNING instead of ERROR to improve robustness, for continuous decoding. 
For this case, we tried to make decoder go on decoding the erroneous bitstream, but now it seems WARNING is not enough as it does not throw proper information out of the decoder.

Comment 7

[chris hofmann]

wayne,  can you make an assessment about the security rating for this bug?

Comment 8

[wayne]

I'm not sure how many rating levels here for the security issues, but I give some descriptions to this:

1. it will happen only the specific syntax of SPS is hacked. So the frequency is low.
2. Even it is met, there's no memory leak issue happening inside codec, just some return information is wrongly given. It may cause above-layer applications unpredictable, or even crash (as in this example).

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

(In reply to wayne from comment #8)
> I'm not sure how many rating levels here for the security issues, but I give
> some descriptions to this:
> 
> 1. it will happen only the specific syntax of SPS is hacked. So the
> frequency is low.
> 2. Even it is met, there's no memory leak issue happening inside codec, just
> some return information is wrongly given. It may cause above-layer
> applications unpredictable, or even crash (as in this example).

Do you have any belief that this can cause a crash or other true security issue in OpenH264 as used by Firefox?  (i.e. not h264dec)

Comment 10

[wayne]

I cannot see how the callback function is used in Firefox, but from gmp-openh264, there's no safety check for the wrongly given data. 

I think it should be considered as a security bug.

Comment 11

[Daniel Veditz [:dveditz]]

Randell: please take a stab at rating the severity of this as a security affecting Firefox (or affecting it in the future if we would have shipped affected version of the plugin).

Comment 14

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

Is this issue fixed or still active? We're still shipping 1.3.

Comment 15

[Ethan Hugg [:ehugg]]

It is fixed in 1.4.  We are in the process of getting that out - it is bug 1133784

Comment 16

[Ethan Hugg [:ehugg]]

This should now be fixed by the rollout of OpenH264 v1.4 - bug 1133784.