FFmpeg: Multiple vulnerabilities
fsbruva opened this issue · 8 comments
The bundled version of ffmpeg suffers from 286 known vulnerabilities, including 33 that received a severity rating of 10.0 (out of 10) from the NIST National Vulnerability Database.
Two options:
- Accept the risk, and continue to use ffmpeg 0.8.6
- Upgrade ffmpeg to latest version, 4.1.1 - which corrects all the vulnerabilities of 0.8.6.
- Upgrade to some other, intermediary version of ffmpeg
I recommend option 2. Version 4.1 only has 3 vulnerabilities reported, one of which was corrected by 4.4.1, and the other two were reported less than a week ago.
Which option should I pursue and prepare a PR for? I have already solved the upgraded ffmpeg API problems for libmediascan and libdlna, so that isn't a concern.
What parts of ffmpeg are we using? Where do we use them? And with how many of those vulnerabilities does this leave us?
I'd rather disable the media server part from LMS than try to update Media::Scan (which likely is the module using ffmpeg) on existing platforms.
You are correct, Media::Scan is the module using ffmpeg. I believe it uses libavcodec, libavfilter, libavformat, libavutils, and libswscale to assist with scanning, obtaining metadata and generating thumbnails for video files. Those libraries make up 32 of the 33 most severe (severity: 10) vulnerabilities.
To be clear - I have already developed the necessary libmediascan patch(es) necessary to build/link it with the new ffmpeg. The level of effort is minimal, but I wanted to have a discussion about it.
Can you try to get those changes upstream (https://github.com/andygrundman/libmediascan)?
I should probably find out what the most popular platforms currently are. Then try to update these? Would that make sense? There's no way we're going to update for 48 platforms, many of which likely are obsolete.
Yes, I can pursue proposing the changes upstream. I will work on that tonight. Would you prefer to wait until the changes are accepted upstream? Or should I submit a PR with the patches here, too?
I should probably find out what the most popular platforms currently are. Then try to update these? Would that make sense?
I think so. I can certainly help with that for the Linux i386 and x64 builds, at least. I don't have a Mac, nor do I have access to an arm or powerpc machine.
There's no way we're going to update for 48 platforms, many of which likely are obsolete.
Wow. That's a lot. Is that the matrix of Perl versions and OS's in the CPAN/arch directory over in the slimserver repo?
Submitted upstream.
Note: These patches are intentionally inflexible, because flexibility would allow users to continue to build using vulnerable software. Thus, use of this patched version will require both FFmpeg and GIFLIB to be upgraded.
There's no way we're going to update for 48 platforms, many of which likely are obsolete.
Maybe it is a good idea to drop off some very old platforms and consolidate the ones already there. Can I help in some ways? I am not deep in coding by I am quite good in testing and adapting...
All I can say for now fsbruva's changes work on OpenIndiana/Solaris and I am keeping up and clean these scripts since I use that platform.
Concerning Windows I started trying to have strawberryperl support for building but there are some issues with that for now. Maybe it would be wise to use strawberryperl since it uses gnu tools for building. I think that the perl version is delivered with LMS so that might work?
Just let me know.
Maybe it is a good idea to drop off some very old platforms and consolidate the ones already there. Can I help in some ways? I am not deep in coding by I am quite good in testing and adapting...
I started not including Perl <5.12 in the ARM and x86 packages a while ago. But people are still downloading the _all.* packages... Maybe it's time to exclude some more.
And that's where I have a split personality: as a developer I would love to have more information about the users and their systems. I considered reporting the perl version used etc. when LMS is calling home. But as a user myself I'm always reluctant to share more data with the outside world...
Concerning Windows I started trying to have strawberryperl support for building but there are some issues with that for now. Maybe it would be wise to use strawberryperl since it uses gnu tools for building. I think that the perl version is delivered with LMS so that might work?
The problem is we're bundling up the Perl code to a binary using ActiveState's PerlApp and related tools. I doubt that would work well with Strawberry Perl. And Windows users definitely are not used to installing Perl and configuring it to run as a service. Changing from ActiveState to Strawberry would be a massive amount of work.
I started not including Perl <5.12 in the ARM and x86 packages a while ago. But people are still downloading the _all.* packages... Maybe it's time to exclude some more.
And that's where I have a split personality: as a developer I would love to have more information about the users and their systems. I considered reporting the perl version used etc. when LMS is calling home. But as a user myself I'm always reluctant to share more data with the outside world...
Does it help to maybe built "into a distro"? I am packaging stuff for OpenIndiana. They have a "running release", but you are more or less tied to hat is in the distro. They build it and distribute it. Maybe something like that would help to get rid of very old distros/perls. On OpenIndiana it is perl5.22 or 5.24.
The problem is we're bundling up the Perl code to a binary using ActiveState's PerlApp and related tools. I doubt that would work well with Strawberry Perl. And Windows users definitely are not used to installing Perl and configuring it to run as a service. Changing from ActiveState to Strawberry would be a massive amount of work.
Seems okay to me too. Do you have a build script somewhere (and maybe the needed ActiveState Version)? Then I would try my best with ActiveState in travis. Issue I have with ActiveState is: There is only the latest version online and they use msvc.