Select provider of libav* libraries

[Balint Reczey]

On 05/24/2015 07:13 PM, Bálint Réczey wrote:
> Hi All,
> 
> I have contacted Moritz asking him to share his opinion regarding
> FFmpeg/Libav. He is not on the list thus asked me to forward his
> email.
Moritz also suggested asking Mateusz Jurczyk.

Please see his email:

On 05/27/2015 08:21 PM, Mateusz Jurczyk wrote:
> Hi Balint and others,
>
> Sure, I am happy to share my thoughts. First of all apologies for the
> late reply, I've been quite busy during the last few days.
>
> Anyway, since I have already expressed my opinion regarding the subject
> several times, let me just quote some of them:
>
>     While the former project [Libav] is doing their best to catch up
>     with the latter, the figures speak for themselves again: there are
>     “only” 413 commits tagged “Jurczyk” or “Coldwind” in Libav, so even
>     though some of the FFmpeg bugs might not apply to Libav, there are
>     still many unresolved issues there which are already fixed in
>     FFmpeg. Consequently, we advise users to use the FFmpeg upstream
>     code where possible, or the latest stable version (currently 2.1.1)
>     otherwise.
>
>
> Source: http://j00ru.vexillium.org/?p=2211
>
>     [...] it is not just several bugs Libav is lagging behind on - it's
>     literally hundreds, or potentially thousands, many of which are
>     security problems. Gynvael and I have been fuzzing FFmpeg for ~3
>     years now, and Michael has been consistently fixing them in his
>     project; so far, this has resulted in a total of 1318 patches in the
>     library (git log | grep j00ru | wc -l).
>
>
>
>     In the meantime, Libav is at 460 fixes, and the two codebases are
>     really not that far off each other (I believe Libav has most of
>     FFmpeg's code, and thus, bugs). We have fuzzed Libav independently
>     and tried to get their maintainers interested in fixing all those
>     issues (or picking patches from FFmpeg), and it has worked, but to
>     very little extent. As a result, we now have this gigantic
>     discrepancy in the security/reliability posture of the two projects,
>     which goes far beyond just a few samples.
>
>
>
>     [...]
>
>
>
>      I'm looking forward to having Debian switched from Libav to FFmpeg
>     - if there is any way I can help with that, let me know.
>
>
> Source: one of my previous e-mails sent to Moritz.
>
> Long story short, both FFmpeg and Libav projects contain a number of
> bugs in the processing of malformed input files, many of which are
> security vulnerabilities which can lead to arbitrary code execution and
> system compromise upon opening a specially crafted multimedia file.
> However, we have been trying to significantly decrease the number of
> such bugs in both projects via automated fuzz-testing, and specifically
> to get many of the "low hanging fruits" fixed so that it is no longer
> trivial for other people to discover security issues - in other words,
> to raise the bar for adversaries seeking to attack programs and systems
> which depend on multimedia handling.
>
> We have been quite successful working on the above effort with FFmpeg
> for the last ~3.5 years: every single issue we have found (even the
> least severe ones) has been fixed in a timely manner. As a result, after
> tens of fuzzing iterations, there are currently no bugs in FFmpeg that
> we are able to find using our current input corpus and mutation
> algorithms. The situation is entirely different with Libav, which is
> still affected by hundreds of such bugs, even though we have provided
> the developers with reproducing testcases a number of times in the past.
> Therefore, the security posture of Libav as of today is much, much worse
> than FFmpeg's, and this is the reason I support the transition to the
> latter library.
>
> I don't know anything about other aspects of the two projects, I can
> only give some insight into the security area. In this field, it is
> quite clear to me what the right choice is.
>
> Let me know if you have any questions.
>
> Cheers,
> Mateusz

Cheers,
Balint