Red Hat Bugzilla – Bug 599147
Libvpx has memory access overruns due to lack of motion vector clipping on some block types
Last modified: 2010-07-05 00:30:10 EDT
When libvpx was being discussed on fedora-devel I mentioned that there are "security relevant bugs", and cautioned against being overly hasty.
This was ignored and fedora has shipped libvpx in the repositories, and users who have installed it have it exposed to the internet via konqueror.
I'll attach a demonstration file that causes ivfdec to segfault on x86_64.
Reproduction there is as simple as ./ivfdec fuzz.ivf -o /dev/null.
If this file doesn't crash on your particular system you can find another test case easily enough with:
zzuf --include any_input_ivf.ivf -s 0:1000 -r 0.0001 ./ivfdec any_input_ivf.ivf -o /dev/null
This hasn't yet been fixed in upstream libvpx because fixing it correctly breaks the bitstream.
The browser vendors (e.g. firefox) are shipping their demo copies with patches, but because of the aforementioned bit-stream issue it causes corruption in some decodes.
There is another fix which retains compatibility with the existing encoder but which still leaves open inconsistent behaviour from other decoders as well as increasing memory usage and lowering performance.
(These patches are available on the webm development mailing list)
Can you point to the upstream bug ticket or the thread where this is discussed (with patches)?
Thanks in advance.
Sorry, I intended to link the thread and got a little send-happy:
Also, I do not believe you attached the demonstration file. :)
Created attachment 419154 [details]
thank you for your report. Just checking -- under "./ivfdec"
above you refer to which decoder? This one:
(wondering, because was trying this one:
and couldn't reproduce the crashes even when trying the "zzuf" command line
above on x86_64 libvpx-0.9.0-6.fc12 [the version you reported against
i.e. libvpx-0.9.0-6.fc13 should be the same]).
Will attach the output I got and try  yet.
Thanks && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Response Team
Created attachment 419473 [details]
The promised test output
Was run with command:
zzuf --include fuzz.ivf -s 0:1000 -r 0.0001 ./sample_ivfdec fuzz.ivf /dev/null > /tmp/`rpm -q libvpx`_output.txt
What I am doing wrong here?
Jan, I was able to reproduce a segfault on my Fedora 13 x86_64 system, using the ivfdec binary in the libvpx-utils package. Applying the patch from the thread in Comment 2 resolves the issue for the time being, so I have already done builds for all targets with it.
I was about to push updates. Do you have any reason for me not to?
(In reply to comment #7)
> Jan, I was able to reproduce a segfault on my Fedora 13 x86_64 system, using
> the ivfdec binary in the libvpx-utils package.
Ah, thanks, Tom, ok.
Applying the patch from the
> thread in Comment 2 resolves the issue for the time being, so I have already
> done builds for all targets with it.
You mean this one:?
FWICT  suggests this is only temporary solution, as it may break
some valid streams. Hopefully, we should investigate the issue in
more depth yet, watch && contribute to the upstream discussion regarding
this && build only the final conclusion patch (not causing regressions).
Tom, Gregory, what's your opinion?
> I was about to push updates. Do you have any reason for me not to?
The patch in  is explicitly stated to not break valid streams, just that it is ugly.
I'm inclined to push it as an update now, if for no other reason than to eliminate potential browser crashes once more browsers start enabling VP8 support.
If/when a "final conclusion" patch emerges, we can move to it (likely with a new upstream release of libvpx).
The patch in that thread does not break existing bitstreams. See comment 3 on the original thread or Tim's comments that you linked to in .
The reason it isn't yet the final upstream solution is that it permanently makes all decoders do extra work and also makes the behaviour inconsistent between modes, which is sure to cause implementation bugs.
Tim (and me, and a lot of other people) would really like google to break the bitstream to adopt a proper fix. Unfortunately as time goes on this seems less and less likely. (Their resistance to doing this comes from that fact that they have made commitments, plus youtube has already transcoded something like few million files) If google doesn't change the bitstream than the patch is the only option.
My recommendation would have been to not ship libvpx at all until this was resolved. Seeing as how thats no longer an option, shipping the fix that is compatible with the existing encoder is strictly superior to doing nothing. It closes a potential security vulnerability, and doesn't create an _additional_ incompatibility over what would exist if the bitstream is changed.
I asked Tim for his thoughts and he said "I mean, it's better than nothing. At this rate, it's going to become the de-facto standard."
The pending 0.9.1 update resolves this. Closing out the ticket.
(I would do it normally, via bodhi, but it doesn't handle security restricted bugs, and no one can seem to figure out how to uncheck that box.)