> > FYI, last time i tried to include this file from libavcodec i was told > not to since it's libavformat specific. > > The proper place for these wrappers is probably the compat folder, in > a new file similar to w32threads.h >
It occurred to me as well that this should be a common header perhaps supplied in libavutil. Currently os_support has many similar functions that provide win32 specific implementations of missing functionality so adding this patch to the existing list of functions supplied in that header seemed the most suitable place to include it as it keeps all the similar functions together. Which to me makes the issue that most of the code in os_support should probably not be in an avformat specific header and in fact should be moved. So for simplicity I added it to the existing code, but if it is decided that this os specific header should be moved to a more central location then Ill write up a second patch after this one get applied that will move all the shared code from os_support (as opposed to putting this patches code in a different location and ending up with similar code spread out in different locations throughout the code base). On 30 August 2016 at 02:26, Jean-Baptiste Kempf <j...@videolan.org> wrote: > On 28 Aug, Matt Oliver wrote : > > The dlopen function is modified to prevent loading dll's from the current > > directory for improved program security for library users. This extends > > similar functionality from the recently applied SetDllDirectory patch > > except that it adds additional security for library users as well (as > > opposed to just program users). > > Why allowing it to open the local folder? > > Said differently, what are you allowing to open, and why? So this is for opening of dynamic link libraries which under normal circumstances the function to load a dll will search multiple different directories in order to find the requested dll. This patch is a result of a discussion on the ffmpeg-security mailing list about the ability for hackers to create a fake dll that gets picked during the dll search and loaded instead. So this patch adds code to limit the search for a dll to the applications install directory and the system directory only. Initially I was just going to limit it to the system folder (which would be the most secure) but others requested the application directory also be included as they use that functionality during testing by adding their own test versions of dlls to the application dir. Also given that although the application dir may be less secure but if someone can modify dlls in that folder then they can modify the application itself anyway so allowing it doesnt really make things any worse. So the main thing is that this patch limits where dll's can be loaded from to limit the ability for someone to inject insecure code into a program. It does this by limiting the standard searched locations to just a subset that only includes the application directory (searched first in case the app requires specific version of dlls that differ from the system version) and then the system directory. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
