[FFmpeg-devel] Load FDK AAC at run-time

[Reimar Döffinger]

On Thu, Feb 21, 2013 at 03:59:44PM -0500, Kyle Schwarz wrote:
> On 2/19/2013 4:56 PM, Reimar Döffinger wrote:
> >On Tue, Feb 19, 2013 at 01:15:17AM -0500, Kyle Schwarz wrote:
> >>On 2/17/2013 11:40 AM, Carl Eugen Hoyos wrote:
> >>>Kyle Schwarz <zeranoe <at> gmail.com> writes:
> >>>
> >>>>There is a demand for FDK AAC, but FDK AAC cannot
> >>>>be compiled into a FFmpeg binary and remain
> >>>>compatible with the GPL. FDK AAC can however be
> >>>>redistributed as a binary alongside a FFmpeg copy
> >>>>that is GPL.
> >>>
> >>>Ianal, but imo, that would (exactly) contradict the
> >>>(essence of the) GPL and we should therefore not
> >>>support it.
> >>>
> >>>Whoever needs a better GPL-compatible AAC encoder
> >>>should consider to either improve or support
> >>>improving FFmpeg's native AAC encoder.
> >>
> >>I don't want to start any arguments, but are there any other people
> >>with an opinion?
> >
> >Well, I see advantages in dynamic loading (for example distributions
> >can make it an optional dependency, thus reducing bloat).
> >However I am strongly against doing it in any way that might
> >make people believe this changes anything with concern to
> >licensing, I find it likely that these kind of "tricks"
> >will at best work in a select few jurisdictions if at all.
> >There is also the point that dynamic loading in a way that
> >works across operating systems without opening security holes
> >is very tricky to do from a library.
> >For example, Windows by default loads libraries from the
> >current working directory, which is a security concern.
> >The solution to that is to disable that behaviour,
> >however doing that inside libavcodec seems inappropriate
> >since libraries should avoid changing global program state.
> 
> If FFmpeg is compiled as a shared build, for Windows it loads the
> .dll files in the working directory.
> 
> Please explain how you think this would expose a security hole?

Because the working directory might be a webdav directory some malware
author? Which will be that case if you e.g. play a media file from such
a share.
And you'd then load the arbitrary code from a bad guy in the internet
with full privileges, just because someone was trying to play a file
from the internet.
How in all the world is that _not_ a gigantic security hole?