Memory corruption in wmv parsing

[Dan Rosenberg]

Binary package hint: vlc

I've attached a fuzzed Windows Media file that crashes VLC due to an out-of-bounds write. Based on my testing, the offset at which this write is performed is controllable by manipulating the contents of the file, suggesting that this is an exploitable memory corruption vulnerability.

The crash occurs in ffmpeg-0.5.1/libavcodec/error_resilience.c at line 334:

    for(i=0; i<s->mb_num; i++){
        const int mb_xy= s->mb_index2xy[ i ];
        int f=0;
        int error= s->error_status_table[mb_xy];

        if(IS_INTRA(s->current_picture.mb_type[mb_xy])) f=MV_FROZEN; //intra //FIXME check
        if(!(error&MV_ERROR)) f=MV_FROZEN; //inter with undamaged MV

* fixed[mb_xy]= f;
        if(f==MV_FROZEN)
            num_avail++;
    }

I wasn't sure if it would be more appropriate to file a bug here or with ffmpeg, since it's unclear as to whether the issue is due to a bug in ffmpeg or improper invocation of ffmpeg library functions. I've confirmed this issue on Lucid (VLC 1.0.6) as well as VLC upstream (1.1.5).

[Kees Cook (kees)]

Please use CVE-2010-3908 for this issue.

Note that using ffmpeg directly, current version errors out, but ffmpeg 0.5.1 hits 100% CPU.

Note that this does not crash on maverick and later, so that would point more to an issue in ffmpeg triggering the vlc crash.

[Rémi Denis-Courmont (rdenis)]

I cannot reproduce the crash with FFmpeg 0.5.2 (from Debian Squeeze). Instead, the VLC 1.1.5 process will bring my computer into thrashing hell, as the file claims to have video of a preposterously large resolution. I get the same thrashing with FFplay 0.5.2. It could be the crash occurs after running out of memory, but I assume Dan would have mentioned such a caveat.

VLC 1.2.0 already avoid the issue by discarding overly large resolution.

What happens if you pass the file to Lucid's version of ffplay (ffmpeg binary package)? Unfortunately, I have no Lucid system at hand.

[Dan Rosenberg (dan-j-rosenberg)]

Passing the file to ffmpeg v0.5.1 (binary package from Lucid) results in the process consuming lots of memory, but it doesn't appear to cause the crash. When running VLC by itself, the crash occurs promptly, without excessive memory consumption.

This might be one of those ugly cases where the issue is due to a very specific bad interaction between VLC and one version of ffmpeg, rather than a problem in the library itself. Good luck.

[Rémi Denis-Courmont (rdenis)]

On the decoding side, VLC does nothing particular about WMV (except for VAAPI); it's just fed to avcodec as anything. So I have to assume this is a bug only in old FFmpeg versions, and is not an VLC upstream issue.

[Dan Rosenberg (dan-j-rosenberg)]

I stumbled upon this bug again when fuzzing RealPlayer (.rm) files, but this time, it seems to cause heap corruption in ffmpeg and ffplay (both 0.5.1 and 0.5.3).

I'm attaching four files here. If any of these turn out to be independent issues, this may require the allocation of more CVEs, but I figured the root cause of each issue should be determined first. The files are as follows:

1. sample.rm - the original unaltered file, which obviously does not crash ffmpeg or vlc

2. pred4x4_128_dc_c.rm - a fuzzed file that causes heap corruption in ffmpeg and crashes vlc with an out-of-bounds write in pred4x4_128_dc_c()

3. put_dc.rm - a fuzzed file that causes heap corruption in ffmpeg and crashes vlc with an out-of-bounds write in put_dc(), which is the same crash location as the previously attached WMV file.

4. heap.rm - causes heap corruption in ffmpeg

It's likely that pred4x4_128_dc_c.rm and put_dc.rm are caused by the same underlying problem, since they differ by a single byte that results in the crash occurring at a different place. I haven't determined whether or not heap.rm is the same issue. Hopefully these files help get to the bottom of the issue(s).

[Rémi Denis-Courmont (rdenis)]

As far as I know, RM and WMV are completely different codecs. That they make libavcodec crash in the same "utility" function is not really telling any more than two bugs crashing in memcpy() would... They are most certainly independent bugs.

In any case, if ffmpeg/ffplay crashes on its own, then it is not, or at least not only, a VLC bug.

[Dan Rosenberg (dan-j-rosenberg)]

I've attached another crash file. This one breaks VLC inside ffmpeg functions and triggers glibc stack-smashing protection, but does not crash ffmpeg by itself. The format is VC1 this tihme. I didn't even have to fuzz the file this time - this is an original unfuzzed sample.

Let me know if there's anything I can do to help resolve these issues.

[Rémi Denis-Courmont (rdenis)]

'valgrind ffplay sample.vc1' shows heap buffer overflows just like 'vlc sample.vc1'. I think it's just pure luck that ffplay does not crash in spite of the heap corruption.

I am not currently sponsored to support VLC and I really do not have the resources to fix nor forward security issues inside dependent libraries. I expect Christophe is in a similar situation. So do not expect the VLC security team to deal with all those FFmpeg issues. Sorry.

[Dan Rosenberg (dan-j-rosenberg)]

Ok, I've pinned down most of what's been happening here.

The crash with the WMV parsing (CVE-2010-3908) was fixed with the following upstream commit:
http://git.videolan.org/?p=FFmpeg.git;a=commit;h=445f0a8b666a34e6402f6ae96c6804c8bc024baa

I'm not sure whether the fact that it fixed this issue was incidental or intentional.

The RealMedia heap corruption crashes were fixed with the following upstream commit:
http://git.videolan.org/?p=FFmpeg.git;a=commit;h=ec10d2d53999f6edf7d7b5ac88df263eccfb1fb0

I think these should probably get a separate CVE.

Finally, the VC1 crash affects current upstream git (when running VLC on top of libavcodec). The nature of the crash changes based on the build version. In all cases, there appears to be a stack overflow in the same piece of code that crashed with the WMV file:

    for(i=0; i<s->mb_num; i++){
        const int mb_xy= s->mb_index2xy[ i ];
        int f=0;
        int error= s->error_status_table[mb_xy];

        if(IS_INTRA(s->current_picture.mb_type[mb_xy])) f=MV_FROZEN; //intra //FIXME check
        if(!(error&MV_ERROR)) f=MV_FROZEN; //inter with undamaged MV

        fixed[mb_xy]= f;
        if(f==MV_FROZEN)
            num_avail++;
    }

In this case, MV_FROZEN is continually written into the fixed[] array, which is declared on the stack, well past its bounds, corrupting the stack. Depending on the build, this corruption may cause crashes in various places, but in 0.5.3, execution continues until returning to 0x03030303. This also probably deserves a separate CVE.

[Reinhard Tartler (siretart)]

I've backported the first two commits into my local 0.5 release branch, but since AFAIUI this issue is still confidential, I haven't pushed it to git.ffmpeg.org yet. Also, if someone has a CVE Number for the second issue, I can add it to the commit message. This means that both patches are being scheduled for a potential 0.5.4 release.

I've also checked that FFmpeg 0.6 and later have both patches already included.

[Kees Cook (kees)]

Thanks for hunting these down!

RealMedia: CVE-2011-0722
VC1: CVE-2011-0723

[Reinhard Tartler (siretart)]

Added reference to 'RealMedia: CVE-2011-0722' to my local, unpushed git commit (issue seems still private)

still no solution for the VC1 issue (needs upstreaming)

[Kees Cook (kees)]

Dan has opened a bug with upstream now:

https://roundup.ffmpeg.org/issue2584

[Reinhard Tartler (siretart)]

not wanting to break any embargoing protocol, but is it okay to push the revisions along with the CVE references to the public ffmpeg git repo right now?

[Dan Rosenberg (dan-j-rosenberg)]

Yes, especially since the WMV issue is publicly visible in ffmpeg's bug tracker. Thanks for waiting.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ffmpeg - 4:0.6-2ubuntu6.1

---------------
ffmpeg (4:0.6-2ubuntu6.1) maverick-security; urgency=low

  * SECURITY UPDATE: denial of service via crafted .ogg file
    - debian/patches/fix-CVE-2010-4704.patch: validate codebook in
      libavcodec/vorbis_dec.c.
    - CVE-2010-4704
  * SECURITY UPDATE: denial of service and possible code execution via
    crafted WebM file
    - debian/patches/fix-CVE-2011-0480.patch: check rangebits in
      libavcodec/vorbis_dec.c.
    - CVE-2011-0480
  * SECURITY UPDATE: denial of service and possible code execution via
    crafted VC1 file (LP: #690169)
    - debian/patches/fix-CVE-2011-0723.patch: fix invalid reads in
      libavcodec/vc1dec.c.
    - CVE-2011-0723
 -- Marc Deslauriers <email address hidden> Thu, 31 Mar 2011 10:38:02 -0400