New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Jun 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

OOB read in media::FFmpegVideoDecodeEngine::Initialize

Project Member Reported by kcc@chromium.org, May 12 2011

Issue description

Caught this using inferno's fuzzer. 
Unless this tool is mistaken, the guts of avcodec_open read past the allocated memory region (and maybe write afterwards). 
Unfortunately, the stack above avcodec_open is not symbolized, I am working on that. 

There are some crashes with media::FFmpegVideoDecodeEngine::Initialize in it... 
http://crash/search?query=media%3A%3AFFmpegVideoDecodeEngine%3A%3AInitialize


READ of size 4 at 0x00002000031b522e; shadow: 0x00001000018da917; mem: 0x000000000c6d48ba thread: 0x9df1700             
  #0 0x7f4435befe75                                                                                                     
  #1 0x7f4435befca3                                                                                                     
  #2 0x7f4435befcea                                                                                                     
  #3 0x7f4435befca3                                                                                                     
  #4 0x7f4435befcea                                                                                                     
  #5 0x7f4435befcea                                                                                                     
  #6 0x7f4435bd6c0a                                                                                                     
  #7 0x7f4435bb4b80 (avcodec_open)                                                                                                    
    #8 0x061cb360  << media::FFmpegVideoDecodeEngine::Initialize  media/video/ffmpeg_video_decode_engine.cc:146         
    #9 0x061b2c0e  << media::FFmpegVideoDecoder::Initialize  media/filters/ffmpeg_video_decoder.cc:82                   
    #10 0x0184768d  << (anonymous namespace)::TaskClosureAdapter::Run()  base/message_loop.cc:100                       
    #11 0x0184b3f7  << base::Callback<void ()>::Run() const  ./base/callback.h:252                                      
    #12 0x0184b951  << MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const0x184b951)  base/message_loop.cc:480  
    #13 0x0184c9b9  << MessageLoop::DoWork()  base/message_loop.cc:670                                                  
    #14 0x0185437e  << base::MessagePumpDefault::Run(base::MessagePump::Delegate*)  base/message_pump_default.cc:23     
    #15 0x0184a4b4  << MessageLoop::RunInternal()  base/message_loop.cc:438                                             
    #16 0x01848e04  << MessageLoop::RunHandler()  base/message_loop.cc:410                                              
    #17 0x018b12f1  << base::Thread::ThreadMain()  base/threading/thread.cc:164                                         
    #18 0x018b009c  << ThreadFunc  base/threading/platform_thread_posix.cc:51                                           
  #19 0x7f44488799ca                                                                                                    
  #20 0x7f4446c1570d                                                      
                                              
 0x000000000c6d48ba is the address located 0 bytes to the right of region:                                              
[0x000000000c6d3df0,0x000000000c6d48bd) -- allocated memory of 0xacd (2765) bytes                                       
allocated by thread 0x9df1700 here:                                                                                     
    #0 0x0646a85a  << posix_memalign  /home/kcc/asan/asan/asan_rtl.cc:1226                                              
  #1 0x7f4435c46479                                                                                                     
    #2 0x061caa2c  << media::FFmpegVideoDecodeEngine::Initialize  media/video/ffmpeg_video_decode_engine.cc:76          
    #3 0x061b2c0e  << media::FFmpegVideoDecoder::Initialize  media/filters/ffmpeg_video_decoder.cc:82                   
    #4 0x0184768d  << (anonymous namespace)::TaskClosureAdapter::Run()  base/message_loop.cc:100                        
    #5 0x0184b3f7  << base::Callback<void ()>::Run() const  ./base/callback.h:252                                       
    #6 0x0184b951  << MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const0x184b951)  base/message_loop.cc:480  
    #7 0x0184c9b9  << MessageLoop::DoWork()  base/message_loop.cc:670                                                   
    #8 0x0185437e  << base::MessagePumpDefault::Run(base::MessagePump::Delegate*)  base/message_pump_default.cc:23      
    #9 0x0184a4b4  << MessageLoop::RunInternal()  base/message_loop.cc:438                           
 

Comment 1 by kcc@chromium.org, May 13 2011

Labels: Stability-AddressSanitizer

Comment 2 by kcc@chromium.org, May 13 2011

Full stack: 

==32145== ERROR: AddressSanitizer crashed on address 0x0000200002748ef2 at pc 0x7fc4e2619e45
READ of size 4 at 0x0000200002748ef2; shadow: 0x00001000013a4779; mem: 0x0000000009d23bca thread: 0xb4f94700
    #0 0x7fc4e2619e45 read_huffman_tree third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/get_bits.h:387
    #1 0x7fc4e2619c73 read_huffman_tree third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/vp3.c:2071
    #2 0x7fc4e2619cba read_huffman_tree third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/vp3.c:2074
    #3 0x7fc4e2619c73 read_huffman_tree third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/vp3.c:2071
    #4 0x7fc4e2619cba read_huffman_tree third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/vp3.c:2074
    #5 0x7fc4e2619cba read_huffman_tree third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/vp3.c:2074
    #6 0x7fc4e2600bda theora_decode_init third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/vp3.c:2270
    #7 0x7fc4e25deb50 avcodec_open third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/utils.c:543
    #8 0x62255f0 media::FFmpegVideoDecodeEngine::Initialize(MessageLoop*, media::VideoDecodeEngine::EventHandler*, media::VideoDecodeContext*, media::VideoDecoderConfig const&) media/video/ffmpeg_
    #9 0x620cc1e media::FFmpegVideoDecoder::Initialize(media::DemuxerStream*, CallbackRunner<Tuple0>*, CallbackRunner<Tuple1<media::PipelineStatistics const&> >*) media/filters/ffmpeg_video_decode
    #10 0x184093d (anonymous namespace)::TaskClosureAdapter::Run() base/message_loop.cc:100
    #11 0x18446a7 base::Callback<void ()()>::Run() const ./base/callback.h:251
    #12 0x1844c01 MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) base/message_loop.cc:480
    #13 0x1845c69 MessageLoop::DoWork() base/message_loop.cc:670
    #14 0x184d62e base::MessagePumpDefault::Run(base::MessagePump::Delegate*) base/message_pump_default.cc:23
    #15 0x1843764 MessageLoop::RunInternal() base/message_loop.cc:438
    #16 0x18420b4 MessageLoop::RunHandler() base/message_loop.cc:410
    #17 0x18aa5a1 base::Thread::ThreadMain() base/threading/thread.cc:164
    #18 0x18a934c base::(anonymous namespace)::ThreadFunc(void*) base/threading/platform_thread_posix.cc:51
  #19 0x7fc4e9c959ca
  #20 0x7fc4e803170d
 0x0000000009d23bca is the address located 0 bytes to the right of region:
[0x0000000009d23100,0x0000000009d23bcd) -- allocated memory of 0xacd (2765) bytes
allocated by thread 0xb4f94700 here:
    #0 0x64c497a posix_memalign /home/kcc/asan/asan/asan_rtl.cc:1239
    #1 0x7fc4e2670449 av_malloc third_party/ffmpeg/patched-ffmpeg-mt/libavutil/mem.c:83
    #2 0x6224cbc media::FFmpegVideoDecodeEngine::Initialize(MessageLoop*, media::VideoDecodeEngine::EventHandler*, media::VideoDecodeContext*, media::VideoDecoderConfig const&) media/video/ffmpeg_
    #3 0x620cc1e media::FFmpegVideoDecoder::Initialize(media::DemuxerStream*, CallbackRunner<Tuple0>*, CallbackRunner<Tuple1<media::PipelineStatistics const&> >*) media/filters/ffmpeg_video_decode
    #4 0x184093d (anonymous namespace)::TaskClosureAdapter::Run() base/message_loop.cc:100
    #5 0x18446a7 base::Callback<void ()()>::Run() const ./base/callback.h:251
    #6 0x1844c01 MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) base/message_loop.cc:480
    #7 0x1845c69 MessageLoop::DoWork() base/message_loop.cc:670
    #8 0x184d62e base::MessagePumpDefault::Run(base::MessagePump::Delegate*) base/message_pump_default.cc:23
    #9 0x1843764 MessageLoop::RunInternal() base/message_loop.cc:438

Comment 3 by kcc@chromium.org, May 13 2011

attached reproducer
fuzz-happyfuntime-QTRVBQ.html
1012 KB View Download
I discussed the credit with kcc and fuzzer names. This one goes to Cris Neckar (happyfuntime).
Cc: scherkus@chromium.org fbarchard@chromium.org cevans@chromium.org
Labels: -Pri-2 Pri-1 SecSeverity-High OS-All Feature-Media
Owner: security...@gtempaccount.com
Status: Assigned
Looks like this was hit by my fuzzer too. So, credits to Kostya, Cris and Me :)

Andrew, Frank, can you please help to triage this.

Bot LIN_BOT on platform LINUX
Root : http://src.chromium.org/svn
Revision : 85147
Root : http://svn.webkit.org/repository/webkit
Revision : 86241

Repro:: run in webkit layouttests/media dir (WITH ASAN - https://sites.google.com/a/chromium.org/dev/developers/testing/addresssanitizer)

<script src=media-file.js></script><script>
            function start()
            {
                setSrcByTagName("video", findMediaFile("video", "content/test"));
            }</script><body onload="start()">
        <video controls</video>
Another super easy testcase on linux
<video src='http://double.co.nz/video_test/bricktrailer.ogg'>

Comment 7 by jsc...@chromium.org, May 16 2011

How easy it is really depends on the complexity of the video file, which is the real trigger.
bricktrailer.ogg
7.3 MB Download
Labels: Mstone-12 ReleaseBlock-Stable
Cc: -scherkus@chromium.org
Owner: scherkus@chromium.org
The video does not play and media disabled/crash when trying to play this in chrome canary, stable. Frank told me that we have NOV build of ffmpeg. he tried with recent ffmpeg trunk and it decodes fine.
media_bench --stream=video bricktrailer.ogg test.yuv decodes to a yuv file that plays ok

Andrew, can you please take a look.
media_bench works okay on it, at least on Windows
d:\mediatests>media_bench --stream=video bricktrailer.ogg test.yuv
* Stream #0: theora (Theora)
  Stream #1: vorbis (Vorbis)

    Threads:          0
     Frames:       4532
      Width:        480
     Height:        360
      Total:    8190.84 ms
  Summation:    1910.18 ms
    Average:       0.42 ms
     StdDev:       0.20 ms       46.33 %
 FPS StdDev:    1311.94 ms       55.30 %
 Decode FPS:    2372.55
  Total FPS:     553.30
    Min FPS:     781.25 Frame:       1427 Time:       1.28 ms
 Drop count:          0
and the yuv plays okay.  audio also decodes.
Chrome doesn't work... button goes away
http://tskir-html5.kir.corp.google.com/mediatests/bricktrailer.html
Firefox4 fails with a big 'X' over the video.

Comment 11 by kcc@chromium.org, May 16 2011

Just a clarification: this bug does not crash chrome, at least usually. 
It only crashes under http://dev.chromium.org/developers/testing/addresssanitizer, 
with an indication of an out-of-bound access. 

Comment 12 by k...@google.com, May 17 2011

Do we need to keep this as a blocker for 12 then?

Comment 13 by kcc@chromium.org, May 18 2011

>> Do we need to keep this as a blocker for 12 then?
For this I have no opinion, the security folks should know better if an out-of-bounds read is a blocker. 
Yes this is a blocker. This is hit very easily in multiple repros. We should fix it for m12.
I'm confused.

bricktrailer.ogg doesn't crash in Canary yet it does in M-12?  Is that true?  I can't get it to crash and I'm wondering if we should treat this as a blocker for M-12 or just let it slide until an FFmpeg update.
These crashes were found in our fuzzing on trunk which is m13. So this issue isn't fixed yet. Also, check out the testcase from c#5 by putting in layouttests/media dir. These testcases don't crash, they only crash inside a memory debugging tool like ASAN. So, they need to debugged in a debugger to track where that invalid read happens. Our stacktrace above has symbols which should simplify the analysis. Andrew, did you get a chance to take a look.

Bot LIN_BOT2 on platform LINUX
Root : http://src.chromium.org/svn
Revision : 85577
Root : http://svn.webkit.org/repository/webkit
Revision : 86640

Comment 17 Deleted

Comment 18 by k...@google.com, May 23 2011

What's the status with this?  We have until EOD to make the final beta cut with this.
Summary: OOB read in media::FFmpegVideoDecodeEngine::Initialize
Correcting title.
Taking a quick look at the source vs stack

get_bits reads 4 bytes off end of buffer
vp3 calls get_bits from read_huffman_tree
  called from theora_decode_tables
  called from theora_decode_init
which has buffer_enforcing=1
                                             
init_get_bits(&gb, header_start[i], header_len[i] * 8);                  
gb.buffer_enforcing = 1;                                                 
          ...
              
    case 0x82:                                                           
        if (theora_decode_tables(avctx, &gb))                            
            return -1;                                                   


Started looking at this before realizing Frank was on it.
The asan report is a bit misleading:
 0x000000000c6d48ba is the address located 0 bytes to the right of region:                                              
[0x000000000c6d3df0,0x000000000c6d48bd) -- allocated memory of 0xacd (2765) bytes
in that it implies that the read is precisely to the right of the allocated region, where in fact the read *overlaps* the allocated region (so IMO the "0 bytes" should say "-3 bytes").
This looks innocuous to me because either the extra read succeeds (doesn't segv) and then the code ignores the bits that weren't requested, or the overrunning read segv's and the renderer crashes.  Neither seems like a security concern.
The latter case also seems unlikely; the only way to trigger it (at least in this codepath) is to have a codec config's extra_data be non-0 mod 4, and no arch we care about has a page size *not* a multiple of 4, so faulting seems impossible to me.

That said, I'm no expert on ffmpeg and could be misreading things.
Frank: do you buy this?  (I'm failing to grok from your comment above what your conclusions are)

Comment 22 by kcc@chromium.org, May 24 2011

Yea... 
The code reads 4 bytes from [0xba, 0xbe), while the region is [..., 0xbd). 
So, the code reads 1 byte past the allocated region. 

The read address is not 4-aligned, so it may in fact cause a fault. (still, quite unlikely)

If there's any way to get the OOB read data back to script etc, then it's a security concern. Since it's pretty difficult to determine absolutely whether or not that's the case, we err on the side of caution.

Also, we are seeing crash reports in the wild on this. @inferno can jump in and provide some.
I seem to remember we discussed this before and the current (ugly) pattern to resolve this situation in ffmpeg is to over-allocate the source buffers to cater for the chunked nature of get_bits() buffer reading? I'm suspecting this is pretty easy to fix, Andrew?
Note if you're using a crash query of media::FFmpegVideoDecodeEngine::Initialize that it could be any random video that's causing the crash and not related to this particular crash but possibly _other_ crash bugs!

That symbol will always show up in the stack trace since it calls av_open_input_file() 
Labels: -SecSeverity-High -ReleaseBlock-Stable SecSeverity-Medium
Updating labels. If the fix is easy, we should still try to aim for m12 first patch.

Comment 28 by kcc@chromium.org, May 25 2011

FYI: I can see the same ASAN report on UILayoutTest.MediaUILayoutTest:

0x00007f0ce07d5542 is located 0 bytes to the right of 2741-byte region [0x00007f0ce07d4a90,0x00007f0ce07d5545)

Same situation, we read 4 bytes while only 3 are legally addressable. 

Labels: -Mstone-12 Mstone-13
not an easy for m12
Labels: -Mstone-13 Mstone-12
Owner: cevans@chromium.org
Chris can knock it out fast enough for m12.
Status: Started
Investigating.
Ah, this is easy.
Project Member

Comment 33 by bugdroid1@chromium.org, Jun 8 2011

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=88354

------------------------------------------------------------------------
r88354 | cevans@chromium.org | Wed Jun 08 10:29:34 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/video/ffmpeg_video_decode_engine.cc?r1=88354&r2=88353&pathrev=88354

Don't forget the ffmpeg input buffer padding when allocating a codec's
extradata buffer.

BUG= 82438 
Review URL: http://codereview.chromium.org/7137002
------------------------------------------------------------------------
Labels: -Mstone-12 Mstone-14
Status: FixUnreleased
Doesn't seem at all risky to me, it can roll in to M14.
Labels: CVE-2011-2843
Labels: SecImpacts-Stable
Batch update.
Labels: -Restrict-View-SecurityNotify
Lifting view restrictions.
Status: Fixed

Comment 39 Deleted

Project Member

Comment 40 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 41 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Type-Security -Area-Internals -Stability-AddressSanitizer -SecSeverity-Medium -Feature-Media -Mstone-14 -SecImpacts-Stable Cr-Internals-Media Security-Severity-Medium Cr-Internals Performance-Memory-AddressSanitizer Security-Impact-Stable Type-Bug-Security M-14
Project Member

Comment 42 by bugdroid1@chromium.org, Mar 11 2013

Labels: -Stability-Memory Performance-Memory
Project Member

Comment 43 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 44 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 45 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Severity-Medium Security_Severity-Medium
Project Member

Comment 46 by bugdroid1@chromium.org, Apr 1 2013

Labels: -Performance-Memory-AddressSanitizer Stability-Memory-AddressSanitizer
Project Member

Comment 47 by bugdroid1@chromium.org, Apr 1 2013

Labels: -Performance-Memory Stability-Memory
Project Member

Comment 48 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 49 by sheriffbot@chromium.org, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment