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

[Kyle Schwarz]

On 2/23/2013 12:52 PM, Reimar Döffinger wrote:
> 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?

If your talking about a malicious .dll file being loaded, the current 
setup could be exploited. A shared build loads .dll files for 
avcodec-54.dll and that .dll file could be manipulated just the same as 
a external library .dll.

Please explain to me if I'm missing something, but your saying that by 
making ffmpeg load .dll files will opens up security holes doesn't seem 
to make sense to me.

Best regards,
   Kyle Schwarz