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

[Reimar Döffinger]

On 24 Feb 2013, at 03:07, Kyle Schwarz <zeranoe at gmail.com> wrote:

> 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.

No it can't, the path for searching a linked dll is different, it is basically just the installation directory and the system directories that ate searched.
I repeat, LoadLibrary searches the working directory (aka '.') by default.
This is often set to the place where data files are located (and the file selection dialog actually changes it for example) and thus can easily refer to a completely untrusted location.
But otherwise this has been all over the news a few months back, with everyone having to patch a lot of stuff (for example Microsoft Office), so I'd expect it should not be so hard to find details.

> 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.

It's Windows, if you're looking for sense it's the wrong place.