On Wed, Jul 30, 2014 at 02:12:25AM +0200, Andreas Cadhalpun wrote: > On 30.07.2014 00:54, Russ Allbery wrote: > >Andreas Cadhalpun <andreas.cadhalpun@googlemail.com> writes: > > > >>I must have failed to make my point again. :( > >>As far as I know there are hundreds of security updates (for all packages > >>together) in the lifetime of a stable release. Compared to that 10 is not > >>large. And, as I already mentioned, I think that some of the FFmpeg > >>updates are minor enough to go through stable-updates. > > > >>It doesn't make a software less secure, if (even minor) security fixes get > >>backported even to old release branches, rather the contrary. > > > >Well... backporting security fixes more of a bare minimum -- that's just > >something that has to happen if we're going to support the software at > >all, with a handful of exceptions where the software is, for one reason or > >another, important enough that we're willing to release with it even > >though security patches aren't backported properly and then terminate > >support in the middle of our normal stable process. > > So it's good that FFmpeg upstream does that backporting. > > >But software should also not pose a significant security load in the first > >place. That quantity of security vulnerabilities tells me that something > >is deeply wrong with FFmpeg as an upstream source base. That's a sign of > >code with a bad smell. > > In my opinion the large amount of security fixes is due to the fact > that FFmpeg is a large codebase and that most of the code has to > deal with untrusted data, a.k.a. multimedia files. > > >Now, that doesn't necessarily mean that it doesn't belong in Debian. > >Sometimes we have to hold our nose and live with that, and it sounds like > >libav isn't necessarily a lot better. > > On the contrary I think that Libav is worse, as it doesn't even > apply all patches for security vulnerabilities fixed in FFmpeg that > also affect Libav. Just have a look at the security tracker of > Libav[1]. > > > But those are really painful > >statistics that, to me at least, indicate the world is crying out for a > >replacement code base that accomplishes the same goals but was written > >with a higher level of quality in mind. > > > >Obviously easier said than done, of course. > > The time needed to do that would likely be spent a lot better with > trying to find and fix the remaining vulnerabilities in FFmpeg, > because any rewrite of such a large code base inevitably introduces > it's own security bugs. > > >Is upstream aware that this is a really bad track record and trying to do > >something proactive to increase the quality of the code, like > >comprehensive auditing, or proactive rewrites to use more secure coding > >practices such as some of the work that the LibreSSL team has been doing? > > On 30.07.2014 01:01, Russ Allbery wrote: > > Ah, I should have Googled my own question. > > > > http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html > > > > Well, that's... better than nothing. It's certainly part of an > > overall strategy, although that number of issues still indicates to > > me that there are style and architecture issues here that could > > benefit from more proactive design work. I could be wrong, having > > not looked at the code personally -- maybe the problem space is just > > really hard. But that seems like quite a lot of errors. > > You could also have asked FFmpeg upstream. (I've CCed Michael > Niedermayer now.) Yes the problem space is hard ... The problem with multimedia in relation to security is that * There are hundreads of different formats, requireing alot of code to support them * The input files and streams can generally not be trusted, which makes most of the code security relevant and a potential target for an exploit * Many and especially the most important and efficient formats are very complex * The code must be very fast, users want to see their movies play in realtime not waiting for each frame to be decoded. And most of the code is speed relevant Above applies to any implementation, and constrains architecture options ... What we do to combat that is All patches going into FFmpeg are reviewed with security in mind The codebase was repeatledly tested with fuzzed files to uncover all kinds of anomalies, all such found anomalies where fixed. Also independant of googles fuzzing efforts, some of our users have done their own fuzzing. And during google code in several students have as well manually tried to find security issues. FFmpeg is regularly tested with static code analyzsers like coverity and most issues found get quickly fixed FFmpeg is tested regularly with runtime memory checkers like valgrind, address sanitizer and others and all reproduceable issues are fixed, iam not aware of any open and reproduceable one Almost all of the internal APIs used in FFmpeg are designed to be secure, always passing array sizes and checking them instead of assuming the caller knows they are large enough, exceptions to this are just the most speed critical parts. Codecs which are WIP and arent up to security standards can be and are marked as experimental and will not be selected during autodetection unless overriden by the user. ... If anyone has any ideas of how we can improve security further with the available resources. Iam very interrested in that and thats quite independant of FFmpeg being accepted in debian or not. I do care about FFmpegs security [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato
Attachment:
signature.asc
Description: Digital signature