FreeImage loads user plugins in 3 ways under Windows, and 1 way everywhere else.
The 3 ways are:
- FreeImage_Initialise scans curr working dir, and a "plugins" subdir for "*.fip" files, trying to load an "Init" prog from it. Using "Init", it creates a Plugin and adds it to the internal plugins list.
- FreeImage_RegisterExternalPluginLoadLibrary from user specified path and then tries to load again "Init" prog from it and create the Plugin.
- FreeImage_RegisterLocalPlugin adds a user provided Plugin instance to the plugins list.
Aside from the fact the first two a implemented only for Windows, making the API incomplete, there is a bigger problem - security. I am not a security expert, but loading blindly a proc with a certain name from litarally everyware, can't be safe. I don't see what prevents an attacker to create a virus.fip with a Init entry point and just place it into the directory of the application. FreeImage will gladly load it for him. Second version is not much different, the only diff is the attacker must know the program uses external plugins and where they are stored.
For that reason (most certainly), this code will fail under newer Windows APIs like WinRT and UWP, making the feature unavailable for modern Windows development as well.
Luckily, the last function RegisterLocalPlugin is all that we need - we just need the plugin instance and that is it. How and were it is stored is not of our concern!
External code loading is not integral to the library and should entirely be left to the user and the frameworks he uses. He can always pack his code into a dll and load it at runtime, using more secure methods and tools, or just embed it into his application.
It is also interesting to note, no one using the other platforms requested adding this, though a lot other requests and contributions are made!
In closing, FreeImage_Initialises folder scan and FreeImage_RegisterExternalPlugin should be deprecated and later removed.
FreeImage loads user plugins in 3 ways under Windows, and 1 way everywhere else.
The 3 ways are:
-
FreeImage_Initialisescans curr working dir, and a "plugins" subdir for "*.fip" files, trying to load an "Init" prog from it. Using "Init", it creates aPluginand adds it to the internal plugins list.-
FreeImage_RegisterExternalPluginLoadLibraryfrom user specified path and then tries to load again "Init" prog from it and create thePlugin.-
FreeImage_RegisterLocalPluginadds a user providedPlugininstance to the plugins list.Aside from the fact the first two a implemented only for Windows, making the API incomplete, there is a bigger problem - security. I am not a security expert, but loading blindly a proc with a certain name from litarally everyware, can't be safe. I don't see what prevents an attacker to create a
virus.fipwith aInitentry point and just place it into the directory of the application. FreeImage will gladly load it for him. Second version is not much different, the only diff is the attacker must know the program uses external plugins and where they are stored.For that reason (most certainly), this code will fail under newer Windows APIs like WinRT and UWP, making the feature unavailable for modern Windows development as well.
Luckily, the last function
RegisterLocalPluginis all that we need - we just need the plugin instance and that is it. How and were it is stored is not of our concern!External code loading is not integral to the library and should entirely be left to the user and the frameworks he uses. He can always pack his code into a dll and load it at runtime, using more secure methods and tools, or just embed it into his application.
It is also interesting to note, no one using the other platforms requested adding this, though a lot other requests and contributions are made!
In closing,
FreeImage_Initialises folder scan andFreeImage_RegisterExternalPluginshould be deprecated and later removed.This, combined with https://sourceforge.net/p/freeimage/discussion/36111/thread/11068961/
completely eliminates any form of initialization of the library.